g-ki/agent-skills : Tâche d'Investigation (Spike)

Tâche d'Investigation (Spike)

Répondre à une question suffisamment bien pour prendre une décision, dans le temps imparti. Le livrable est un compte-rendu de décision, pas du code fusionné.

Entrée

$ARGUMENTS

• Ticket, obligatoire : une clé de suivi (p. ex. ENG-130) ou un identifiant local (p. ex. T-03) d'un ticket de type spike. Si ce n'est pas un spike, arrêtez-vous et dirigez vers /implement-task.
• --tasks <file> : le fichier de tâches local. S'il n'est pas fourni, cherchez le fichier *.tasks.md contenant le ticket dans le dossier RFC local ignoré par git du projet (p. ex. .rfcs/), puis docs/rfcs/.
• --branch <name> : nom de branche pour un prototype, si nécessaire. Sinon, <nom_utilisateur>/<slug_projet>/spike-<branche_tache>, en suivant la même règle de nommage que /implement-task.
• --unattended : lancé par un orchestrateur ; personne ne peut répondre aux questions. Ne demandez jamais ; lorsque vous auriez besoin de demander, arrêtez-vous et expliquez-le dans le rapport. Travaillez dans votre propre répertoire de travail (worktree).

Lisez le ticket à partir de l'outil de suivi s'il est publié (l'outil est la source de vérité pour son contenu), sinon à partir du fichier de tâches. Les fichiers RFC et de tâches locaux ne se trouvent que dans le dossier principal du projet : si vous êtes dans un worktree, trouvez-le avec git worktree list (première entrée) et lisez-les via le chemin absolu. Ne modifiez jamais de fichiers ni n'exécutez de commandes git dans le dossier principal, sauf pour écrire le compte-rendu de décision comme décrit ci-dessous.

1. Cadrer la question

Avant de rassembler quoi que ce soit, écrivez :

• La question, en une phrase à laquelle on peut répondre (« Est-ce que Postgres LISTEN/NOTIFY peut gérer 2 000 événements/s sur notre taille d'instance ? », pas « étudier l'eventing »).
• La décision qu'elle débloque et les tickets qui en dépendent.
• Les options entre lesquelles on doit trancher, y compris « ne rien faire » ou l'option la plus simple lorsqu'elle est plausible.
• Les critères de décision, tirés de la section DRIVE du RFC si possible (contraintes, valeurs, résultats essentiels), afin que les preuves soient jugées selon ce que l'équipe a déjà convenu comme important.
• Le temps imparti du ticket (par défaut : environ une journée de travail). Terminer signifie que la question est répondue ou que le temps imparti est écoulé, selon la première éventualité.

Si le ticket est trop vague pour cadrer une question, arrêtez-vous et signalez bloqué avec les questions qui nécessitent des réponses.

2. Rassembler les preuves, en commençant par les moins coûteuses

Arrêtez-vous dès que les preuves tranchent la question ; ne faites pas de recherche pour être exhaustif.

1. Le code existant : les patterns, contraintes, tentatives précédentes, commentaires et historique autour de la zone concernée (git log sur les chemins pertinents).
2. Les sources primaires : documentation officielle, journaux des modifications, notes de version, suivi des bogues des bibliothèques ou services impliqués. Privilégiez ces sources aux articles de blog. Si une compétence deep-research est disponible et que la question nécessite une recherche externe large, utilisez-la.
3. Mesurer : lorsque la lecture ne peut pas trancher (performance, compatibilité, « est-ce que cette API se comporte vraiment comme cela ? »), construisez le prototype ou benchmark le plus petit possible qui répond à la question, sur la branche du spike, à partir du dernier main. Il existe pour produire des preuves : aucun test au-delà de ce que la mesure nécessite, aucun polissage, et il n'est jamais fusionné. Poussez la branche afin que les preuves soient reproductibles, mais n'ouvrez pas de PR.

Gardez une trace de la façon dont vous savez chaque chose : mesuré (vous l'avez exécuté), documenté (une source primaire le dit) ou supposé (inférence). Citez les liens et les chemins de fichiers.

3. Décider quoi recommander

• Évaluez chaque option par rapport aux critères de décision, en utilisant les preuves.
• Recommandation d'une option, avec un niveau de confiance : élevé (mesuré ou bien documenté), moyen (documenté mais non testé dans notre contexte), faible (principalement par inférence).
• Lorsque la confiance est faible, préférez l'option la moins coûteuse à annuler, et indiquez quel signal vous ferait changer d'avis.
• Si le temps imparti s'est écoulé avant que la question ne soit répondue, dites-le clairement : rapportez ce qui est connu et recommandez la plus petite prochaine étape (un spike de suivi plus ciblé, ou un choix par défaut réversible pour avancer).

4. Proposer des modifications du backlog

La décision modifie généralement le plan. Proposez, n'appliquez pas :

• Tickets à ajouter, dans le même format que le fichier de tâches (titre, périmètre, fichiers, critères d'acceptation, dépendances), chacun d'un story point.
• Tickets à modifier (périmètre, critères ou dépendances) et tickets à supprimer, chacun avec la raison.
• Sections du RFC à mettre à jour.

5. Rédiger le compte-rendu et rapporter

1. Rédigez le compte-rendu de décision en utilisant templates/decision.md sous <nom-rfc>.<id-ticket>.decision.md à côté du fichier de tâches dans le dossier principal du projet (le seul fichier que vous y écrivez). C'est un fichier local non suivi, comme le RFC.
2. Si le ticket est publié, publiez un résumé court sur la tâche de suivi : la question, la recommandation et le niveau de confiance, ainsi que les preuves clés en trois à cinq lignes, clairement marquées comme proposée, en attente d'approbation.
3. Si vous travaillez directement avec l'utilisateur, définissez le statut du ticket sur decision-proposed dans le fichier de tâches, expliquez-lui la recommandation et demandez-lui d'approuver, de choisir une autre option ou de prolonger le spike. En mode non supervisé, laissez les statuts à l'orchestrateur.
4. Terminez par le rapport :

RESULTAT : decision-proposed | inconclusive | bloque
TICKET : <id local> / <clé suivi ou