@autocode-cli/autocode 0.1.12 → 0.1.13

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 <ticket-key> "Qualification effectuee"`
-9. Avancer : `autocode next <ticket-key>`
-
-> Ou retour : `autocode move <ticket-key> <target-column-slug>`
+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/design.en.md

@@ -13,8 +13,8 @@ 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 <ticket-key> "Design complete: <summary>"`
 9. Advance: `autocode next <ticket-key>`

package/templates/prompts/design.fr.md

@@ -13,8 +13,8 @@ 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 <ticket-key> "Design termine : <resume>"`
 9. Avancer : `autocode next <ticket-key>`

package/templates/prompts/dev.en.md

@@ -13,8 +13,8 @@ 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 <ticket-key> "Development complete: <files modified>"`
 9. Advance: `autocode next <ticket-key>`

package/templates/prompts/dev.fr.md

@@ -13,8 +13,8 @@ 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 <ticket-key> "Developpement termine : <fichiers modifies>"`
 9. Avancer : `autocode next <ticket-key>`

package/templates/prompts/done.en.md

@@ -9,8 +9,8 @@ Archive of completed and validated tickets. End of workflow.
 1. Document: `autocode comment <ticket-key> "Ticket completed"`
 
 > 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>" -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`
 
 ## Validation Criteria
 

package/templates/prompts/done.fr.md

@@ -9,8 +9,8 @@ Archive des tickets termines et valides. Fin du workflow.
 1. Documenter : `autocode comment <ticket-key> "Ticket termine"`
 
 > 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>" -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`
 
 ## Criteres de Validation
 

package/templates/prompts/in-progress.en.md

@@ -12,8 +12,8 @@ Active development. Ticket is being worked on, code is being written.
 4. Implement the solution
 5. Test locally that it works
 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`
+   - 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
 7. Document: `autocode comment <ticket-key> "Work completed"`
 8. Advance: `autocode next <ticket-key>`

package/templates/prompts/in-progress.fr.md

@@ -12,8 +12,8 @@ Developpement actif. Le ticket est en cours de travail, le code est en cours d'e
 4. Implementer la solution
 5. Tester localement que ca fonctionne
 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`
+   - 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
 7. Documenter : `autocode comment <ticket-key> "Travail effectue"`
 8. Avancer : `autocode next <ticket-key>`

package/templates/prompts/qualification.en.md

@@ -13,8 +13,8 @@ Analyze and qualify the ticket requirement. Ensure the request is clear, feasibl
 5. Identify dependencies with other tickets or systems
 6. If clarification needed: add comment with questions
 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 <ticket-key> "Qualification complete: <summary>"`
 9. Advance: `autocode next <ticket-key>`

package/templates/prompts/qualification.fr.md

@@ -13,8 +13,8 @@ Analyser et qualifier le besoin du ticket. S'assurer que la demande est claire,
 5. Identifier les dependances avec d'autres tickets ou systemes
 6. Si clarification necessaire : ajouter un commentaire avec les questions
 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 <ticket-key> "Qualification terminee : <resume>"`
 9. Avancer : `autocode next <ticket-key>`

package/templates/prompts/retest-cypress.en.md

@@ -10,12 +10,8 @@ Re-run all automated E2E tests to ensure refactoring did not introduce regressio
 2. Compare results with pre-refactoring run
 3. If new failures: identify cause (test or code issue)
 4. Fix any regressions before proceeding
-5. 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
-6. Document: `autocode comment <ticket-key> "Retest Cypress OK"`
-7. Advance: `autocode next <ticket-key>`
+5. Document: `autocode comment <ticket-key> "Retest Cypress OK"`
+6. Advance: `autocode next <ticket-key>`
 
 > Or return: `autocode move <ticket-key> <target-column-slug>`
 

package/templates/prompts/retest-cypress.fr.md

