hbardet/batch-features

Batch features

Partie réception du workflow. L'autre partie est work-issue.

Vous ne traitez pas un dump de backlog. Vous transformez des idées brutes en tickets qu'un agent peut planifier sans refaire votre découverte. Cela signifie un débat par élément, puis une approbation, puis la soumission.

Annoncez au début : "J'utilise la compétence batch-features pour transformer cette liste en tickets."

Configuration

shared/ est le répertoire à côté de cette compétence — ~/.agents/skills/shared/ quand elle est installée, ou ../shared/ dans un dépôt. Si un chemin shared/... ne résout pas, utilisez l'autre.

1. Lisez le dépôt : AGENTS.md (ou CLAUDE.md) à la racine. Il est contraignant pour les conventions.
2. Lisez .agent-skills/config.json s'il existe ; sinon lisez shared/config.md, posez les questions de première exécution, et écrivez le fichier.
3. Lisez shared/tracker-adapter.md, shared/labels.md, et shared/issue-template.md.
4. Détectez le tracker. Regardez les labels et tickets existants pour que les nouveaux s'intègrent.
5. Modèles. Vérifiez si le projet a déjà un modèle de ticket (.gitlab/issue_templates/*.md, .github/ISSUE_TEMPLATE/*.md). Si oui, utilisez-le et enregistrez son chemin dans config comme issueTemplate. Sinon, notez que vous proposerez à la fin de commiter shared/issue-template.md dans le projet.

Le débat

Parcourez la liste un élément à la fois. Pour chacun :

1. Reformulez-le avec vos propres mots : ce que c'est, à qui ça sert, pourquoi maintenant. Gardez le libellé original comme citation textuelle sous Intention dans le corps du ticket — même si le reste est en anglais.
2. Proposez une interprétation concrète. Pas "que voulez-vous ici ?" mais "Je comprends ceci comme X, parce que Y. Dites le mot si vous vouliez dire Z."
3. Posez au maximum deux questions. Chacune doit être spécifique, et chacune doit porter une valeur par défaut que l'utilisateur peut accepter en un mot. Posez la question dont la réponse changerait le plus ce qui sera construit. Si l'utilisateur a demandé un débat approfondi, posez-en plus ; sinon deux.
4. Fixez deux choses : les critères d'acceptation (chacun observable et vérifiable) et le type (feature / fix / refactor / chore). Rien d'autre — ni taille, ni domaine, ni dépendances.

Si un élément ne peut pas être fixé après le débat, marquez-le status::blocked avec une note besoin de spec plutôt que de deviner. Créer un ticket vague est pire que de ne pas le créer.

Ne passez à la soumission que lorsque chaque élément a été débattu.

La table de revue

Après le dernier élément, présentez une table pour l'ensemble du lot :

| # | Titre | Type |
|---|-------|------|
| 1 | ...   | feature |

Demandez ensuite l'approbation. L'utilisateur peut modifier les titres, supprimer des éléments ou changer les types. Rien n'est soumis avant cette approbation.

Créer les tickets

Pour chaque élément approuvé, dans l'ordre préféré de l'utilisateur (ordre de création par défaut) :

1. Créez le ticket avec le CLI du tracker, le corps issu du modèle du projet s'il en a un, sinon de shared/issue-template.md. Titres et corps dans la language de la config (par défaut en).
2. Appliquez les labels : status::ready et kind::<type>. Enregistrez le numéro du ticket.
3. Rapportez les URL des tickets.

Si la liste de l'utilisateur impliquait un ordre ("X puis Y"), notez-le dans le corps du ticket sous Notes — ne créez pas de relation de dépendance ou de label.

Si le projet n'a pas de modèle de ticket et que l'utilisateur a accepté votre offre, commitez shared/issue-template.md vers le chemin attendu par le tracker une fois, puis créez. Ne le créez pas en silence.

Rapport

À la fin, affichez :

• Les URL des tickets, une ligne chacune.
• Le résumé du lot : N créés, M bloqués.
• Une ligne : "Pour commencer le travail, dites work-issue <n>."

Garde-fous stricts

• Aucun ticket n'est créé sans l'approbation de la table de revue.
• Aucun ticket n'est créé avec une section Critères d'acceptation ou Vérification vide.
• Aucun ticket n'est créé avec un périmètre deviné : s'il est vague après le débat, il est status::blocked.
• Ne revendiquez jamais un ticket ou ne commencez pas l'implémentation avec cette compétence ; c'est le rôle de work-issue.