EvolveHQ/docflow

Exécute une vague limitée sur le plan/la file d'attente des tâches dans un dépôt piloté par la documentation, en utilisant les agents parallèles disponibles ou une exécution séquentielle. Établit la largeur, le budget et la supervision ; isole le travail et collecte les résultats vérifiés. À utiliser pour « lancer une vague d'agents », « exécuter la file d'attente en parallèle », « répartir le travail » ou « vague d'agents », et non pour rédiger une décision ou ajouter un nouvel élément à la file.

Qu'est-ce que docflow ?

Ce skill, `agent-wave`, orchestre l'exécution contrôlée des éléments de la file d'attente dans un dépôt piloté par la documentation, en respectant les capacités réelles de l'hôte (parallélisme, isolation). Il établit une largeur (nombre d'agents simultanés), un budget (en éléments ou vagues) et une supervision (point de contrôle après chaque vague ou continue). Le skill isole chaque élément de travail, collecte les résultats vérifiés et les intègre selon le profil du dépôt. Il prend en charge plusieurs modes d'exécution (écriture unique, checkout partagé, arbres de travail séparés) et plusieurs niveaux d'orchestration, du plus simple (un élément à la fois) au plus avancé (délégation via une fonctionnalité d'orchestration activée par l'opérateur). L'objectif est de permettre à un développeur ou à un utilisateur d'agents IA de lancer une « vague d'agents » pour traiter plusieurs éléments de la file d'attente en parallèle ou en séquence, avec des garanties de sécurité (pas de vol de travail, pas d'écrasement de revendications) et une supervision complète.

Compatible avec~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/EvolveHQ/docflow/tree/HEAD/plugins/docflow/skills/agent-wave

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

vague-agent

Exécute un lot déclaré d'éléments acceptés de la file d'attente en utilisant les capacités que cet hôte expose réellement. Les budgets comptent les éléments ou les vagues. Un plafond horaire optionnel arrête les nouvelles vagues, jamais un élément en cours d'exécution. L'automatisation de longue durée utilise la fonctionnalité de planification de l'hôte (voir README) ; cette session ne promet pas de lui survivre.

Préconditions et capacité de l'hôte

Avant de poser des paramètres, lisez le point d'entrée du dépôt, les conventions, la file d'attente et l'invite autonome. Résolvez tous les chemins d'artefacts, y compris _agent/, par rapport à la racine enregistrée. Exigez une porte réelle et la file d'attente qu'elle parcoure.

Mode enregistréExécution
Écrivain uniqueArrêtez et dirigez l'opérateur vers l'invite autonome séquentielle, à chaque largeur demandée.
Checkout partagé, intégration directeUn exécuteur à la fois dans ce checkout, en utilisant le statut des éléments et les lignes de verrouillage. Pas de branche de revendication ou d'arbre de travail d'intégration.
Checkout partagé, intégration PRArrêtez avant de revendiquer ; exigez des arbres de travail séparés pour les vagues PR.
Arbres de travail séparésChaque exécuteur utilise son propre arbre de travail ; l'intégration suit le modèle enregistré.

Récupérez/taillez le dépôt distant enregistré et exigez sa branche d'intégration. Imprimez le SHA de base récupéré. Comparez la référence d'intégration locale : signalez les commits non poussés ou la divergence avant de continuer, ne les supprimez jamais silencieusement. Un checkout en retard et propre peut être avancé rapidement lorsqu'il est sûr ; sinon, laissez-le tranquille. L'état et la sonde de la vague proviennent de la base récupérée, pas des fichiers non validés dans le checkout de l'opérateur. Si la file d'attente distante est vide mais que la file d'attente locale est différente, expliquez cette différence.

Déterminez si l'hôte peut déléguer, isoler les checkouts, exécuter en concurrence, utiliser une fonctionnalité d'orchestration déjà activée par l'opérateur, et exiger des résultats structurés. Choisissez le niveau disponible le plus élevé :

  1. Fonctionnalité d'orchestration activée : un seul fan-out pour cette vague uniquement. Conservez les boucles de vague, les vérifications d'horloge et les questions dans l'orchestrateur.
  2. Sous-agents simples : en parallèle si disponible, séquentiel sinon. Utilisez l'isolement d'arbre de travail de l'hôte uniquement si sa tête de départ est égale à la base déclarée ; sinon, créez explicitement chaque arbre de travail à cette base.
  3. L'orchestrateur exécute un élément à la fois, dans son propre arbre de travail ou le checkout partagé selon ce que le mode enregistré permet.

Signalez Exécution : niveau N — raison. L'opérateur peut réduire ce choix ; ne l'augmentez jamais au-delà de la capacité observée ni ne sollicitez son activation. Une compétence mentionnant une fonctionnalité n'est pas une adhésion de l'opérateur. Le même bref canonique ci-dessous est utilisé à chaque niveau. Sans plafond de concurrence prouvé, utilisez-en un.

Évaluation et déclaration

Réutilisez les réponses applicables déjà données, y compris la profondeur ; les valeurs par défaut ne remplacent jamais les choix explicites. Une spécification entièrement fournie n'a besoin d'aucun sélecteur ou confirmation répété. Ne demandez qu'un choix manquant matériellement ou conflictuel ; une préférence enregistrée seule n'est pas une autorité d'exécution actuelle. Sinon, posez une question à la fois avec une réponse recommandée et une raison, en utilisant un sélecteur structuré si disponible. Lorsque la profondeur n'est pas résolue, proposez une profondeur expresse (valeurs par défaut), guidée (budget/supervision) ou complète, avec la profondeur enregistrée présélectionnée. Honorez les valeurs par défaut-à-partir-d'ici ou allez-plus-loin.

  1. Largeur demandée : recommander min(profondeur éligible de la file d'attente, 3, plafond de l'hôte).
  2. Budget : éléments ou vagues ; recommander une vague. Optionnellement un plafond horaire souple.
  3. Supervision : point de contrôle après chaque vague (recommandé), ou continue.
  4. Intégration : utiliser le profil du dépôt sauf indication contraire explicite. L'intégration directe est légitime avec les garde-fous de concurrence enregistrés ; son intégration est série. Une dérogation ne peut pas rendre valide un mode non pris en charge.

Déclarez et confirmez la spécification résultante avant l'exécution (les paramètres appelés de façon explicite constituent déjà une confirmation). Inclure :

  • Nom de la vague, date, dépôt distant, branche d'intégration et SHA de base récupéré.
  • Largeur demandée/effective, niveau/raison, plafond de l'hôte et toute limite de jetons.
  • Budget, supervision et plafond souple ; ne convertissez jamais les limites de jetons en nombre d'éléments.
  • La clé de chaque élément, les décisions propriétaires, les dépendances, la variante de revendication, les artefacts exacts détenus, les identifiants réservés avec leurs séquences, et le drapeau Continuer.
  • Profil d'isolation et d'intégration ; actions d'intégration/fusion réellement accordées.
  • Octroi : « Vague assistée : l'opérateur a confirmé ces paramètres et cet élément le ; n'implémentez que l'élément nommé, n'en choisissez jamais un autre. »

Réservez uniquement les identifiants qu'un élément créera, en blocs finis et disjoints. Incluez les réservations existantes actives ; les éléments continués conservent leurs réservations d'origine. N'attribuez jamais à deux écrivains la même décision ou le même corps de plan. INDEX est dérivé : un exécuteur modifie uniquement ses propres lignes, et l'intégration régénère l'ensemble du tableau. Les réservations épuisées arrêtent l'élément ; pas de vol de créneaux.

Après confirmation, créez un arbre de travail d'intégration/sonde détaché à la base pour le mode arbres de travail séparés, en dehors de l'arborescence de l'opérateur. Réutilisez un résidu uniquement après avoir prouvé qu'il est propre et détenu. Sondez la porte exacte là-bas avec uniquement les fichiers suivis et l'environnement existant. En cas d'échec environnemental, arrêtez avant l'envoi et signalez la commande, la sortie et le code de sortie ; n'installez pas de dépendances manquantes et n'insinuez pas que la sélection du niveau trois répare la porte. Signalez le chemin effectif des hooks et l'origine du paramètre de signature.

Collecte avant chaque vague

Récupérez/taillez à nouveau ; lisez le statut des éléments, les conseils de revendication, les arbres de travail et l'état des PR. Utilisez cette préséance, en résolvant chaque élément à la base et au conseil de revendication :

ClassePreuve et action
InvérifiablePreuve distante/PR requise indisponible ou contradictoire : arrêtez l'exécution.
ExpédiéEntrée Done sur la branche d'intégration avec un commit de pied de page accessible ou une PR fusionnée confirmée. Exclure.
Fusionné mais non expédiéTravail/PR fusionné mais l'élément toujours en file d'attente sur la base. Exclure et demander une réconciliation.
ArrêtéChamp Stopped sur la base ou le conseil de revendication. Exclure sauf continuation explicite.
ActifRevendication distante non fusionnée ou PR en brouillon/prête, ou propriétaire/verrous de checkout partagé actuels. Exclure sauf continuation explicite.
StalePropriété locale basée sur une branche après disparition confirmée de la référence distante. Signalez le nettoyage ; ne réaffectez pas les restes incertains.
ÉligiblePropriété acceptée, dépendances satisfaites, aucun conflit de revendication/arrêt/état stale. Sélectionnez dans l'ordre de la file d'attente.

Une PR prête peut avoir déplacé l'élément vers l'état done sur sa propre branche. Résolvez ce déplacement via l'historique des PR liées ; il est toujours actif, pas orphelin. Vérifiez les fusions de PR confirmées lorsque le squash/rebase rend l'ancestralité source non concluante. Les revendications partagées sont évaluées à partir des éléments/verrous, jamais de l'absence de revendication distante. Les arbres de travail détachés ne sont ni des revendications ni des états stale. Une référence de revendication locale en avance signifie un travail non poussé : retournez inconnu et préservez-le.

À profondeur guidée/complète, proposez Continuer uniquement pour une revendication active/arrêtée existante ; par défaut, excluez-la. L'état Express exclut et liste comment continuer. Un appel nommant la revendication ou l'élément est la réponse explicite. Continuer ne crée pas une nouvelle revendication ou réservation ; signalez tout arbre de travail restant. Après la sélection, revérifiez le chevauchement des chemins détenus et les dépendances.

Consigne canonique de l'exécuteur

Passez cette consigne complète avec la spécification de l'élément, inchangée à tous les niveaux :

  1. Ouvrez et orientez-vous. Vérifiez l'ancestralité de la base et l'élément nommé. Un checkout continué doit égaler le conseil de revendication récupéré ; le déplacement d'achèvement d'une PR prête liée est un contexte valide. Lisez le point d'entrée et l'invite autonome. Une discordance est bloquée, jamais une permission de travailler un autre élément.
  2. Revendiquer. Récupérez à nouveau. Pour un nouvel élément avec arbre de travail séparé, créez claim/<clé-élément> à partir de la base ; commitez Claimed by avec acteur/date/branche et mettez la branche de revendication réelle, la vague, les réservations et les artefacts détenus dans son premier message de commit. Avant de publier, relisez git show -s --format=%B HEAD et git show HEAD:<chemin-plan-détenu>. Vérifiez la branche réelle littérale dans le message et Claimed by, le nom de la vague, les réservations (y compris aucune), et les chemins détenus exacts. Vérifiez git diff-tree --no-commit-id --name-only -r HEAD : ce commit initial modifie uniquement le statut de l'élément détenu, sans résultat d'implémentation. Réparez les métadonnées manquantes localement avant l'acquisition. Un commit ultérieur ne peut pas réparer une revendication initiale déficiente. Validez la clé avec git check-ref-format --branch ; n'utilisez jamais un espace réservé littéral. Acquérez avec git push --porcelain --force-with-lease=refs/heads/claim/<clé-élément>: origin HEAD:refs/heads/claim/<clé-élément>. Exigez un code de sortie zéro et le résultat porcelaine * new-ref pour cette destination. Les références existantes, y compris les résultats same-tip/up-to-date, n'accordent aucune propriété. Attendez la fin de cette poussée et inspectez son accusé de réception de nouvelle référence avant d'émettre une quelconque écriture d'implémentation. Ne regroupez pas l'acquisition et l'implémentation dans le même appel d'outil. Un échec de signature/poussée arrête avant l'implémentation ; préservez les résultats inconnus. N'écrasez jamais une autre revendication. Définissez upstream après l'acquisition. Pour le mode PR, ouvrez/réutilisez immédiatement la PR en brouillon avec l'élément, l'acteur, la branche, les réservations, les chemins détenus et le bloc de fermeture ; l'échec bloque l'implémentation. Continuez en détachant à la pointe distante existante, en conservant les réservations et en mettant à jour Claimed by dans le premier commit, puis repoussez sur cette référence. Checkout partagé : revendiquez via le statut de l'élément et les lignes de verrouillage avant chaque édition, y compris les nouveaux enregistrements ; ne créez ni ne changez jamais de branche de revendication.
  3. Implémenter. Suivez l'invite autonome pour cet élément unique. N'acceptez/remplacez pas les décisions, n'insérez ni ne renumérotez les éléments existants de la file d'attente, ne dépassez pas les réservations, ne mettez pas à jour la version, n'étiquetez pas, ne publiez pas et ne demandez pas à l'opérateur. Retournez un bloqueur lorsque la consigne ne peut pas être honorée.
  4. Vérifiez et validez. Exécutez la porte enregistrée exactement. Réparez les échecs d'implémentation compris et relancez. Si la porte ne peut pas s'exécuter, n'installez rien qu'elle n'installe pas elle-même : enregistrez l'erreur exacte dans Bloqueurs, validez/poussez le travail récupérable dans le cadre de l'octroi et retournez bloqué, jamais vérifié ou expédié. Suivez les règles de signature, de Justification et d'intégrité de la porte.
  5. Intégrez selon le profil. Intégration directe avec arbres de travail séparés : poussez la revendication vérifiée et retournez prêt ; l'orchestrateur invoque le mode d'intégration de ship-item. Checkout partagé : invoquez ship-item dans l'arborescence active. Mode PR : invoquez ship-item sur la PR réelle, incluant le rebase, les vérifications de collision, la réparation du numéro propre, les deux portes et le commit d'achèvement. Gardez son corps/rapport à jour ; prêt nécessite des vérifications à la tête actuelle. Fusionnez uniquement dans le cadre de l'octroi et signalez expédié uniquement après un atterrissage confirmé. Retentez une base déplacée au maximum deux fois ; préservez les revendications non résolues en cas d'échec.
  6. Arrêtez et signalez. Mettez date/raison et les trois étiquettes de rapport dans le champ Stoppé de l'élément mis en file d'attente, ou le corps de la PR s'il y a déjà été déplacé. Validez/poussez uniquement dans le cadre de l'octroi. Retournez les champs ci-dessous et le bloc final. Ne créez jamais d'instantané de coordination et ne supprimez pas silencieusement un travail sale.

Exécutez, intégrez et collectez les résultats

Distribuez la vague déclarée avec le mécanisme dérivé. La largeur effective est de un au niveau trois et pour les checkouts partagés. Au niveau trois, revendiquer démarre un élément : créez des branches de revendication locales ou distantes et remplissez Claimed by uniquement pour l'élément actuel, ne pré-revendiquez jamais le lot restant. Inspectez le résultat de sa porte avant d'émettre les commandes de l'élément suivant. Une pré-revendication ultérieure n'est pas un exécuteur déjà en cours d'exécution. Au niveau trois, terminez et intégrez chaque élément avant de commencer le suivant. Avant de faire avancer la boucle, vérifiez le résultat de la porte du dernier exécuteur. Un bloqueur environnemental termine la vague entière immédiatement, même si l'élément suivant est indépendant et que le budget a de la place. Ne commencez pas l'élément suivant ni une autre intégration. Cette règle prend le dessus sur la supervision continue et le seuil d'échec numérique. Récupérez les exécuteurs déjà en cours sans démarrer de nouveau travail, puis signalez le bloqueur systémique. Préservez leurs revendications récupérables. Une sonde de base réussie n'annule pas un échec environnemental après implémentation.

Pour le travail direct en parallèle, invoquez le mode d'intégration de ship-item pour les revendications prêtes dans l'ordre de la file d'attente, en utilisant l'arbre de travail d'intégration détaché. La mécanique d'intégration vit dans ship-item, pas dans une deuxième procédure ici. Les hôtes PR sérialisent les fusions PR autorisées.

Normalisez chaque retour en : clé d'élément ; résultat (expédié, prêt, échoué, bloqué, arrêté, inconnu) ; branche de revendication/réelle ; SHA d'intégration ou PR ; identifiants utilisés/renumérotés ; bloqueur ; fichiers en conflit ; bloc final textuel. Aucun retour signifie inconnu. Le résultat est séparé du vocabulaire Overall. Pour une revendication prête en attente d'intégration, écrivez Resultat : prêt et Overall : partiellement vérifié ; prêt et expédié ne sont jamais des valeurs Overall. Signalez chaque élément et un résumé de vague avec Statut en un coup d'œil ; tout inconnu plafonne la vague à partiellement vérifié. Incluez les revendications exclues/retirées, la largeur effective, le niveau, les résultats de la porte, les origines des hooks/signatures et le travail restant.

Dans la réponse finale, conservez un bloc Statut en un coup d'œil pour chaque élément, puis un bloc séparé pour la vague. Chacun a Cette exécution, Overall et Encore à faire. Un tableau de résultats par élément peut accompagner ces blocs mais ne les remplace jamais, y compris au niveau séquentiel. Vérifiez leur nombre avant de retourner. Mettez la clé de l'élément ou « Vague » dans un titre séparé au-dessus de son bloc. Gardez l'en-tête du bloc exactement Statut en un coup d'œil, sans suffixe d'élément ou préfixe de vague. Mettez Vague dans son propre titre de portée, tout comme pour un élément. Par exemple :

## Élément <clé>
### Statut en un coup d'œil
- **Cette exécution :** <actions observées et sortie/code de sortie de la porte>
- **Overall :** <vocabulaire autorisé>
- **Encore à faire :** <travail restant ou Aucun>

Le point de contrôle demande avant une autre vague. Le mode continu recueille à nouveau depuis git et procède dans le budget confirmé. Lisez l'horloge shell au premier envoi et après chaque vague ; si indisponible, signalez le plafond souple comme non appliqué. Arrêtez de démarrer de nouvelles vagues après le plafond ; ne coupez jamais un élément en vol.

Arrêt et nettoyage

Un refus de permission explicite de l'hôte/outil arrête la vague immédiatement et marque l'élément actuel comme bloqué. Nettoyez les branches de revendication locales et les arbres de travail détachés sans supprimer les résultats récupérables. Signalez le nombre d'arbres de travail supprimés et toute revendication non résolue. Un arrêt normal après la fin de la vague laisse les revendications et les arbres de travail en place pour inspection.

Consignes finales

Ne modifiez pas la configuration de l'hôte, n'activez pas de fonctionnalités et ne modifiez pas les définitions de compétences. L'opérateur conserve le contrôle explicite de l'environnement. Signalez tout écart entre le comportement observé et la documentation de la compétence.

Individual skills in this repo

This repo contains 3 individual skills — each has its own dedicated page.

EvolveHQ/docflow

Assess and add a CONVENTION (a reusable rule, practice, or naming/process standard) to a documentation-led repo — decides FIRST whether it is worth codifying at all, then routes it to the right home (AGENTS.md hard rule, CONVENTIONS.md guidance, GLOSSARY term, or to /new-adr if it is really a one-off decision). Pushes back on premature or duplicate conventions. Use when the user says "add a convention", "make this a rule", "document this practice", "we should always X", or invokes /add-convention. NOT for recording a single architectural/product decision (use /new-adr) and NOT for queueing work (use /new-plan).

EvolveHQ/docflow

Scaffold or retrofit documentation-led conventions (AGENTS.md, CLAUDE.md, CONVENTIONS.md, ADR catalogue, plan/ queue, _agent/ coordination) into a repo. Use when the user asks to "set up conventions", "bootstrap ADRs", "scaffold the documentation-led layout", or "add AGENTS.md and a plan queue". Works on fresh repos and existing ones — preserves existing content and merges rather than overwrites. Opens with an express / guided / full depth choice, so a quick conservative setup needs almost no questions.

EvolveHQ/docflow

Decompose a problem, feature, or goal into candidate ADRs and plan items for a documentation-led repo — one decision per ADR, dependency edges, suggested ordering. Proposes drafts for review and writes nothing until approved. Use when the user says "brainstorm ADRs", "break this down into decisions", "what ADRs do we need for X", "plan out the work", or invokes /brainstorm.

Skills associés