@@ -10,12 +10,8 @@ Re-executer tous les tests E2E automatises pour s'assurer que le refactoring n'a
 2. Comparer les resultats avec l'execution pre-refactoring
 3. Si nouveaux echecs : identifier la cause (probleme de test ou de code)
 4. Corriger toute regression avant de continuer
-5. 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
-6. Documenter : `autocode comment <ticket-key> "Retest Cypress OK"`
-7. Avancer : `autocode next <ticket-key>`
+5. Documenter : `autocode comment <ticket-key> "Retest Cypress OK"`
+6. Avancer : `autocode next <ticket-key>`
 
 > Ou retour : `autocode move <ticket-key> <target-column-slug>`
 

package/templates/prompts/retest-playwright.en.md

@@ -12,10 +12,7 @@ Post-refactoring validation with Playwright. Verify that refactoring did not bre
 4. Verify edge cases still work
 5. Compare behavior with pre-refactoring state
 6. If regression detected: return to review step
-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
+7. Do not test functionality outside the ticket scope
 8. Document: `autocode comment <ticket-key> "Retest Playwright OK"`
 9. Advance: `autocode next <ticket-key>`
 

package/templates/prompts/retest-playwright.fr.md

@@ -12,10 +12,7 @@ Validation post-refactoring avec Playwright. Verifier que le refactoring n'a pas
 4. Verifier que les cas limites fonctionnent toujours
 5. Comparer le comportement avec l'etat pre-refactoring
 6. Si regression detectee : retour a l'etape de review
-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
+7. Ne pas tester de fonctionnalites hors scope du ticket
 8. Documenter : `autocode comment <ticket-key> "Retest Playwright OK"`
 9. Avancer : `autocode next <ticket-key>`
 

package/templates/prompts/retest.en.md

@@ -13,10 +13,7 @@ Re-run all tests after bug fixes or corrections. Ensure no regressions were intr
 5. Verify the original issue is fixed
 6. Check for regressions in related functionality
 7. If tests fail: return to appropriate column for fixes
-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
+8. Do not write tests for code outside the ticket scope
 9. Document: `autocode comment <ticket-key> "Retest passed: all tests green"`
 10. Advance: `autocode next <ticket-key>`
 

package/templates/prompts/retest.fr.md

@@ -13,10 +13,7 @@ Re-executer tous les tests apres corrections de bugs. S'assurer qu'aucune regres
 5. Verifier que le probleme original est corrige
 6. Verifier les regressions dans les fonctionnalites liees
 7. Si les tests echouent : retourner a la colonne appropriee pour corrections
-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
+8. Ne pas ecrire de tests pour du code hors scope du ticket
 9. Documenter : `autocode comment <ticket-key> "Retest OK : tous les tests verts"`
 10. Avancer : `autocode next <ticket-key>`
 

package/templates/prompts/review-best-practices.en.md

@@ -12,12 +12,8 @@ Code quality audit. Verify conventions and best practices are followed.
 4. Verify file size (components < 300 lines)
 5. Verify import organization
 6. Fix violations found
-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 <ticket-key> "Review best practices OK"`
-9. Advance: `autocode next <ticket-key>`
+7. Document: `autocode comment <ticket-key> "Review best practices OK"`
+8. Advance: `autocode next <ticket-key>`
 
 > Or return: `autocode move <ticket-key> <target-column-slug>`
 

package/templates/prompts/review-best-practices.fr.md

@@ -12,12 +12,8 @@ Audit qualite du code. Verifier que les conventions et bonnes pratiques sont res
 4. Verifier la taille des fichiers (composants < 300 lignes)
 5. Verifier l'organisation des imports
 6. Corriger les violations trouvees
-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 <ticket-key> "Review best practices OK"`
-9. Avancer : `autocode next <ticket-key>`
+7. Documenter : `autocode comment <ticket-key> "Review best practices OK"`
+8. Avancer : `autocode next <ticket-key>`
 
 > Ou retour : `autocode move <ticket-key> <target-column-slug>`
 

package/templates/prompts/review-code.en.md

