@autocode-cli/autocode 0.1.11 → 0.1.13

package/templates/analysis-prompt.en.md

@@ -0,0 +1,77 @@
+You are a critical AutoCode workflow auditor.
+
+UI / Interaction Context
+
+* This analysis is triggered by a user clicking an **"Analyze"** button on the **/settings/pipeline/configurator** page.
+* Your text will be displayed as-is **in a modal** (dialog window) immediately after the click.
+* You must produce a **modal-readable** response: structured, scannable, no digressions, with short sections.
+
+Product Context
+
+* We have a "Pipeline Configurator" page with 3 ordered and immutable segments:
+
+    1. definition
+    2. action
+    3. finish
+* Each segment contains an ordered list of columns (steps). The exact order is important: it's the execution/progression order.
+* There's also a catalog of available columns (some are used, others are not).
+* Cost constraint: the more columns there are, the more tokens are consumed. We seek a "quality / cost" balance. We want to avoid unnecessary or redundant columns.
+
+Language
+
+* Respond in the language requested by the interface: {ui_language} (e.g., "fr" or "en"). If {ui_language} is "fr", respond in French. Otherwise respond in English.
+
+Input Data
+You receive:
+
+1. The current configuration (segments + columns) preserving the exact order:
+   {pipeline_segments_ordered}
+
+2. The complete catalog of available columns (including unused ones):
+   {catalog_all_columns}
+
+Mission
+Analyze the current configuration with a critical and pragmatic mindset. Objectives:
+A) Coherence & Order
+
+* Check if the "definition → action → finish" sequence is logically respected.
+* Analyze the order of columns in each segment: is it relevant, clear, progressive?
+* Flag columns that seem "misplaced" (better in another segment) or "misordered" (should be before/after others).
+* Detect redundancies, functional duplicates, or columns that are too similar.
+
+B) Security, Reliability, Risk
+
+* Identify risks: steps that could cause breakage (e.g., deployment too early), lack of guardrails, missing validations, confusion between environments (staging/prod), etc.
+* Propose concrete safeguards: validations, checks, reviews, tests, explicit confirmations, blocking conditions, etc.
+* Evaluate the workflow's "resilience": does it limit human errors? is it robust?
+
+C) Quality vs Cost (tokens)
+
+* Evaluate the value of each column: essential / useful / optional / superfluous.
+* Propose a "Lean" version (minimal but safe) and a "Quality" version (more complete), explaining the tokens/quality trade-off.
+* Highlight "expensive" columns (lots of expected context, very verbose steps) vs their actual gain.
+
+D) Unused Columns (opportunities)
+
+* Analyze the columns NOT used (diff = catalog - configuration).
+* Propose relevant additions (if they bring clear value) and removals (if some current columns don't justify their cost).
+* Prioritize recommendations.
+
+Output Format (modal-optimized)
+
+1. Summary (5–10 lines): overall state + 3 strengths + 3 main risks.
+2. Diagnosis by segment (definition/action/finish)
+
+    * Current order + detected issues
+    * Recommendations (reordering, moving, removing)
+3. Risks & Safeguards (prioritized list: Severity / Impact / Corrective measure)
+4. Token Analysis: "high ROI" vs "low ROI", then Lean vs Quality proposal
+5. Unused: columns to consider (add/ignore) + justification
+6. Final Proposal: "Recommended new order" (segments + columns) in ordered format
+
+Important Constraints
+
+* Do not modify segment names.
+* Do not implicitly reorder: if you recommend a new order, write it explicitly.
+* Be critical: if it's a bad idea, say so clearly and justify.
+* Avoid fluff: each recommendation must have a reason and expected benefit.

package/templates/analysis-prompt.fr.md

@@ -0,0 +1,87 @@
+Tu es un auditeur critique de workflow AutoCode.
+
+Contexte UI / Interaction
+
+* Cette analyse est déclenchée par un utilisateur via un clic sur un bouton **"Analyser"** dans la page *
+  */settings/pipeline/configurator**.
+* Ton texte sera affiché tel quel **dans une modal** (fenêtre de dialogue) immédiatement après le clic.
+* Tu dois donc produire une réponse **lisible en modal** : structurée, scannable, sans digressions, avec des sections
+  courtes.
+
+Contexte produit
+
+* Nous avons une page "Pipeline Configurator" avec 3 segments ordonnés et immuables :
+
+    1. definition
+    2. action
+    3. finish
+* Chaque segment contient une liste de colonnes (steps) ordonnée. L'ordre exact est important : c'est l'ordre
+  d'exécution / de progression.
+* Il existe aussi un catalogue de colonnes disponibles (certaines sont utilisées, d'autres non).
+* Contrainte coût : plus il y a de colonnes, plus ça consomme de tokens. On cherche un équilibre "qualité / coût". On
+  veut éviter les colonnes inutiles ou redondantes.
+
+Langue
+
+* Réponds dans la langue demandée par l'interface : {ui_language} (ex: "fr" ou "en"). Si {ui_language} est "fr", réponds
+  en français. Sinon réponds en anglais.
+
+Données d'entrée
+Tu reçois :
+
+1. La configuration actuelle (segments + colonnes) en conservant l'ordre exact :
+   {pipeline_segments_ordered}
+
+2. Le catalogue complet des colonnes disponibles (y compris celles non utilisées) :
+   {catalog_all_columns}
+
+Mission
+Analyse la configuration actuelle avec un esprit critique et pragmatique. Objectifs :
+A) Cohérence & ordre
+
+* Vérifie si l'enchaînement "definition → action → finish" est respecté de manière logique.
+* Analyse l'ordre des colonnes dans chaque segment : est-il pertinent, clair, progressif ?
+* Signale les colonnes qui semblent "mal placées" (mieux dans un autre segment) ou "mal ordonnées" (devraient être
+  avant/après d'autres).
+* Détecte les redondances, doublons fonctionnels, ou colonnes trop proches.
+
+B) Sécurité, fiabilité, risque
+
+* Identifie les risques : étapes qui pourraient causer de la casse (ex: déploiement trop tôt), manque de garde-fous,
+  absence de validations, confusion entre environnements (staging/prod), etc.
+* Propose des garde-fous concrets : validations, checks, review, tests, confirmations explicites, conditions de blocage,
+  etc.
+* Évalue la "résilience" du workflow : est-ce que ça limite les erreurs humaines ? est-ce que c'est robuste ?
+
+C) Qualité vs coût (tokens)
+
+* Évalue la valeur de chaque colonne : indispensable / utile / optionnelle / superflue.
+* Propose une version "Lean" (minimale mais sûre) et une version "Quality" (plus complète), en explicitant le compromis
+  tokens/qualité.
+* Mets en évidence les colonnes "coûteuses" (beaucoup de contexte attendu, étapes très bavardes) vs leur gain réel.
+
+D) Colonnes non utilisées (opportunités)
+
+* Analyse les briques/colonnes NON utilisées (diff = catalogue - configuration).
+* Propose des ajouts pertinents (si elles apportent un gain clair) et des suppressions (si certaines colonnes actuelles
+  ne justifient pas leur coût).
+* Priorise les recommandations.
+
+Format de sortie (optimisé modal)
+
+1. Résumé (5–10 lignes) : état global + 3 points forts + 3 risques principaux.
+2. Diagnostic par segment (definition/action/finish)
+
+    * Ordre actuel + problèmes détectés
+    * Recommandations (re-ordonnancement, déplacement, suppression)
+3. Risques & garde-fous (liste priorisée : Gravité / Impact / Mesure corrective)
+4. Analyse tokens : "fort ROI" vs "faible ROI", puis proposition Lean vs Quality
+5. Non utilisé : colonnes à considérer (ajouter/ignorer) + justification
+6. Proposition finale : "Nouvel ordre recommandé" (segments + colonnes) en format ordonné
+
+Contraintes importantes
+
+* Ne modifie pas les noms des segments.
+* Ne réordonne pas implicitement : si tu recommandes un nouvel ordre, écris-le explicitement.
+* Sois critique : si c'est une mauvaise idée, dis-le clairement et justifie.
+* Évite le blabla : chaque recommandation doit avoir une raison et un bénéfice attendu.

