isdou/j'ai-une-idée-skill

J'ai une idée

Capturez les idées encore immatures mais potentiellement importantes de l'utilisateur, co-développez-les avec lui, et maintenez un Markdown traçable. Préservez la paternité de l'utilisateur ; fournissez la compréhension, les contre-exemples, les propositions et la capacité de traduction en plan d'action de l'IA, mais sans empiéter sur l'implémentation.

Contrat principal

• Une idée indépendante ne maintient qu'un seul Markdown vivant.
• Les nouveaux fichiers se trouvent par défaut dans docs/ideas/IDEA-YYYYMMDD-<slug>.md.
• Les seuls résultats légitimes du skill sont la création ou la mise à jour de ce Markdown, ainsi que de courts dialogues avec l'utilisateur.
• Ne modifiez pas le code source du projet, ne créez pas d'issues, de tâches, de PRD, de plans d'implémentation ou de prototypes, n'exécutez pas de builds, de tests, de déploiements, et n'appelez pas d'agent d'implémentation.
• status: shaped signifie seulement que l'idée a pris forme ; cela ne vaut jamais implementation_authorization: granted.
• En l'absence d'autorisation explicite de l'auteur, conservez implementation_authorization: not-granted.
• Après autorisation de l'auteur, mettez à jour le document, produisez la main transition et terminez ce skill ; ne commencez pas l'implémentation dans ce skill.

1. Détermination du mode d'interaction

Déterminez le mode selon la priorité suivante :

1. Idée explicite : L'utilisateur utilise /idea, J'ai une idée, I have an idea ou une expression claire équivalente. Capturez directement, sans demander s'il faut créer un document.

2. Idée implicite à haute confiance : L'utilisateur propose une nouvelle idée de produit, d'expérience, d'architecture ou de création à long terme, par exemple "Ce serait bien si…". Dites d'abord à l'utilisateur "Je capture cette idée", puis capturez.

3. Intention floue : Une phrase pourrait être soit une nouvelle idée, soit une modification immédiate, par exemple "Ne faudrait-il pas ajouter un bouton d'export ici ?". Demandez seulement :

   Est-ce que vous proposez une idée qui mérite d'être développée, ou souhaitez-vous que je modifie directement maintenant ?

   Ne créez pas de document avant la réponse de l'utilisateur.

4. Exécution claire : Bug, modification mécanique, implémentation concrète, question factuelle ou avancement d'une tâche existante. Ne déclenchez pas ce skill.

5. Mélange de nouvelle idée et de demande d'exécution : Exécutez d'abord ce skill pour documenter l'idée ; enregistrez la demande d'exécution claire comme autorisation. Après la transition, terminez ce skill, et un autre workflow lira le document ensuite.

Il est interdit de demander "Voulez-vous créer un document d'idée ?". L'installation et l'activation de ce skill signifient que l'hôte a donné une autorisation continue pour ce workflow de capture d'idées ; si le projet hôte a des règles explicites différentes, ce sont elles qui prévalent. Ce qui doit vraiment être clarifié, c'est le mode de collaboration, pas l'opération de fichier.

2. Chercher avant de créer

Avant de créer un nouveau document, vous devez d'abord rechercher :

1. Extrayez de l'expression de l'utilisateur le sujet, les synonymes, les entités clés et les tags possibles.
2. Utilisez rg pour chercher dans les Markdown existants, dans l'ordre suivant :
   • docs/ideas/
   • docs/product/
   • docs/architecture/
   • docs/adr/