@@ -13,12 +13,8 @@ Perform peer code review. Ensure code quality, readability, and adherence to pro
 5. Check error handling
 6. Suggest improvements if needed
 7. If issues found: add comment with feedback and return to dev
-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 <ticket-key> "Code review passed: <summary>"`
-10. Advance: `autocode next <ticket-key>`
+8. Document: `autocode comment <ticket-key> "Code review passed: <summary>"`
+9. Advance: `autocode next <ticket-key>`
 
 > Or return: `autocode move <ticket-key> <target-column-slug>`
 

package/templates/prompts/review-code.fr.md

@@ -13,12 +13,8 @@ Effectuer une revue de code. Assurer la qualite du code, sa lisibilite et le res
 5. Verifier la gestion des erreurs
 6. Suggerer des ameliorations si necessaire
 7. Si problemes trouves : ajouter un commentaire avec feedback et retourner au dev
-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 <ticket-key> "Code review OK : <resume>"`
-10. Avancer : `autocode next <ticket-key>`
+8. Documenter : `autocode comment <ticket-key> "Code review OK : <resume>"`
+9. Avancer : `autocode next <ticket-key>`
 
 > Ou retour : `autocode move <ticket-key> <target-column-slug>`
 

package/templates/prompts/review-consistency.en.md

@@ -12,12 +12,8 @@ Verify code integrates harmoniously with existing project architecture.
 4. Check error handling (uniform try/catch)
 5. Verify correct Pinia store usage
 6. Fix inconsistencies
-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 <ticket-key> "Review consistency OK"`
-9. Advance: `autocode next <ticket-key>`
+7. Document: `autocode comment <ticket-key> "Review consistency OK"`
+8. Advance: `autocode next <ticket-key>`
 
 > Or return: `autocode move <ticket-key> <target-column-slug>`
 

package/templates/prompts/review-consistency.fr.md

@@ -12,12 +12,8 @@ Verifier que le code s'integre harmonieusement avec l'architecture existante du
 4. Controler la gestion d'erreurs (try/catch uniforme)
 5. Verifier l'usage correct des stores Pinia
 6. Corriger les incoherences
-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 <ticket-key> "Review consistency OK"`
-9. Avancer : `autocode next <ticket-key>`
+7. Documenter : `autocode comment <ticket-key> "Review consistency OK"`
+8. Avancer : `autocode next <ticket-key>`
 
 > Ou retour : `autocode move <ticket-key> <target-column-slug>`
 

package/templates/prompts/review-no-duplication.en.md

@@ -12,12 +12,8 @@ Identify and eliminate code duplication. Factor into reusable functions/composab
 4. Detect copy-pasted business logic
 5. Extract to composable/service/shared function if >2 usages
 6. Update all existing calls
-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 <ticket-key> "Review no duplication OK"`
-9. Advance: `autocode next <ticket-key>`
+7. Document: `autocode comment <ticket-key> "Review no duplication OK"`
+8. Advance: `autocode next <ticket-key>`
 
 > Or return: `autocode move <ticket-key> <target-column-slug>`
 

package/templates/prompts/review-no-duplication.fr.md

@@ -12,12 +12,8 @@ Identifier et eliminer la duplication de code. Factoriser en fonctions/composabl
 4. Detecter la logique metier copiee-collee
 5. Extraire en composable/service/fonction partagee si >2 usages
 6. Mettre a jour tous les appels existants
-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 <ticket-key> "Review no duplication OK"`
-9. Avancer : `autocode next <ticket-key>`
+7. Documenter : `autocode comment <ticket-key> "Review no duplication OK"`
+8. Avancer : `autocode next <ticket-key>`
 
 > Ou retour : `autocode move <ticket-key> <target-column-slug>`
 

package/templates/prompts/review-security.en.md