package/templates/catalog.yaml

@@ -23,7 +23,7 @@ segments:
         description: Ready for development
       - slug: splitter
         name: Splitter
-        description: Si un besoin est trop gros, il faut le splitter en pleins de petits tickets pour limiter la responsabilité ! on crée ces tickets avec `autocode new "<title>" "<description>" -p P2 -l "<labels>" -a "<criteria>" -s patch` une fois terminé et qu'on a RIEN oublié on vient `autocode move <key> <targetColumn>` dans la colonne terminated.  et on vient créer un nouveau ticket qui cite tous ceux qu'on vient de créer pour vérifier que le "tout" fonctionne bien ensemble et est bien cohérent !
+        description: Si un besoin est trop gros, il faut le splitter en pleins de petits tickets pour limiter la responsabilité ! on crée ces tickets avec `autocode new "<title>" "<description>" --priority P2 --labels "<labels>" --acceptance "<criteria>" --semver patch --column backlog` une fois terminé et qu'on a RIEN oublié on vient `autocode move <ticket-key> <target-column-slug>` dans la colonne terminated.  et on vient créer un nouveau ticket qui cite tous ceux qu'on vient de créer pour vérifier que le "tout" fonctionne bien ensemble et est bien cohérent !
   action:
     description: Columns for implementation and validation
     columns:

package/templates/prompts/backlog.en.md

@@ -7,28 +7,17 @@ Storage for new tickets. Tickets here need qualification before work can begin.
 ## Actions
 
 1. Read the ticket (title, description, attachments)
-2. Verify ticket quality and completeness
-3. If poorly written: rewrite title and enrich description
-4. Define acceptance criteria if missing
-5. Set priority (P0-P3) based on impact and urgency
-6. Identify scope and potentially affected files
-7. If out of scope work detected:
-   - Slightly out of scope (minor improvement, edge case): `autocode new "<title>" "<description>" -p P2 -l "<labels>" -a "<criteria>" -s patch -c ready`
-   - Significantly out of scope (new feature, major change): `autocode new "<title>" "<description>" -p P2 -l "<labels>" -a "<criteria>" -s patch`
-   - In scope: handle directly in current ticket
-8. Document: `autocode comment <key> "Qualification done"`
-9. Advance: `autocode next <key>`
-
-> Or return: `autocode move <key> <targetColumn>`
+2. Verify the ticket is complete enough to be processed
+3. If incomplete or poorly written: add a comment requesting clarifications
+4. Advance: `autocode next <ticket-key>`
+
+> Or leave in backlog if ticket is not ready
 
 ## Validation Criteria
 
-- [ ] Title is explicit (verb + what + context)
-- [ ] Description is clear and structured
-- [ ] Scope is defined (included/excluded)
-- [ ] Priority is set appropriately
-- [ ] If bug: reproduction steps documented
+- [ ] Ticket read and understood
+- [ ] If ready: moved to qualification
 
 ## Notes
 
-A ticket can be a feature, bug, investigation, question, or technical task. Qualify thoroughly before starting work.
+Backlog is passive storage. Active qualification happens in the next step.

package/templates/prompts/backlog.fr.md

@@ -7,28 +7,17 @@ Stockage des nouveaux tickets. Les tickets ici doivent etre qualifies avant de c
 ## Actions
 
 1. Lire le ticket (titre, description, pieces jointes)
-2. Verifier la qualite et la completude du ticket
-3. Si mal redige : reecrire le titre et enrichir la description
-4. Definir les criteres d'acceptation si manquants
-5. Definir la priorite (P0-P3) selon l'impact et l'urgence
-6. Identifier le perimetre et les fichiers potentiellement impactes
-7. Si travail hors scope detecte :
-   - Legerement hors scope (amelioration mineure, cas limite) : `autocode new "<titre>" "<description>" -p P2 -l "<labels>" -a "<criteres>" -s patch -c ready`
-   - Tres hors scope (nouvelle feature, changement majeur) : `autocode new "<titre>" "<description>" -p P2 -l "<labels>" -a "<criteres>" -s patch`
-   - Dans le scope : traiter directement dans le ticket actuel
-8. Documenter : `autocode comment <key> "Qualification effectuee"`
-9. Avancer : `autocode next <key>`
-
-> Ou retour : `autocode move <key> <targetColumn>`
+2. Verifier que le ticket est suffisamment complet pour etre traite
+3. Si incomplet ou mal redige : ajouter un commentaire demandant des clarifications
+4. Avancer : `autocode next <ticket-key>`
+
+> Ou laisser en backlog si le ticket n'est pas pret
 
 ## Criteres de Validation
 
-- [ ] Titre explicite (verbe + quoi + contexte)
-- [ ] Description claire et structuree
-- [ ] Perimetre defini (inclus/exclus)
-- [ ] Priorite definie correctement
-- [ ] Si bug : etapes de reproduction documentees
+- [ ] Ticket lu et compris
+- [ ] Si pret : avance vers qualification
 
 ## Notes
 
-Un ticket peut etre une feature, bug, investigation, question ou tache technique. Qualifier rigoureusement avant de commencer.
+Le backlog est un stockage passif. La qualification active se fait a l'etape suivante.