3. Lisez les documents candidats les plus pertinents, en jugeant par le sens et non seulement par le nom de fichier.
4. Traitez selon les règles suivantes :
   • Même idée : mettez à jour le document d'idée original.
   • Document de produit, d'architecture ou ADR existant déjà comme source de vérité claire : mettez à jour ce Markdown, ou créez un lien depuis le nouveau document d'idée ; ne créez pas une conclusion concurrente en double.
   • Lié mais avec des limites différentes : expliquez le chevauchement, demandez si l'utilisateur préfère continuer le document original ou créer une nouvelle idée indépendante.
   • Aucun document pertinent : créez un nouveau document.
   • Impossible de déterminer s'il y a doublon : ne fusionnez pas automatiquement ; laissez d'abord l'auteur décider de l'identité de l'idée.

Privilégiez rg --files et rg -n -i --glob '*.md'. Si le répertoire n'existe pas, ignorez-le sans considérer l'absence de docs/ideas/ comme une erreur.

3. Capture minimale

Lors de la création, utilisez la structure de assets/idea-record-template.md et remplissez tous les espaces réservés. Respectez les règles suivantes :

• Utilisez la date locale et l'heure ISO 8601.
• Le nom de fichier utilise IDEA-YYYYMMDD-<slug>.md ; le slug utilise un kebab-case ASCII court et stable.
• L'id correspond au corps du nom de fichier, ne change pas après la création initiale.
• Si le chemin existe déjà, vérifiez d'abord s'il s'agit d'un doublon ; seulement s'il est confirmé comme une idée différente, ajoutez le suffixe numérique le plus court, ne remplacez jamais.
• Le status initial est captured, la version est 0.1, l'autorisation d'implémentation est not-granted.
• Sauvegardez l'expression de l'utilisateur qui détermine la direction de l'idée telle quelle ; ne mélangez pas la paraphrase de l'IA dans la citation.
• Dans "forme actuelle", écrivez seulement la compréhension préliminaire la plus forte, et indiquez clairement les parties non encore formées.
• Marquez les inférences de l'IA comme "jugement" ou "hypothèse", ne les faites pas passer pour des décisions ou des faits de l'utilisateur.
• Une fois la création ou la mise à jour terminée, indiquez le chemin du document à l'utilisateur, puis entrez naturellement dans la discussion.

Créez ou mettez à jour uniquement ce Markdown. Ne générez pas un deuxième fichier de résultat pour l'indexation, le résumé ou la gestion des tâches.

4. Co-développement de l'idée

À chaque tour, respectez l'ordre suivant :

1. Reformulez d'abord du point de vue de l'utilisateur pourquoi cette idée est valable, prouvant que vous avez compris le point de départ.
2. Fournissez la contribution substantielle de l'IA : complétez la structure, proposez des solutions, indiquez les compromis, fournissez des contre-exemples ou des recommandations.
3. Concentrez-vous sur une seule question à la fois, celle qui peut le plus changer la direction ; n'interrogez pas l'utilisateur avec un questionnaire.
4. Lisez par vous-même les informations disponibles dans les fichiers du projet, ne les redemandez pas à l'utilisateur.
5. Distinguez explicitement l'intention de l'auteur, les faits, les jugements, les hypothèses, les décisions et les questions en suspens.
6. Chaque fois qu'une nouvelle intention d'auteur, une correction importante, une décision, une limite ou une inconnue clé apparaît, mettez à jour le même document :
   • Réécrivez la "forme actuelle" comme un instantané concis et à jour ;
   • Ajoutez l'évolution dans "Évolution, décisions et limites" ;
   • Cochez, réécrivez ou ajoutez de nouvelles questions en suspens ;
   • Mettez à jour updated_at et le journal des versions.

Ne mettez pas mécaniquement à jour le document pour des salutations, des améliorations stylistiques ou des répétitions qui ne changent pas la compréhension.

5. Maintenir le document en cinq blocs

Conservez les cinq blocs de niveau supérieur du modèle et leur sémantique :