@@ -14,8 +14,8 @@ Security audit. Identify and fix potential vulnerabilities (OWASP Top 10).
 6. Audit API calls (injection, XSS)
 7. Fix vulnerabilities
 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`
+   - 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
 9. Document: `autocode comment <ticket-key> "Review security OK"`
 10. Advance: `autocode next <ticket-key>`

package/templates/prompts/review-security.fr.md

@@ -14,8 +14,8 @@ Audit securite. Identifier et corriger les vulnerabilites potentielles (OWASP To
 6. Auditer les appels API (injection, XSS)
 7. Corriger les vulnerabilites
 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`
+   - 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
 9. Documenter : `autocode comment <ticket-key> "Review security OK"`
 10. Avancer : `autocode next <ticket-key>`

package/templates/prompts/specification.en.md

@@ -13,8 +13,8 @@ Write detailed technical specifications for the ticket. Define the implementatio
 5. Specify API contracts if applicable
 6. Document edge cases and error handling
 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 <ticket-key> "Specification complete: <technical approach>"`
 9. Advance: `autocode next <ticket-key>`

package/templates/prompts/specification.fr.md

@@ -13,8 +13,8 @@ Rediger les specifications techniques detaillees pour le ticket. Definir clairem
 5. Specifier les contrats API si applicable
 6. Documenter les cas limites et la gestion d'erreurs
 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 <ticket-key> "Specification terminee : <approche technique>"`
 9. Avancer : `autocode next <ticket-key>`

package/templates/prompts/splitter.en.md

@@ -18,12 +18,11 @@ If the task is small enough to be completed in one go, proceed directly without
 2. Identify natural boundaries between features, layers, or responsibilities
 3. Define clear acceptance criteria for each sub-ticket
 4. Ensure each split ticket is independently testable and deployable
-5. Create sub-tickets: `autocode new "<title>" "<description>" -p P2 -l "<labels>" -a "<criteria>" -s patch`
+5. Create sub-tickets: `autocode new "<title>" "<description>" --priority P2 --labels "<labels>" --acceptance "<criteria>" --semver patch --column backlog`
 6. Verify no functionality has been forgotten or duplicated across tickets
 7. Create an integration ticket that references all sub-tickets to validate cohesion
-8. If out of scope work detected: `autocode new "<title>" "<description>" -p P2 -l "<labels>" -a "<criteria>" -s patch`
-9. Document: `autocode comment <ticket-key> "[summary]"`
-10. Advance: `autocode next <ticket-key>`
+8. Document: `autocode comment <ticket-key> "[summary]"`
+9. Advance: `autocode next <ticket-key>`
 
 > Or return: `autocode move <ticket-key> <target-column-slug>`
 

package/templates/prompts/splitter.fr.md

@@ -18,12 +18,11 @@ Si la tâche est suffisamment petite pour être complétée en une fois, procéd
 2. Identifier les frontières naturelles entre fonctionnalités, couches ou responsabilités
 3. Définir des critères d'acceptation clairs pour chaque sous-ticket
 4. S'assurer que chaque ticket découpé est testable et déployable indépendamment
-5. Créer les sous-tickets : `autocode new "<title>" "<description>" -p P2 -l "<labels>" -a "<criteria>" -s patch`
+5. Créer les sous-tickets : `autocode new "<title>" "<description>" --priority P2 --labels "<labels>" --acceptance "<criteria>" --semver patch --column backlog`
 6. Vérifier qu'aucune fonctionnalité n'a été oubliée ou dupliquée entre les tickets
 7. Créer un ticket d'intégration qui référence tous les sous-tickets pour valider la cohésion
-8. Si travail hors scope détecté : `autocode new "<title>" "<description>" -p P2 -l "<labels>" -a "<criteria>" -s patch`
-9. Documenter : `autocode comment <ticket-key> "[résumé]"`
-10. Avancer : `autocode next <ticket-key>`
+8. Documenter : `autocode comment <ticket-key> "[résumé]"`
+9. Avancer : `autocode next <ticket-key>`
 
 > Ou retourner : `autocode move <ticket-key> <target-column-slug>`
 