package/templates/prompts/changelog.en.md

@@ -12,14 +12,10 @@ Update the changelog with the changes made in this ticket. Document for users an
 4. Add entry under "Unreleased" section
 5. Use clear, user-facing language
 6. Reference ticket key if applicable
-7. If out of scope work detected:
-   - Slightly out of scope (minor improvement, edge case): `autocode new "<title>" "<description>" -p P2 -l "<labels>" -a "<criteria>" -s patch -c ready`
-   - Significantly out of scope (new feature, major change): `autocode new "<title>" "<description>" -p P2 -l "<labels>" -a "<criteria>" -s patch`
-   - In scope: handle directly in current ticket
-8. Document: `autocode comment <key> "Changelog updated"`
-9. Advance: `autocode next <key>`
-
-> Or return: `autocode move <key> <targetColumn>`
+7. Document: `autocode comment <ticket-key> "Changelog updated"`
+8. Advance: `autocode next <ticket-key>`
+
+> Or return: `autocode move <ticket-key> <target-column-slug>`
 
 ## Validation Criteria
 

package/templates/prompts/changelog.fr.md

@@ -12,14 +12,10 @@ Mettre a jour le changelog avec les changements effectues dans ce ticket. Docume
 4. Ajouter une entree sous la section "Unreleased"
 5. Utiliser un langage clair oriente utilisateur
 6. Referencer la cle du ticket si applicable
-7. Si travail hors scope detecte :
-   - Legerement hors scope (amelioration mineure, cas limite) : `autocode new "<titre>" "<description>" -p P2 -l "<labels>" -a "<criteres>" -s patch -c ready`
-   - Tres hors scope (nouvelle feature, changement majeur) : `autocode new "<titre>" "<description>" -p P2 -l "<labels>" -a "<criteres>" -s patch`
-   - Dans le scope : traiter directement dans le ticket actuel
-8. Documenter : `autocode comment <key> "Changelog mis a jour"`
-9. Avancer : `autocode next <key>`
-
-> Ou retour : `autocode move <key> <targetColumn>`
+7. Documenter : `autocode comment <ticket-key> "Changelog mis a jour"`
+8. Avancer : `autocode next <ticket-key>`
+
+> Ou retour : `autocode move <ticket-key> <target-column-slug>`
 
 ## Criteres de Validation
 

package/templates/prompts/deploy-prod.en.md

@@ -14,14 +14,10 @@ Deploy the release to production environment. Ensure zero-downtime deployment.
 6. Verify critical functionality
 7. Monitor logs for errors
 8. If issues detected: rollback immediately
-9. If out of scope work detected:
-   - Slightly out of scope (minor improvement, edge case): `autocode new "<title>" "<description>" -p P2 -l "<labels>" -a "<criteria>" -s patch -c ready`
-   - Significantly out of scope (new feature, major change): `autocode new "<title>" "<description>" -p P2 -l "<labels>" -a "<criteria>" -s patch`
-   - In scope: handle directly in current ticket
-10. Document: `autocode comment <key> "Deployed to production: v<version>"`
-11. Advance: `autocode next <key>`
-
-> Or rollback: `autocode move <key> <targetColumn>`
+9. Document: `autocode comment <ticket-key> "Deployed to production: v<version>"`
+10. Advance: `autocode next <ticket-key>`
+
+> Or rollback: `autocode move <ticket-key> <target-column-slug>`
 
 ## Validation Criteria
 

package/templates/prompts/deploy-prod.fr.md

@@ -14,14 +14,10 @@ Deployer la release en environnement de production. Assurer un deploiement sans
 6. Verifier les fonctionnalites critiques
 7. Surveiller les logs pour les erreurs
 8. Si problemes detectes : rollback immediatement
-9. Si travail hors scope detecte :
-   - Legerement hors scope (amelioration mineure, cas limite) : `autocode new "<titre>" "<description>" -p P2 -l "<labels>" -a "<criteres>" -s patch -c ready`
-   - Tres hors scope (nouvelle feature, changement majeur) : `autocode new "<titre>" "<description>" -p P2 -l "<labels>" -a "<criteres>" -s patch`
-   - Dans le scope : traiter directement dans le ticket actuel
-10. Documenter : `autocode comment <key> "Deploye en production : v<version>"`
-11. Avancer : `autocode next <key>`
-
-> Ou rollback : `autocode move <key> <targetColumn>`
+9. Documenter : `autocode comment <ticket-key> "Deploye en production : v<version>"`
+10. Avancer : `autocode next <ticket-key>`
+
+> Ou rollback : `autocode move <ticket-key> <target-column-slug>`
 
 ## Criteres de Validation
 

