fy-flow

Kit de compétences pour le flux de travail multi-agent AI et la collaboration en équipe humaine : gestion des statuts, audits qualité, boucles de prévention des erreurs et automatisation du tableau Kanban.

Qu'est-ce que fy-flow ?

FY-Flow est un kit de compétences pour agents AI conçu pour orchestrer des workflows de développement collaboratifs entre plusieurs agents AI et des humains. Il suit un paradigme de micro-noyau piloté par des contrats (compatible AutoGen) et met en place des mécanismes de contrôle des autorisations, de prévention des tâches fragmentées et d'évitement des états suspendus. Le skill est accessible via des commandes slash comme `/fy-flow help`, `/fy-flow start`, `/fy-flow status`, `/fy-flow kanban`, `/fy-flow trace` ou par langage naturel. Il propose un protocole de passerelle unifiée (Unified Gateway Protocol) avec une matrice de distribution à deux branches : les opérations de console système (branche A) et les interactions de développement métier (branche B). Le flux de décision en trois niveaux (« L0 Réponse instantanée », « L1 Tâche légère », « L2 Développement standard ») garantit que chaque demande est correctement classifiée avant d'être traitée. Le skill intègre également une matrice de huit sous-agents experts (PM, architecte, développeur, frontend, reviewer, QA, docs, DevOps) avec des droits d'écriture et des transitions d'état strictement contrôlés, y compris un mécanisme de jeton de distribution (Dispatch Token) pour empêcher les agents de se faire passer pour d'autres rôles. La gestion des tâches s'appuie sur des commandes CLI puissantes (création de tickets, transition d'état, validation de portes, inspection du tableau Kanban, etc.) et des références modulaires détaillées pour chaque aspect du workflow.

Compatible avec~Claude Code✓Codex CLI~Cursor
npx skills add hava-idea/fy-flow

Installed? Explore more Développement et programmation skills: steipete/bluebubbles, steipete/eightctl, steipete/blucli · View all 6 →

Demander à votre IA préférée

Ouvre une nouvelle conversation avec cette compétence d'agent déjà préchargée.

Documentation

Compétence FY MultiAgent Flow (FY-Flow)

Micro-noyau de développement collaboratif multi-agent piloté par contrat (FY-Flow) — Aligné sur le paradigme AutoGen, prévient efficacement les excès de pouvoir, la fragmentation des tâches et les états suspendus.


Protocole de passerelle d'entrée unifiée (Unified Gateway Protocol)

Toutes les instructions appelant cette compétence sont uniformément redirigées vers cette passerelle d'entrée, avec la répartition et la décision selon les deux branches suivantes :

1. Matrice de répartition à deux branches

Type de brancheCaractéristiques de déclenchement et instructionsMécanisme de traitement et contrat de réponseScénario typique
Branche A : Opérations de console système/fy-flow help/fy-flow start/fy-flow status/fy-flow kanban/fy-flow tracePassage direct au moteur d'exploitation sous-jacent (0 pré-niveau), exécute directement le script correspondant et affiche l'état du système.Affichage du manuel d'aide, SOP d'initialisation, démarrage du tableau Kanban, inspection du tableau de bord, diagramme de lien hors ligne
Branche B : Développement métier et intentions interactivesLangage naturel pour les besoins, modifications de code, développement de fonctionnalités, corrections de bugs, dépannage, /fy-flow autoExécution forcée préalable des [Trois questions de classification et découpage à responsabilité unique] , et affichage explicite de l'en-tête double standard sur la première ligne de la réponse :`【Classification de tâche : L0 Réponse instantanée / L1 Tâche légère / L2 Développement standard】【Responsabilité unique : Ticket conforme / Besoin composite à décomposer en N tâches atomiques】`

2. Flux de décision [Trois questions de classification] pour les besoins métier

[Saisie du besoin métier]
   │
   ├─► 1. Va-t-il y avoir des modifications de fichiers du dépôt (code/doc/conf) ?
   │      ├─ Non ──► 2. La conclusion doit-elle être tracée a posteriori comme base pour l'ingénierie ?
   │      │            ├─ Non ───────────────► 【L0 Réponse instantanée】(pas de ticket, réponse directe, 0 latence CLI, brouillon dans le dossier brouillon)
   │      │            └─ Oui ───────────────► 【L1 Tâche légère】(création du ticket, arrêt en attente de démarrage → après autorisation humaine, complété par un seul rôle)
   │      │
   │      └─ Oui ──► 3. Nécessite-t-il une collaboration multi-rôle, la modification de code métier critique ou la modification de bibliothèques de base communes ?
   │                   ├─ Non ───────────────► 【L1 Tâche légère】
   │                   └─ Oui ───────────────► 【L2 Tâche de développement standard】(création du ticket, arrêt en attente de démarrage → après autorisation humaine, collaboration multi-rôle)
  • Correspondance de classification passerelle et classification élastique CCP :
    • 【L0 Réponse instantanée】 : Pas de ticket, réponse directe, 0 surcoût de machine d'état ;
    • 【L1 Tâche légère】 : Correspond à CCP Tier-3 (Fast-Path, pas de rapport physique, écriture directe des justificatifs dans le tableau Kanban) ;
    • 【L2 Développement standard】 : Correspond automatiquement à CCP Tier-2 (optimisation locale, temps de travail ≤ 4,0 h, pas de rapport physique) ou CCP Tier-1 (contrainte forte de l'architecture centrale et du contrat d'interface) selon l'ampleur et le contrat.
  • Pour toutes les demandes métier L1/L2, la passerelle applique une vérification de responsabilité unique (temps de travail ≤ 8,0 h, livrable atomique unique). Les demandes transversales orthogonales doivent être décomposées en tickets.
  • Ligne rouge infranchissable pour l'autorisation de démarrage : La création du ticket marque la fin de l'état de planification de la session en cours ; le ticket doit strictement rester à l'état [En attente] ; sans instruction explicite d'autorisation de démarrage de l'utilisateur humain (par exemple "Démarrer", "Commencer le développement", "Confirmer l'exécution"), il est strictement interdit de passer automatiquement à l'état [En cours].
  • L'ID de tâche d'exécution (par exemple T0001) traverse directement la passerelle pour entrer dans la machine d'état ; il est interdit de créer un deuxième ticket.

Tableau de référence rapide des commandes principales (CLI Command Quick Reference)

Scénario métierCLI unifiée (cli.py)Script spécialisé sous-jacentRôle principal et paramètres
Création d'un ticket de tâchepython3 scripts/cli.py task create ...python3 scripts/quick_task.py create ...--name "..." --assignee "..." --stage "Sprint 2.1 Ajustement du menu" --type "A" --target "..." --criteria "..." [--in-scope "fichier # raison"]
Validation d'entrée/sortie de porte d'étapepython3 scripts/check_stage_gate.py ...python3 scripts/check_stage_gate.py ...--action start/close --stage "Sprint 2.1 Ajustement du menu" (validation à la demande, vérification automatique des dépendances antérieures)
Dispatching codépython3 scripts/cli.py dispatch --task-id T00xx --format codexpython3 scripts/dispatch_task.pyVérifie les dépendances et la concurrence, passe à [En cours], affiche les paramètres JSON directement utilisables par l'outil sous-agent Codex
Avancement de la transition de tâchepython3 scripts/transition_task.py ...python3 scripts/transition_task.py ...--task-id T00xx --role DEV --from-status En cours --to-status En revue --token <token> --summary "Description des modifications principales" --remarks "..." (la soumission à la revue exige --summary pour injecter automatiquement le diff et l'instantané de justificatif)
Validation finale humainepython3 scripts/cli.py task accept ...python3 scripts/quick_task.py accept ...--task-id T00xx (Réservé à l'utilisateur humain, interdiction de signature par l'agent)
Démarrage du tableau Kanbanpython3 scripts/cli.py kanbanpython3 scripts/start_kanban_server.pyDémarre par défaut sur http://127.0.0.1:32886/
Inspection de santépython3 scripts/cli.py statuspython3 scripts/heartbeat.pyAffiche la santé du tableau de bord, les tickets bloqués et les indicateurs de performance (inclut la cognition itinérante du sous-agent et les alertes > 600s)
Synchronisation de la pile technique / Recalcul du profil-scripts/update_agent_tech_stacks.py--force-recalc force le recalcul du profil de capacité technique expert et rafraîchit l'exportation du sous-agent, résout le problème de profil obsolète après migration de la pile technique
Vérification de continuitépython3 scripts/cli.py ccp ...python3 scripts/cli.py ccp ...--task-id T00xx --stage En revue Vérifie la continuité du contexte
Diagramme de lien completpython3 scripts/cli.py tracepython3 scripts/generate_trace_html.pyAnalyse hors ligne la trace de la session, génère en quelques secondes un diagramme de lien complet au format HTML (0 Token)
Test incrémental intelligentpython3 scripts/cli.py testscripts/run_tests.pyDétecte automatiquement les modifications Git, exécute uniquement les tests unitaires pertinents (en quelques secondes), les modifications de documentation sont automatiquement exemptées, --all pour une régression complète

Matrice des droits d'écriture et des intervalles de transition des 8 sous-agents experts

[!IMPORTANT] Règle d'isolement physique et contrôle par jeton (Dispatch Token Gating) :

  1. L'agent principal (PM Yan Manager) est strictement interdit de se faire passer pour un développeur et d'écrire du code métier dans la session principale ! L'hôte Codex doit utiliser un véritable outil de sous-agent pour dispatcher ; les autres hôtes peuvent utiliser leurs propres outils de sous-agent.
  2. Dispatching codé et contrôle par jeton : Le dispatching d'une tâche génère un dispatch_token exclusif via cli.py dispatch. Les rôles de développement professionnel (DEV/FRONTEND/REVIEWER/QA) doivent obligatoirement utiliser --token <token> lors des transitions ; la machine d'état vérifie de manière stricte l'existence du jeton, empêchant ainsi les simulations et les faux positifs.

Contrat de dispatching automatique pour le bureau Codex

Après autorisation explicite de démarrage par l'utilisateur, l'agent principal exécute dans le répertoire du projet cible : python3 .agents/skills/fy-flow/scripts/dispatch_task.py --task-id <ID> --format codex. La sortie standard est un objet JSON unique contenant tool, arguments, task_id et role ; les informations de diagnostic transitent par la sortie d'erreur standard. L'agent principal doit immédiatement passer arguments tel quel comme paramètre d'un véritable appel à l'outil collaboration.spawn_agent, attendre le retour du sous-agent, puis continuer à dispatcher les experts revue et test selon l'état actuel de la tâche. Ne pas réécrire, copier ou résumer manuellement le message de dispatching ; ne pas imprimer le JSON comme si le dispatching était terminé, et ne pas faire exécuter le travail d'expert par l'agent principal. Si l'hôte Codex actuel ne dispose pas d'outil de sous-agent, signaler clairement l'absence de capacité de l'hôte, laisser la tâche dans son état actuel, et ne pas falsifier de reçu d'expert. L'expert déjà dispatché ne doit exécuter que le exit_contract.required_cli présent dans le message, et ne doit pas recréer de ticket ou redémarrer. Comme l'autorisation de l'utilisateur couvre cette exécution, le dispatching peut être poursuivi dans la même session après la création du ticket ; seul le cas sans autorisation de démarrage doit rester en [En attente].

Identifiant du sous-agentNom du rôleResponsabilités principalesIntervalles de transition d'état légitimesContrat de sortie
@flow-pmYan Manager (Chef de projet)Décomposition des besoins, classification et création de ticketsEn attente -> En cours / Demande de validationLe scénario de création de ticket s'arrête en [En attente] en attendant l'autorisation de démarrage ; demande de validation humaine
@flow-architectQian Architect (Architecte système)Architecture globale du système, contrat d'interface et choix techniquesEn attente -> En cours -> TerminéProduit un document ADR et un plan d'architecture
@flow-devLi Dev (Ingénieur développeur)Codage principal back-end / full-stack et implémentation de tests unitairesEn attente -> En cours -> En revueDoit exécuter les tests unitaires, générer un rapport de développement, fournir --summary pour la soumission à la revue
@flow-frontendMa Frontend (Ingénieur développeur frontend)Implémentation des composants Web/UI et de l'expérience frontendEn attente -> En cours -> En revueVérifier le rendu des composants et l'interaction, générer un rapport, fournir --summary pour la soumission à la revue
@flow-reviewerZhou Reviewer (Expert en revue de code)Convention de code, analyse de sécurité et contrôle qualitéEn revue -> En test / En revue -> Terminé (Passage direct sans QA si les justificatifs Tier-3 sont frais et non dérivés) / En revue -> RetournéAnalyse statique sans alerte, produire un avis de revue
@flow-qaZhang QA (Ingénieur test)Tests d'intégration ciblés et validation de sortie (exécuter uniquement les tests liés à la tâche en cours, interdiction des scripts complets)En test -> Terminé / En test -> RetournéRédiger des cas de test ciblés, enregistrer le temps de travail réel
@flow-docsLi Wentong (Ingénieur documentation)Gestion des documents livrables et manuel utilisateurEn attente -> En cours -> TerminéSuivre la norme GB/T 7713 académique et d'ingénierie
@flow-devopsLv Gaite (Administrateur DevOps)Fusion de branches, construction de release et protection de l'historique GitEn attente -> En cours -> TerminéVérifier la réussite du pipeline, résoudre le blocage de la PR

Index des entités des spécifications modulaires (consulter le fichier de spécification spécifique selon les besoins)

Lorsque et seulement lorsque l'on entre dans un scénario métier spécifique, l'agent doit appeler view_file pour consulter le fichier Markdown correspondant de la spécification :

Skills associés