package/templates/prompts/testing-cypress.en.md

@@ -12,10 +12,7 @@ Write AND execute E2E automated tests to prevent regressions.
 4. Describe tests clearly (describe/it)
 5. Execute tests: npx cypress run
 6. If failures: fix tests or code
-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
+7. Do not write tests for code outside the ticket scope
 8. Document: `autocode comment <ticket-key> "Cypress tests OK"`
 9. Advance: `autocode next <ticket-key>`
 

package/templates/prompts/testing-cypress.fr.md

@@ -12,10 +12,7 @@ Rediger ET executer des tests E2E automatises pour prevenir les regressions.
 4. Decrire les tests clairement (describe/it)
 5. Executer les tests : npx cypress run
 6. Si echecs : corriger les tests ou le code
-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
+7. Ne pas ecrire de tests pour du code hors scope du ticket
 8. Documenter : `autocode comment <ticket-key> "Tests Cypress OK"`
 9. Avancer : `autocode next <ticket-key>`
 

package/templates/prompts/testing-integration.en.md

@@ -13,10 +13,7 @@ Run integration tests to verify components work correctly together. Ensure syste
 5. Test database operations
 6. Test external service connections
 7. Fix any failing tests
-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
+8. Do not write tests for code outside the ticket scope
 9. Document: `autocode comment <ticket-key> "Integration tests passed"`
 10. Advance: `autocode next <ticket-key>`
 

package/templates/prompts/testing-integration.fr.md

@@ -13,10 +13,7 @@ Executer les tests d'integration pour verifier que les composants fonctionnent c
 5. Tester les operations base de donnees
 6. Tester les connexions aux services externes
 7. Corriger les tests en echec
-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
+8. Ne pas ecrire de tests pour du code hors scope du ticket
 9. Documenter : `autocode comment <ticket-key> "Tests d'integration OK"`
 10. Avancer : `autocode next <ticket-key>`
 

package/templates/prompts/testing-playwright.en.md

@@ -12,10 +12,7 @@ Live functional testing with Playwright. Manually verify feature works by naviga
 4. Test edge cases
 5. Verify error handling
 6. Capture screenshots if needed
-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
+7. Do not test functionality outside the ticket scope
 8. Document: `autocode comment <ticket-key> "Playwright tests OK"`
 9. Advance: `autocode next <ticket-key>`
 

package/templates/prompts/testing-playwright.fr.md

@@ -12,10 +12,7 @@ Test fonctionnel live avec Playwright. Verifier manuellement que la feature fonc
 4. Tester les cas limites
 5. Verifier la gestion d'erreurs
 6. Capturer des screenshots si necessaire
-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
+7. Ne pas tester de fonctionnalites hors scope du ticket
 8. Documenter : `autocode comment <ticket-key> "Tests Playwright OK"`
 9. Avancer : `autocode next <ticket-key>`
 

package/templates/prompts/testing-unit.en.md

@@ -13,10 +13,7 @@ Write and run unit tests for the implemented feature. Ensure code coverage and r
 5. Run all unit tests: `npm test` or equivalent
 6. Fix any failing tests
 7. Verify coverage meets project standards
-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
+8. Do not write tests for code outside the ticket scope
 9. Document: `autocode comment <ticket-key> "Unit tests passed: <coverage>%"`
 10. Advance: `autocode next <ticket-key>`
 

package/templates/prompts/testing-unit.fr.md

@@ -13,10 +13,7 @@ Ecrire et executer les tests unitaires pour la fonctionnalite implementee. Assur
 5. Executer tous les tests unitaires : `npm test` ou equivalent
 6. Corriger les tests en echec
 7. Verifier que la couverture respecte les standards du projet
-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
+8. Ne pas ecrire de tests pour du code hors scope du ticket
 9. Documenter : `autocode comment <ticket-key> "Tests unitaires OK : <couverture>%"`
 10. Avancer : `autocode next <ticket-key>`