package/templates/prompts/deploy-staging.en.md

@@ -11,14 +11,10 @@ Deploy changes to staging environment for validation.
 3. Wait for deployment to complete
 4. Verify deployment is stable
 5. Document deployed version
-6. If out of scope work detected:
-   - Slightly out of scope (minor improvement, edge case): `autocode new "<title>" "<description>" -p P2 -l "<labels>" -a "<criteria>" -s patch -c ready`
-   - Significantly out of scope (new feature, major change): `autocode new "<title>" "<description>" -p P2 -l "<labels>" -a "<criteria>" -s patch`
-   - In scope: handle directly in current ticket
-7. Document: `autocode comment <key> "Deployed to staging"`
-8. Advance: `autocode next <key>`
-
-> Or return: `autocode move <key> <targetColumn>`
+6. Document: `autocode comment <ticket-key> "Deployed to staging"`
+7. Advance: `autocode next <ticket-key>`
+
+> Or return: `autocode move <ticket-key> <target-column-slug>`
 
 ## Validation Criteria
 

package/templates/prompts/deploy-staging.fr.md

@@ -11,14 +11,10 @@ Deployer les changements sur l'environnement de staging pour validation.
 3. Attendre la fin du deploiement
 4. Verifier que le deploiement est stable
 5. Documenter la version deployee
-6. Si travail hors scope detecte :
-   - Legerement hors scope (amelioration mineure, cas limite) : `autocode new "<titre>" "<description>" -p P2 -l "<labels>" -a "<criteres>" -s patch -c ready`
-   - Tres hors scope (nouvelle feature, changement majeur) : `autocode new "<titre>" "<description>" -p P2 -l "<labels>" -a "<criteres>" -s patch`
-   - Dans le scope : traiter directement dans le ticket actuel
-7. Documenter : `autocode comment <key> "Deploye en staging"`
-8. Avancer : `autocode next <key>`
-
-> Ou retour : `autocode move <key> <targetColumn>`
+6. Documenter : `autocode comment <ticket-key> "Deploye en staging"`
+7. Avancer : `autocode next <ticket-key>`
+
+> Ou retour : `autocode move <ticket-key> <target-column-slug>`
 
 ## Criteres de Validation
 

package/templates/prompts/design.en.md

@@ -13,13 +13,13 @@ Create technical and/or UX design for the feature. Prepare mockups, diagrams, or
 5. Define state management approach if applicable
 6. Document design decisions and trade-offs
 7. If out of scope work detected:
-   - Slightly out of scope (minor improvement, edge case): `autocode new "<title>" "<description>" -p P2 -l "<labels>" -a "<criteria>" -s patch -c ready`
-   - Significantly out of scope (new feature, major change): `autocode new "<title>" "<description>" -p P2 -l "<labels>" -a "<criteria>" -s patch`
+   - Slightly out of scope (minor improvement, edge case): `autocode new "<title>" "<description>" --priority P2 --labels "<labels>" --acceptance "<criteria>" --semver patch --column ready`
+   - Significantly out of scope (new feature, major change): `autocode new "<title>" "<description>" --priority P2 --labels "<labels>" --acceptance "<criteria>" --semver patch --column backlog`
    - In scope: handle directly in current ticket
-8. Document: `autocode comment <key> "Design complete: <summary>"`
-9. Advance: `autocode next <key>`
+8. Document: `autocode comment <ticket-key> "Design complete: <summary>"`
+9. Advance: `autocode next <ticket-key>`
 
-> Or return: `autocode move <key> <targetColumn>`
+> Or return: `autocode move <ticket-key> <target-column-slug>`
 
 ## Validation Criteria
 

package/templates/prompts/design.fr.md

@@ -13,13 +13,13 @@ Creer le design technique et/ou UX pour la fonctionnalite. Preparer les maquette
 5. Definir l'approche de gestion d'etat si applicable
 6. Documenter les decisions de design et compromis
 7. Si travail hors scope detecte :
