g-ki/agent-skills

Pensée Productive

Facilitez une session de conception structurée en utilisant le modèle de Pensée Productive de Tim Hurson, puis rédigez-la éventuellement sous forme de RFC.

Entrée

$ARGUMENTS

• Si l'entrée commence par rfc, lancez le mode RFC. Tout ce qui suit est un titre ou un chemin de sortie facultatif.
• Sinon, lancez le mode interactif, en traitant l'entrée comme l'énoncé du problème. Si elle est vide, demandez à l'utilisateur de décrire le problème en une ou deux phrases avant de faire quoi que ce soit d'autre.

Comment faciliter

• Ancrez tout dans le code. Avant chaque étape, recherchez et lisez les fichiers, schémas, configurations et documents pertinents, et citez les chemins lorsque vous vous y appuyez. La valeur de cette session par rapport à une discussion sur un tableau blanc est que les conclusions reposent sur ce que le système fait réellement, alors vérifiez plutôt que de supposer. Pour des balayages larges sur de nombreux fichiers, déléguez à un sous-agent Explore afin que le contexte de la session reste concentré sur la discussion.
• Allégez la charge de l'utilisateur. Posez au maximum 5 questions par tour, et associez-les à vos propres réponses suggérées basées sur ce que vous avez trouvé, afin que l'utilisateur puisse répondre « oui, en grande partie, mais… » au lieu de partir d'une page blanche.
• Une étape par tour. Ouvrez chaque étape avec un en-tête comme Étape 2 sur 6 — Qu'est-ce que la réussite ?, effectuez l'étape, puis arrêtez-vous et attendez. Passez à l'étape suivante uniquement lorsque l'utilisateur est prêt ; laissez-le sauter, revenir ou se déplacer entre les étapes.
• Conservez un fichier de notes. Après chaque étape, ajoutez le résultat convenu dans <rfc-dir>/<slug>.notes.md (choisissez <rfc-dir> comme décrit dans le mode RFC, étape 3). Les sessions longues seront compactées ou reprises plus tard ; le fichier de notes permet au mode RFC, ou à une nouvelle session, de reprendre sans perdre les décisions. Informez l'utilisateur de son emplacement la première fois que vous le créez.

Les six étapes

1. Que se passe-t-il ?

Objectif : compréhension partagée de la réalité actuelle et de l'avenir cible. Explorez les implémentations existantes, les sites d'appel, les modèles de données et l'historique Git récent des zones concernées. Couvrez : le point de douleur ou le goulot d'étranglement (avec des preuves telles que des erreurs, des métriques ou du code), les modules et services impactés, qui est concerné, et à quoi ressemble un état « résolu ».

2. Qu'est-ce que la réussite ? (DRIVE)

Objectif : critères sur lesquels chaque option sera évaluée. Proposez un brouillon à partir de l'étape 1 et laissez l'utilisateur le corriger.

• Doit faire : ce que la solution doit accomplir
• Restrictions : contraintes dures (rétrocompatibilité, budgets de performance, pile technologique, conformité)
• Investissement : temps, personnes et complexité que l'équipe est prête à consacrer
• Valeurs : principes d'ingénierie qui départagent (simplicité, testabilité, …)
• Résultats essentiels : résultats non négociables, mesurables si possible

Capturez également les non-objectifs explicites.

3. Quelle est la question ?

Proposez 2 à 3 questions « Comment pourrions-nous… » qui cadrent le défi différemment, par exemple une étroite et une qui remet en question une hypothèse de l'étape 1. L'utilisateur choisit ou reformule l'une d'elles ; elle devient l'énoncé du problème pour le reste de la session.

4. Générer des réponses

Proposez 2 à 3 approches réellement distinctes, ancrées dans la base de code, et non des variations d'une même idée. Pour chacune : une courte esquisse, les fichiers ou modules qu'elle touche, et son risque principal. Retenez votre jugement à cette étape et invitez les idées de l'utilisateur.

5. Forger la solution

Évaluez chaque approche par rapport à DRIVE (un petit tableau fonctionne bien), recommandez-en une, et nommez le compromis que vous acceptez. Ensuite, renforcez-la : modes de défaillance, cas limites, préoccupations de migration, questions ouvertes. Enregistrez pourquoi les autres options ont été écartées ; cela deviendra « Alternatives envisagées ».

6. Aligner les ressources

Convenez de la forme de la livraison, et non des tickets individuels : phases ou jalons et ce que chacun rend démontrable, la partie la plus risquée à prouver en premier, la stratégie de feature flag et de migration, la stratégie de test, le déploiement et le rollback, et ce qu'il faut surveiller. La répartition détaillée des tickets viendra plus tard de /task-breakdown, qui fonctionne à partir de la RFC. Terminez en proposant de générer la RFC.

Mode RFC

1. Trouver la session : utilisez la conversation jusqu'à présent ainsi que le fichier de notes, s'il existe. S'il n'y a aucune session, dites-le et proposez d'en démarrer une : demandez l'énoncé du problème et commencez l'étape 1.
2. Étapes manquantes : listez lesquelles et demandez s'il faut les compléter maintenant ou rédiger la RFC avec ces sections marquées À DÉFINIR. N'inventez pas de décisions que l'utilisateur n'a pas prises.
3. Choisir l'emplacement de sortie. Les fichiers RFC, notes et tâches sont des documents de travail locaux du développeur : non suivis par défaut, non commités avec le code. Recherchez un dossier local existant, ignoré par Git, pour ceux-ci (vérifiez .gitignore et .git/info/exclude) et suivez sa convention de nommage. S'il n'y en a pas, proposez .rfcs/YYYY-MM-DD-<slug>.md et ajoutez .rfcs/ à .git/info/exclude, ce qui l'ignore localement sans modifier le .gitignore du dépôt. Utilisez un dossier suivi comme docs/rfcs/ uniquement si l'utilisateur dit que l'équipe commite les RFC.
4. Rédiger la RFC en utilisant templates/rfc.md, en remplissant chaque section à partir de la session et en reliant les affirmations sur la base de code aux chemins de fichiers.
5. Indiquez à l'utilisateur le chemin, et listez les éventuelles sections À DÉFINIR et les questions ouvertes.
6. Proposez l'étape suivante : /task-breakdown <rfc-path> pour transformer la RFC en tickets de 1 story point que l'équipe peut prendre en charge.