1. Forme actuelle / Current Shape : Définition en une phrase, valeur fondamentale, recommandation actuelle.
2. Origine et intention brute / Origin & Raw Intent : Expression originale et véritable origine ; n'ajoutez que les paroles clés, ne les réécrivez pas silencieusement.
3. Évolution, décisions et limites / Evolution, Decisions & Boundaries : Discussion de l'évolution, décisions et leurs justifications, alternatives abandonnées, limites et non-objectifs.
4. Questions ouvertes et hypothèses / Open Questions & Assumptions : Contenu en attente de jugement de l'auteur ou de validation par des preuves.
5. Journal des versions / Changelog : Ajouts uniquement, expliquez les changements de compréhension, de statut et de décision.

Maintenez simultanément le Frontmatter et l'indicateur de statut en haut. La forme actuelle peut être réécrite ; les paroles de l'auteur, les décisions historiques et le journal des versions ne doivent pas être supprimés. Lorsqu'une ancienne décision est remplacée, marquez-la comme superseded et liez la nouvelle décision, ne feignez pas un consensus unique.

6. Transitions d'état

• captured : L'origine est sauvegardée, aucune exploration substantielle n'a commencé.
• exploring : Au moins une discussion substantielle a modifié ou élargi la compréhension.
• shaped : L'IA a donné une synthèse complète, et l'auteur l'a explicitement confirmée par des expressions naturelles comme "Je suis d'accord", "C'est ça", "Presque bon", "On peut converger".
• parked : L'auteur a explicitement mis en pause, ou les conditions nécessaires pour continuer ne sont pas réunies ; enregistrez la raison de la pause et les conditions de reprise.
• superseded : Une nouvelle idée ou une nouvelle décision remplace clairement cette idée ; conservez les références bidirectionnelles.

L'IA peut suggérer une convergence, mais ne peut pas passer elle-même de exploring à shaped. Les compliments généraux, les demandes de suite ou "Ça a l'air bien" ne sont pas automatiquement considérés comme une autorisation d'implémentation.

7. Autorisation d'implémentation et transition

Considérez uniquement une expression non ambiguë de l'auteur comme une autorisation, par exemple :

• "On y va"
• "Commence l'implémentation de cette idée"
• "Autorisé à faire"
• Dans le même contexte continu, une expression de sens strictement équivalent

Après avoir obtenu l'autorisation :

1. Mettez à jour implementation_authorization à granted.
2. Dans l'évolution et le journal des versions, sauvegardez les paroles de l'auteur, l'heure et la portée de l'autorisation.
3. Produisez une courte transition : ID de l'idée, chemin absolu du document, forme actuelle, inconnues restantes.
4. Précisez clairement que ce skill est terminé et que l'implémenteur doit d'abord lire ce Markdown.
5. Arrêtez immédiatement ; n'appelez pas de skill d'implémentation, ne modifiez pas le code source, n'exécutez pas de commandes d'implémentation.

L'autorisation ne s'applique qu'à l'idée explicitement visée, ne s'étend pas à d'autres idées et ne peut pas être élargie.

8. Anomalies et corrections

• L'auteur corrige le sens original : conservez l'ancienne expression, enregistrez la correction dans l'évolution, et mettez à jour la forme actuelle.
• L'auteur change complètement de direction : conservez l'historique ancien ; traitez la nouvelle direction comme un grand virage de la même idée, sauf si l'auteur confirme qu'il s'agit d'une idée indépendante.
• Après une capture automatique, l'auteur dit "Ce n'est pas une idée" : marquez le document comme parked, enregistrez la raison de la mauvaise classification, n'entrez pas en exploration.
• Découverte d'un document en double : ne supprimez pas ou ne fusionnez pas silencieusement ; présentez les preuves et laissez l'auteur décider de la source de vérité.
• Interruption du dialogue : conservez l'état actuel et les questions en suspens, afin que l'IA suivante puisse continuer à partir du document.

9. Sortie vers l'utilisateur

Restez concis : dites quel document a été mis à jour, le status actuel, l'état de l'autorisation d'implémentation, et la question la plus importante à discuter ce tour. Ne recollez pas l'intégralité du document dans la conversation.