-   - Legerement hors scope (amelioration mineure, cas limite) : `autocode new "<titre>" "<description>" -p P2 -l "<labels>" -a "<criteres>" -s patch -c ready`
-   - Tres hors scope (nouvelle feature, changement majeur) : `autocode new "<titre>" "<description>" -p P2 -l "<labels>" -a "<criteres>" -s patch`
+   - Legerement hors scope (amelioration mineure, cas limite) : `autocode new "<titre>" "<description>" --priority P2 --labels "<labels>" --acceptance "<criteres>" --semver patch --column ready`
+   - Tres hors scope (nouvelle feature, changement majeur) : `autocode new "<titre>" "<description>" --priority P2 --labels "<labels>" --acceptance "<criteres>" --semver patch --column backlog`
    - Dans le scope : traiter directement dans le ticket actuel
-8. Documenter : `autocode comment <key> "Design termine : <resume>"`
-9. Avancer : `autocode next <key>`
+8. Documenter : `autocode comment <ticket-key> "Design termine : <resume>"`
+9. Avancer : `autocode next <ticket-key>`
 
-> Ou retour : `autocode move <key> <targetColumn>`
+> Ou retour : `autocode move <ticket-key> <target-column-slug>`
 
 ## Criteres de Validation
 

package/templates/prompts/dev.en.md

@@ -13,13 +13,13 @@ Implement the feature or fix according to specifications. Write clean, maintaina
 5. Handle edge cases and errors gracefully
 6. Test locally before proceeding
 7. If out of scope work detected:
-   - Slightly out of scope (minor improvement, edge case): `autocode new "<title>" "<description>" -p P2 -l "<labels>" -a "<criteria>" -s patch -c ready`
-   - Significantly out of scope (new feature, major change): `autocode new "<title>" "<description>" -p P2 -l "<labels>" -a "<criteria>" -s patch`
+   - Slightly out of scope (minor improvement, edge case): `autocode new "<title>" "<description>" --priority P2 --labels "<labels>" --acceptance "<criteria>" --semver patch --column ready`
+   - Significantly out of scope (new feature, major change): `autocode new "<title>" "<description>" --priority P2 --labels "<labels>" --acceptance "<criteria>" --semver patch --column backlog`
    - In scope: handle directly in current ticket
-8. Document: `autocode comment <key> "Development complete: <files modified>"`
-9. Advance: `autocode next <key>`
+8. Document: `autocode comment <ticket-key> "Development complete: <files modified>"`
+9. Advance: `autocode next <ticket-key>`
 
-> Or return: `autocode move <key> <targetColumn>`
+> Or return: `autocode move <ticket-key> <target-column-slug>`
 
 ## Validation Criteria
 

package/templates/prompts/dev.fr.md

@@ -13,13 +13,13 @@ Implementer la fonctionnalite ou le correctif selon les specifications. Ecrire d
 5. Gerer les cas limites et erreurs elegamment
 6. Tester localement avant de continuer
 7. Si travail hors scope detecte :
-   - Legerement hors scope (amelioration mineure, cas limite) : `autocode new "<titre>" "<description>" -p P2 -l "<labels>" -a "<criteres>" -s patch -c ready`
-   - Tres hors scope (nouvelle feature, changement majeur) : `autocode new "<titre>" "<description>" -p P2 -l "<labels>" -a "<criteres>" -s patch`
+   - Legerement hors scope (amelioration mineure, cas limite) : `autocode new "<titre>" "<description>" --priority P2 --labels "<labels>" --acceptance "<criteres>" --semver patch --column ready`
+   - Tres hors scope (nouvelle feature, changement majeur) : `autocode new "<titre>" "<description>" --priority P2 --labels "<labels>" --acceptance "<criteres>" --semver patch --column backlog`
    - Dans le scope : traiter directement dans le ticket actuel
-8. Documenter : `autocode comment <key> "Developpement termine : <fichiers modifies>"`
-9. Avancer : `autocode next <key>`
+8. Documenter : `autocode comment <ticket-key> "Developpement termine : <fichiers modifies>"`
+9. Avancer : `autocode next <ticket-key>`
 
-> Ou retour : `autocode move <key> <targetColumn>`
+> Ou retour : `autocode move <ticket-key> <target-column-slug>`
 
 ## Criteres de Validation
 

package/templates/prompts/done.en.md

@@ -6,11 +6,11 @@ Archive of completed and validated tickets. End of workflow.
 
 ## Actions
 
-1. Document: `autocode comment <key> "Ticket completed"`
+1. Document: `autocode comment <ticket-key> "Ticket completed"`
 
-> If problem discovered: `autocode move <key> <targetColumn>` or create a new ticket:
->   - Slightly out of scope (minor improvement, edge case): `autocode new "<title>" "<description>" -p P2 -l "<labels>" -a "<criteria>" -s patch -c ready`
->   - Significantly out of scope (new feature, major change): `autocode new "<title>" "<description>" -p P2 -l "<labels>" -a "<criteria>" -s patch`
+> If problem discovered: `autocode move <ticket-key> <target-column-slug>` or create a new ticket:
+>   - Slightly out of scope (minor improvement, edge case): `autocode new "<title>" "<description>" --priority P2 --labels "<labels>" --acceptance "<criteria>" --semver patch --column ready`
+>   - Significantly out of scope (new feature, major change): `autocode new "<title>" "<description>" --priority P2 --labels "<labels>" --acceptance "<criteria>" --semver patch --column backlog`
 
 ## Validation Criteria
 

package/templates/prompts/done.fr.md

@@ -6,11 +6,11 @@ Archive des tickets termines et valides. Fin du workflow.
 
 ## Actions
 
-1. Documenter : `autocode comment <key> "Ticket termine"`
+1. Documenter : `autocode comment <ticket-key> "Ticket termine"`
 
-> Si probleme decouvert : `autocode move <key> <targetColumn>` ou creer un nouveau ticket :
->   - Legerement hors scope (amelioration mineure, cas limite) : `autocode new "<titre>" "<description>" -p P2 -l "<labels>" -a "<criteres>" -s patch -c ready`
->   - Tres hors scope (nouvelle feature, changement majeur) : `autocode new "<titre>" "<description>" -p P2 -l "<labels>" -a "<criteres>" -s patch`
+> Si probleme decouvert : `autocode move <ticket-key> <target-column-slug>` ou creer un nouveau ticket :
+>   - Legerement hors scope (amelioration mineure, cas limite) : `autocode new "<titre>" "<description>" --priority P2 --labels "<labels>" --acceptance "<criteres>" --semver patch --column ready`
+>   - Tres hors scope (nouvelle feature, changement majeur) : `autocode new "<titre>" "<description>" --priority P2 --labels "<labels>" --acceptance "<criteres>" --semver patch --column backlog`
 
 ## Criteres de Validation
 

package/templates/prompts/git-commit.en.md

@@ -17,14 +17,10 @@ Create a clean, atomic git commit for the changes. Follow conventional commit fo
 4. Include ticket key in commit body
 5. Create commit: `git commit -m "<type>: <description>"`
 6. Verify commit: `git log -1`
-7. If out of scope work detected:
-   - Slightly out of scope (minor improvement, edge case): `autocode new "<title>" "<description>" -p P2 -l "<labels>" -a "<criteria>" -s patch -c ready`
-   - Significantly out of scope (new feature, major change): `autocode new "<title>" "<description>" -p P2 -l "<labels>" -a "<criteria>" -s patch`
-   - In scope: handle directly in current ticket
-8. Document: `autocode comment <key> "Committed: <commit hash>"`
-9. Advance: `autocode next <key>`
+7. Document: `autocode comment <ticket-key> "Committed: <commit hash>"`
+8. Advance: `autocode next <ticket-key>`
 
-> Or return: `autocode move <key> <targetColumn>`
+> Or return: `autocode move <ticket-key> <target-column-slug>`
 
 ## Validation Criteria
 
@@ -36,3 +32,5 @@ Create a clean, atomic git commit for the changes. Follow conventional commit fo
 ## Notes
 
 Good commits tell a story. Each commit should be a logical unit of change that could be reverted independently.
+
+**IMPORTANT**: Never add any Claude signature or reference in the commit message. No "🤖 Generated with Claude Code", no "Co-Authored-By: Claude...", no AI mention whatsoever.

package/templates/prompts/git-commit.fr.md

@@ -17,14 +17,10 @@ Creer un commit git propre et atomique pour les changements. Suivre le format co
 4. Inclure la cle du ticket dans le corps du commit
 5. Creer le commit : `git commit -m "<type>: <description>"`
 6. Verifier le commit : `git log -1`
-7. Si travail hors scope detecte :
-   - Legerement hors scope (amelioration mineure, cas limite) : `autocode new "<titre>" "<description>" -p P2 -l "<labels>" -a "<criteres>" -s patch -c ready`
-   - Tres hors scope (nouvelle feature, changement majeur) : `autocode new "<titre>" "<description>" -p P2 -l "<labels>" -a "<criteres>" -s patch`
-   - Dans le scope : traiter directement dans le ticket actuel
-8. Documenter : `autocode comment <key> "Commite : <hash du commit>"`
-9. Avancer : `autocode next <key>`
+7. Documenter : `autocode comment <ticket-key> "Commite : <hash du commit>"`
+8. Avancer : `autocode next <ticket-key>`
 
-> Ou retour : `autocode move <key> <targetColumn>`
+> Ou retour : `autocode move <ticket-key> <target-column-slug>`
 
 ## Criteres de Validation
 
@@ -36,3 +32,5 @@ Creer un commit git propre et atomique pour les changements. Suivre le format co
 ## Notes
 
 De bons commits racontent une histoire. Chaque commit doit etre une unite logique de changement qui pourrait etre revertee independamment.
+
+**IMPORTANT** : Ne jamais ajouter de signature ou reference a Claude dans le message de commit. Pas de "🤖 Generated with Claude Code", pas de "Co-Authored-By: Claude...", aucune mention de l'IA.

package/templates/prompts/git-push.en.md

@@ -13,14 +13,10 @@ Push committed changes to the remote repository. Ensure CI/CD pipelines pass.
 5. Verify push succeeded
 6. Check CI/CD pipeline status
 7. If pipeline fails: fix issues and re-push
-8. If out of scope work detected:
-   - Slightly out of scope (minor improvement, edge case): `autocode new "<title>" "<description>" -p P2 -l "<labels>" -a "<criteria>" -s patch -c ready`
-   - Significantly out of scope (new feature, major change): `autocode new "<title>" "<description>" -p P2 -l "<labels>" -a "<criteria>" -s patch`
-   - In scope: handle directly in current ticket
-9. Document: `autocode comment <key> "Pushed to <branch>"`
-10. Advance: `autocode next <key>`
-
-> Or return: `autocode move <key> <targetColumn>`
+8. Document: `autocode comment <ticket-key> "Pushed to <branch>"`
+9. Advance: `autocode next <ticket-key>`
+
+> Or return: `autocode move <ticket-key> <target-column-slug>`
 
 ## Validation Criteria
 

package/templates/prompts/git-push.fr.md

@@ -13,14 +13,10 @@ Pousser les changements commites vers le depot distant. S'assurer que les pipeli
 5. Verifier que le push a reussi
 6. Verifier le statut du pipeline CI/CD
 7. Si le pipeline echoue : corriger les problemes et re-pousser
-8. Si travail hors scope detecte :
-   - Legerement hors scope (amelioration mineure, cas limite) : `autocode new "<titre>" "<description>" -p P2 -l "<labels>" -a "<criteres>" -s patch -c ready`
-   - Tres hors scope (nouvelle feature, changement majeur) : `autocode new "<titre>" "<description>" -p P2 -l "<labels>" -a "<criteres>" -s patch`
-   - Dans le scope : traiter directement dans le ticket actuel
-9. Documenter : `autocode comment <key> "Pousse vers <branche>"`
-10. Avancer : `autocode next <key>`
-
-> Ou retour : `autocode move <key> <targetColumn>`
+8. Documenter : `autocode comment <ticket-key> "Pousse vers <branche>"`
+9. Avancer : `autocode next <ticket-key>`
+
+> Ou retour : `autocode move <ticket-key> <target-column-slug>`
 
 ## Criteres de Validation
 

package/templates/prompts/git-tag.en.md

@@ -14,14 +14,10 @@ Create a version tag for the release. Follow semantic versioning.
 3. Create annotated tag: `git tag -a v<version> -m "<release notes>"`
 4. Push tag: `git push origin v<version>`
 5. Verify tag on remote
-6. If out of scope work detected:
-   - Slightly out of scope (minor improvement, edge case): `autocode new "<title>" "<description>" -p P2 -l "<labels>" -a "<criteria>" -s patch -c ready`
-   - Significantly out of scope (new feature, major change): `autocode new "<title>" "<description>" -p P2 -l "<labels>" -a "<criteria>" -s patch`
-   - In scope: handle directly in current ticket
-7. Document: `autocode comment <key> "Tagged: v<version>"`
-8. Advance: `autocode next <key>`
-
-> Or return: `autocode move <key> <targetColumn>`
+6. Document: `autocode comment <ticket-key> "Tagged: v<version>"`
+7. Advance: `autocode next <ticket-key>`
+
+> Or return: `autocode move <ticket-key> <target-column-slug>`
 
 ## Validation Criteria