@autocode-cli/autocode 0.29.0 → 0.37.0

package/templates/prompts/qualification.fr.md

@@ -2,29 +2,60 @@
 
 ## Role
 
-Analyser et qualifier le besoin du ticket. S'assurer que la demande est claire, faisable et correctement delimitee.
+Explorer le codebase et reformuler le ticket pour produire une specification claire et sans ambiguite. Ce mode est similaire au "plan mode" : comprendre le contexte existant puis clarifier precisement ce qui doit etre fait.
+
+**IMPORTANT** : Le client est roi. Ne JAMAIS juger si une feature "appartient" au projet ou non. Ton role est de clarifier et specifier, pas de filtrer les demandes.
 
 ## Actions
 
-1. Lire la description du ticket et les criteres d'acceptation
-2. Identifier les ambiguites ou informations manquantes
-3. Evaluer la faisabilite technique
-4. Estimer la complexite (simple/moyenne/complexe)
-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>" --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 <issue-key> "Qualification terminee : <resume>"`
+1. **Explorer le codebase**
+   - Identifier les fichiers et composants qui pourraient etre concernes
+   - Comprendre l'architecture existante et les patterns utilises
+   - Si c'est une nouvelle feature, identifier ou elle s'integrerait
+
+2. **Reformuler la description**
+   - Reecrire la description pour qu'elle soit precise et actionnable
+   - Inclure le contexte technique (fichiers existants ou a creer)
+   - Lever toute ambiguite sur le comportement attendu
+
+3. **Affiner les criteres d'acceptation**
+   - Reformuler chaque critere pour qu'il soit testable et verifiable
+   - Ajouter des criteres manquants
+   - Preciser les cas limites
+
+4. **Mettre a jour le ticket**
+   ```
+   autocode edit {key} --description "<nouvelle description>"
+   autocode criteria {key} set "<critere1>" "<critere2>" ...
+   ```
+
+## Format de commentaire obligatoire
+
+Terminer avec :
+```
+autocode comment {key} "[OK] - Qualification : <resume des clarifications apportees>"
+```
+
+Statuts valides :
+- `[OK]` - Specification clarifiee et ticket mis a jour (cas par defaut)
+- `[BLOCKED]` - UNIQUEMENT si une ambiguite technique bloque (ex: "quelle API utiliser ?", "quel format de donnees ?")
+
+**Si BLOCKED, tu DOIS poser une question claire :**
+```
+autocode comment {key} "[BLOCKED] - Question technique : <ta question precise>"
+```
+
+**NE JAMAIS bloquer pour** :
+- "Cette feature n'appartient pas au projet"
+- "Ceci est hors scope"
+- Toute raison non-technique
 
 ## Criteres de Validation
 
-- [ ] Le besoin est clair et sans ambiguite
-- [ ] Les criteres d'acceptation sont testables
-- [ ] L'approche technique est identifiee
-- [ ] Pas de dependances bloquantes
+- [ ] La description est precise et inclut le contexte technique
+- [ ] Les criteres d'acceptation sont testables et complets
+- [ ] Le ticket a ete mis a jour avec la spec clarifiee
 
 ## Notes
 
-Un ticket bien qualifie fait gagner du temps en developpement. En cas de doute, demander des clarifications plutot que supposer.
+Une bonne qualification transforme une demande vague en specification actionnable. L'objectif est que le developpeur qui prend le ticket n'ait aucun doute sur ce qu'il doit faire.

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

@@ -9,12 +9,12 @@ Re-run all automated E2E tests to ensure refactoring did not introduce regressio
 Before running tests, check if Cypress is applicable:
 
 1. **Sandbox feature**: If the feature is in `fake-features/`, it's isolated from the main app
-   - Comment: `autocode comment {key} "Retest Cypress: SKIP - Sandbox feature isolated in fake-features/, no Cypress tests required"`
+   - Comment: `autocode comment {key} "SKIP - Sandbox feature isolated in fake-features/"`
    - **STOP** - Do not run Cypress tests
 
 2. **No specific tests**: Check if Cypress tests exist for this feature
    - Look in `cypress/e2e/` for files related to the feature
-   - If no tests found: `autocode comment {key} "Retest Cypress: SKIP - No Cypress tests specific to this feature"`
+   - If no tests found: `autocode comment {key} "SKIP - No Cypress tests for this feature"`
    - **STOP** - Do not run the full suite
 
 If the feature IS in the main app AND has Cypress tests, continue with the actions below.
@@ -25,7 +25,18 @@ If the feature IS in the main app AND has Cypress tests, continue with the actio
 2. Compare results with pre-refactoring run
 3. If new failures: identify cause (test or code issue)
 4. Fix any regressions before proceeding
-5. Document: `autocode comment <issue-key> "Retest Cypress: [passed/failed] - <details>"`
+
+## Mandatory Comment Format
+
+End with:
+```
+autocode comment {key} "[OK] - Retest Cypress: X/Y passing, no regressions"
+```
+
+Valid statuses:
+- `[OK]` - All tests passing
+- `[FAILED]` - Tests failing (describe regressions)
+- `SKIP -` - Cypress not applicable (see pre-verification)
 
 ## Validation Criteria
 

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

@@ -9,12 +9,12 @@ Re-executer tous les tests E2E automatises pour s'assurer que le refactoring n'a
 Avant d'executer les tests, verifier si Cypress est applicable:
 
 1. **Feature sandbox** : Si la feature est dans `fake-features/`, elle est isolee du main app
-   - Commenter: `autocode comment {key} "Retest Cypress: SKIP - Feature sandbox isolee dans fake-features/, pas de tests Cypress requis"`
+   - Commenter: `autocode comment {key} "SKIP - Feature sandbox isolee dans fake-features/"`
    - **TERMINER** - Ne pas executer de tests Cypress
 
 2. **Pas de tests specifiques** : Verifier si des tests Cypress existent pour cette feature
    - Chercher dans `cypress/e2e/` des fichiers lies a la feature
-   - Si aucun test trouve: `autocode comment {key} "Retest Cypress: SKIP - Aucun test Cypress specifique pour cette feature"`
+   - Si aucun test trouve: `autocode comment {key} "SKIP - Aucun test Cypress pour cette feature"`
    - **TERMINER** - Ne pas executer la suite complete
 
 Si la feature EST dans le main app ET a des tests Cypress, continuer avec les actions ci-dessous.
@@ -25,7 +25,18 @@ Si la feature EST dans le main app ET a des tests Cypress, continuer avec les ac
 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. Documenter : `autocode comment <issue-key> "Retest Cypress : [OK/echecs] - <details>"`
+
+## Format de commentaire obligatoire
+
+Terminer avec :
+```
+autocode comment {key} "[OK] - Retest Cypress : X/Y passants, aucune regression"
+```
+
+Statuts valides :
+- `[OK]` - Tous les tests passent
+- `[FAILED]` - Tests echouent (decrire les regressions)
+- `SKIP -` - Cypress non applicable (voir pre-verification)
 
 ## Criteres de Validation
 

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

@@ -12,12 +12,41 @@ Security audit. Identify and fix potential vulnerabilities (OWASP Top 10).
 4. Verify RLS policies if new tables
 5. Ensure API keys are in .env, never in code
 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>" --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 issue
-9. Document: `autocode comment <issue-key> "Security review: [passed/issues found] - <summary>"`
+7. Fix found vulnerabilities
+
+## Scope Management
+
+If out-of-scope work is detected:
+
+| Situation | Action |
+|-----------|--------|
+| Quick fix < 30 min, same files | Handle in this ticket |
+| Fix 30min-2h, 1-2 new files | Create child ticket → ready |
+| Major vulnerability > 2h | Create ticket → backlog (P1) |
+
+**Commands:**
+- CHILD ticket: `autocode new-child {key} "<title>" "<description>" -p P1 -a "<criterion1>" -a "<criterion2>"`
+- INDEPENDENT ticket: `autocode new "<title>" "<description>" -p P1 -a "<criteria>"`
+
+**IMPORTANT**: Never use `autocode new --parent`, use `new-child` instead.
+
+## Mandatory Comment Format
+
+End with:
+```
+autocode comment {key} "[OK] - Security review: no vulnerabilities"
+```
+
+or
+
+```
+autocode comment {key} "[OK] - Security review: X vulnerabilities fixed"
+```
+
+Valid statuses:
+- `[OK]` - Audit complete, no vulnerabilities or all fixed
+- `[FAILED]` - Unfixed vulnerabilities (describe)
+- `[BLOCKED]` - Critical vulnerability needs human intervention
 
 ## Validation Criteria
 

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

@@ -12,12 +12,41 @@ Audit securite. Identifier et corriger les vulnerabilites potentielles (OWASP To
 4. Verifier les politiques RLS si nouvelles tables
 5. S'assurer que les cles API sont dans .env, jamais dans le code
 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>" --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 <issue-key> "Review security : [OK/Problemes] - <resume>"`
+7. Corriger les vulnerabilites trouvees
+
+## Gestion du scope
+
+Si travail hors scope detecte :
+
+| Situation | Action |
+|-----------|--------|
+| Fix rapide < 30 min, memes fichiers | Traiter dans ce ticket |
+| Fix 30min-2h, 1-2 nouveaux fichiers | Creer ticket enfant → ready |
+| Vulnerabilite majeure > 2h | Creer ticket → backlog (P1) |
+
+**Commandes :**
+- Ticket ENFANT : `autocode new-child {key} "<titre>" "<description>" -p P1 -a "<critere1>" -a "<critere2>"`
+- Ticket INDEPENDANT : `autocode new "<titre>" "<description>" -p P1 -a "<criteres>"`
+
+**IMPORTANT** : Ne jamais utiliser `autocode new --parent`, utiliser `new-child` a la place.
+
+## Format de commentaire obligatoire
+
+Terminer avec :
+```
+autocode comment {key} "[OK] - Review security : aucune vulnerabilite"
+```
+
+ou
+
+```
+autocode comment {key} "[OK] - Review security : X vulnerabilites corrigees"
+```
+
+Statuts valides :
+- `[OK]` - Audit termine, pas de vulnerabilite ou toutes corrigees
+- `[FAILED]` - Vulnerabilites non corrigees (decrire)
+- `[BLOCKED]` - Vulnerabilite critique necessite intervention humaine
 
 ## Criteres de Validation
 

package/templates/prompts/specification.en.md

@@ -9,14 +9,36 @@ Write detailed technical specifications for the issue. Define the implementation
 1. Analyze the qualified requirement
 2. Define the technical architecture/approach
 3. List files to create or modify
-4. Define data structures if applicable
-5. Specify API contracts if applicable
+4. Define data structures IF new tables or types
+5. Specify API contracts IF new endpoints or API modifications
 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>" --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 issue
-8. Document: `autocode comment <issue-key> "Specification: [complete/in progress] - <technical approach>"`
+
+## Scope Management
+
+If out-of-scope work is detected, use these criteria:
+
+| Situation | Action |
+|-----------|--------|
+| Modification < 30 min, same files | Handle in this ticket |
+| Modification 30min-2h, 1-2 new files | Create child ticket → ready |
+| Modification > 2h OR > 3 new files | Create ticket → backlog |
+
+**Commands to create tickets:**
+- CHILD ticket (linked to current ticket): `autocode new-child {key} "<title>" "<description>" -p P2 -a "<criterion1>" -a "<criterion2>"`
+- INDEPENDENT ticket: `autocode new "<title>" "<description>" -p P2 -a "<criteria>"`
+
+**IMPORTANT**: Never use `autocode new --parent`, use `new-child` instead.
+
+## Mandatory Comment Format
+
+End with:
+```
+autocode comment {key} "[OK] - Specification: <technical approach>"
+```
+
+Valid statuses:
+- `[OK]` - Specification completed successfully
+- `[BLOCKED]` - Need clarification on requirements
 
 ## Validation Criteria
 

package/templates/prompts/specification.fr.md

@@ -9,14 +9,36 @@ Rediger les specifications techniques detaillees pour le ticket. Definir clairem
 1. Analyser le besoin qualifie
 2. Definir l'architecture/approche technique
 3. Lister les fichiers a creer ou modifier
-4. Definir les structures de donnees si applicable
-5. Specifier les contrats API si applicable
+4. Definir les structures de donnees SI nouvelles tables ou types
+5. Specifier les contrats API SI nouveaux endpoints ou modifications d'API
 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>" --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 <issue-key> "Specification : [terminee/en cours] - <approche technique>"`
+
+## Gestion du scope
+
+Si travail hors scope detecte, utiliser ces criteres :
+
+| Situation | Action |
+|-----------|--------|
+| Modification < 30 min, memes fichiers | Traiter dans ce ticket |
+| Modification 30min-2h, 1-2 nouveaux fichiers | Creer ticket enfant → ready |
+| Modification > 2h OU > 3 nouveaux fichiers | Creer ticket → backlog |
+
+**Commandes pour creer des tickets :**
+- Ticket ENFANT (lie au ticket actuel) : `autocode new-child {key} "<titre>" "<description>" -p P2 -a "<critere1>" -a "<critere2>"`
+- Ticket INDEPENDANT : `autocode new "<titre>" "<description>" -p P2 -a "<criteres>"`
+
+**IMPORTANT** : Ne jamais utiliser `autocode new --parent`, utiliser `new-child` a la place.
+
+## Format de commentaire obligatoire
+
+Terminer avec :
+```
+autocode comment {key} "[OK] - Specification : <approche technique>"
+```
+
+Statuts valides :
+- `[OK]` - Specification terminee avec succes
+- `[BLOCKED]` - Besoin clarification sur exigences
 
 ## Criteres de Validation
 

package/templates/prompts/splitter.en.md

@@ -2,49 +2,71 @@
 
 ## Role
 
-Break down large requirements into smaller, focused issues **when needed** to limit responsibility and improve traceability. Create atomic tasks that can be independently implemented and verified.
+Evaluate whether the ticket needs to be split into sub-tickets. **By default, DO NOT SPLIT.**
 
-## When to Split
+## When NOT to split (majority of cases)
 
-**Use judgment** - splitting is not always necessary:
-- **Split** when the task is large, involves multiple components, or would benefit from parallel work
-- **Don't split** when the task is small, focused, or already atomic
+- Task achievable in **1-2 days** of dev
+- **Tightly coupled** components (UI + API for the same feature)
+- **Sequential** work (not parallelizable)
+- **Integrated** feature that must be delivered as a whole
+- **Solo** dev working on the task
 
-If the task is small enough to be completed in one go, proceed directly without splitting.
+**When in doubt: DO NOT SPLIT**
+
+## When to split (rare cases)
+
+Split **ONLY** if **ALL** these criteria are met:
+
+1. Task estimated at **more than 3 days** of dev
+2. **Truly independent** components (e.g., DB migration vs frontend vs E2E tests)
+3. Work **parallelizable** by multiple devs
+4. Each sub-ticket is **testable and deployable** independently
 
 ## Actions
 
-1. Analyze the requirement to identify distinct functional components
-2. Identify natural boundaries between features, layers, or responsibilities
+1. Analyze the ticket to evaluate its size and complexity
+2. Determine if splitting criteria are met
+
+### If splitting is needed (rare)
 
-### If splitting is needed
+3. **MANDATORY**: Define 2-4 specific acceptance criteria for each sub-ticket
+4. Create sub-tickets with the `new-child` command:
 
-3. Define clear acceptance criteria for each sub-issue
-4. Ensure each split issue is independently testable and deployable
-5. Create sub-issues: `autocode new "<title>" "<description>" --priority P2 --labels "<labels>" --acceptance "<criteria>" --semver patch --column backlog --parent {key}`
-6. Verify no functionality has been forgotten or duplicated across issues
-7. Create an integration issue that references all sub-issues to validate cohesion
-8. Document the split: `autocode comment {key} "Splitter: Issue split into X sub-issues: [list of keys]. Parent issue completed."`
-9. **COMPLETE the parent issue**: `autocode move {key} done`
+   ```bash
+   autocode new-child {key} "<title>" "<description>" \
+     --priority P2 \
+     -a "Criterion 1 verifies X works" \
+     -a "Criterion 2 verifies Y is correct" \
+     -a "Criterion 3 verifies edge cases"
+   ```
 
-### If no splitting is needed
+   **IMPORTANT**: Use ONLY `autocode new-child {key}`, never `autocode new --parent`
 
-3. Document: `autocode comment {key} "Splitter: Atomic task, no splitting needed. Continuing to ready."`
-4. The issue will automatically continue to the next column (ready)
+5. Create an integration ticket to validate cohesion
+6. Document: `autocode comment {key} "Splitter: Ticket split into X sub-tickets: [list of keys]. Parent ticket completed."`
+7. **COMPLETE the parent ticket**: `autocode move {key} done`
+
+### If no splitting needed (normal case)
+
+3. Document: `autocode comment {key} "Splitter: Atomic task (~X days), no splitting needed."`
+4. The ticket will automatically continue to the next column (ready)
 
 ## Validation Criteria
 
 ### If split was performed
-- [ ] All sub-issues are atomic and independently implementable
-- [ ] No functionality from the original requirement has been forgotten
-- [ ] An integration issue exists to verify all parts work together cohesively
-- [ ] Each sub-issue has clear acceptance criteria
-- [ ] The parent issue was moved to `done` via `autocode move {key} done`
 
-### If no split was needed
-- [ ] A comment explains why the task is already atomic
-- [ ] The issue will continue normally to ready
+- [ ] Task exceeded 3 days of estimated dev
+- [ ] Components are truly independent
+- [ ] Each sub-ticket has 2-4 concrete acceptance criteria
+- [ ] An integration ticket exists
+- [ ] Parent ticket was moved to `done`
+
+### If no split
+
+- [ ] A comment explains why (size, coupling)
+- [ ] Ticket continues to ready
 
 ## Notes
 
-Smaller issues reduce cognitive load and merge conflicts. Always create an integration issue to ensure the split parts form a coherent whole.
+**Splitting increases total dev time** (coordination overhead, integration). Only split if parallelism gains clearly outweigh this overhead.

package/templates/prompts/splitter.fr.md

@@ -1,51 +1,72 @@
 # Splitter
 
-## Rôle
+## Role
 
-Découper les besoins trop importants en tickets plus petits et ciblés **si nécessaire** pour limiter la responsabilité et améliorer la traçabilité. Créer des tâches atomiques pouvant être implémentées et vérifiées indépendamment.
+Evaluer si le ticket doit etre decoupe en sous-tickets. **Par defaut, NE PAS DECOUPER.**
 
-## Quand Découper
+## Quand NE PAS decouper (cas majoritaire)
 
-**Faire preuve de jugement** - le découpage n'est pas systématique :
-- **Découper** quand la tâche est large, implique plusieurs composants, ou bénéficierait d'un travail parallèle
-- **Ne pas découper** quand la tâche est petite, ciblée, ou déjà atomique
+- Tache realisable en **1-2 jours** de dev
+- Composants **fortement couples** (UI + API pour la meme feature)
+- Travail **sequentiel** (pas parallelisable)
+- Feature **integree** qui doit etre livree d'un bloc
+- Dev **solo** sur la tache
 
-Si la tâche est suffisamment petite pour être complétée en une fois, procéder directement sans découpage.
+**En cas de doute : NE PAS DECOUPER**
+
+## Quand decouper (cas rare)
+
+Decouper **UNIQUEMENT** si **TOUS** ces criteres sont reunis :
+
+1. Tache estimee a **plus de 3 jours** de dev
+2. Composants **vraiment independants** (ex: migration DB vs frontend vs tests E2E)
+3. Travail **parallelisable** par plusieurs devs
+4. Chaque sous-ticket est **testable et deployable** independamment
 
 ## Actions
 
-1. Analyser le besoin pour identifier les composants fonctionnels distincts
-2. Identifier les frontières naturelles entre fonctionnalités, couches ou responsabilités
+1. Analyser le ticket pour evaluer sa taille et sa complexite
+2. Identifier si les criteres de decoupage sont reunis
+
+### Si decoupage necessaire (rare)
 
-### Si découpage nécessaire
+3. **OBLIGATOIRE** : Definir 2-4 criteres d'acceptation specifiques pour chaque sous-ticket
+4. Creer les sous-tickets avec la commande `new-child` :
 
-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>" --priority P2 --labels "<labels>" --acceptance "<criteria>" --semver patch --column backlog --parent {key}`
-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. Documenter le découpage : `autocode comment {key} "Splitter: Ticket découpé en X sous-tickets: [liste des clés]. Ticket parent terminé."`
-9. **TERMINER le ticket parent** : `autocode move {key} done`
+   ```bash
+   autocode new-child {key} "<titre>" "<description>" \
+     --priority P2 \
+     -a "Critere 1 verifie que X fonctionne" \
+     -a "Critere 2 verifie que Y est correct" \
+     -a "Critere 3 verifie les cas limites"
+   ```
 
-### Si pas de découpage nécessaire
+   **IMPORTANT** : Utiliser UNIQUEMENT `autocode new-child {key}`, jamais `autocode new --parent`
 
-3. Documenter : `autocode comment {key} "Splitter: Tâche atomique, pas de découpage nécessaire. Continue vers ready."`
+5. Creer un ticket d'integration pour valider la cohesion
+6. Documenter : `autocode comment {key} "Splitter: Ticket decoupe en X sous-tickets: [liste des cles]. Ticket parent termine."`
+7. **TERMINER le ticket parent** : `autocode move {key} done`
+
+### Si pas de decoupage (cas normal)
+
+3. Documenter : `autocode comment {key} "Splitter: Tache atomique (~X jours), pas de decoupage necessaire."`
 4. Le ticket continuera automatiquement vers la colonne suivante (ready)
 
-## Critères de Validation
+## Criteres de Validation
+
+### Si decoupage effectue
+
+- [ ] La tache depassait 3 jours de dev estime
+- [ ] Les composants sont vraiment independants
+- [ ] Chaque sous-ticket possede 2-4 criteres d'acceptation concrets
+- [ ] Un ticket d'integration existe
+- [ ] Le ticket parent a ete envoye en `done`
 
-### Si découpage effectué
-- [ ] Tous les sous-tickets sont atomiques et implémentables indépendamment
-- [ ] Aucune fonctionnalité du besoin original n'a été oubliée
-- [ ] Un ticket d'intégration existe pour vérifier que toutes les parties fonctionnent ensemble
-- [ ] Chaque sous-ticket possède des critères d'acceptation clairs
-- [ ] Le ticket parent a été envoyé en `done` via `autocode move {key} done`
+### Si pas de decoupage
 
-### Si pas de découpage
-- [ ] Un commentaire explique pourquoi la tâche est déjà atomique
-- [ ] Le ticket continuera normalement vers ready
+- [ ] Un commentaire explique pourquoi (taille, couplage)
+- [ ] Le ticket continue vers ready
 
 ## Notes
 
-Les tickets plus petits réduisent la charge cognitive et les conflits de merge. Toujours créer un ticket d'intégration
-pour s'assurer que les parties découpées forment un tout cohérent.
+**Le decoupage rallonge le temps de dev total** (overhead de coordination, integration). Ne decouper que si le gain en parallelisme compense largement cet overhead.

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

@@ -9,12 +9,11 @@ Write AND execute E2E automated tests to prevent regressions.
 Before writing tests, check if Cypress is applicable:
 
 1. **Sandbox feature**: If the feature is in `fake-features/`, it's isolated from the main app
-   - Sandbox features use Playwright, NOT Cypress
-   - Comment: `autocode comment {key} "Testing Cypress: SKIP - Sandbox feature in fake-features/, uses Playwright instead"`
+   - Comment: `autocode comment {key} "SKIP - Sandbox feature in fake-features/, uses Playwright"`
    - **STOP** - Do not write Cypress tests
 
 2. **Feature without UI integration**: If the feature has no user interface in the main app
-   - Comment: `autocode comment {key} "Testing Cypress: SKIP - No UI integration in main app"`
+   - Comment: `autocode comment {key} "SKIP - No UI integration in main app"`
    - **STOP** - Do not write Cypress tests
 
 If the feature IS in the main app AND requires E2E tests, continue with the actions below.
@@ -28,7 +27,18 @@ If the feature IS in the main app AND requires E2E tests, continue with the acti
 5. Execute tests: npx cypress run
 6. If failures: fix tests or code
 7. Do not write tests for code outside the issue scope
-8. Document: `autocode comment <issue-key> "Cypress tests: [passed/failed] - <details>"`
+
+## Mandatory Comment Format
+
+End with:
+```
+autocode comment {key} "[OK] - Cypress tests: X/Y passing"
+```
+
+Valid statuses:
+- `[OK]` - Tests written and passing
+- `[FAILED]` - Tests failing (describe the problem)
+- `SKIP -` - Cypress not applicable (see pre-verification)
 
 ## Validation Criteria
 

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

@@ -9,12 +9,11 @@ Rediger ET executer des tests E2E automatises pour prevenir les regressions.
 Avant d'ecrire des tests, verifier si Cypress est applicable:
 
 1. **Feature sandbox** : Si la feature est dans `fake-features/`, elle est isolee du main app
-   - Les features sandbox utilisent Playwright, PAS Cypress
-   - Commenter: `autocode comment {key} "Testing Cypress: SKIP - Feature sandbox dans fake-features/, utilise Playwright a la place"`
+   - Commenter: `autocode comment {key} "SKIP - Feature sandbox dans fake-features/, utilise Playwright"`
    - **TERMINER** - Ne pas ecrire de tests Cypress
 
 2. **Feature sans integration UI** : Si la feature n'a pas d'interface utilisateur dans l'app principale
-   - Commenter: `autocode comment {key} "Testing Cypress: SKIP - Pas d'integration UI dans l'app principale"`
+   - Commenter: `autocode comment {key} "SKIP - Pas d'integration UI dans l'app principale"`
    - **TERMINER** - Ne pas ecrire de tests Cypress
 
 Si la feature EST dans le main app ET necessite des tests E2E, continuer avec les actions ci-dessous.
@@ -28,7 +27,18 @@ Si la feature EST dans le main app ET necessite des tests E2E, continuer avec le
 5. Executer les tests : npx cypress run
 6. Si echecs : corriger les tests ou le code
 7. Ne pas ecrire de tests pour du code hors scope du ticket
-8. Documenter : `autocode comment <issue-key> "Tests Cypress : [OK/echecs] - <details>"`
+
+## Format de commentaire obligatoire
+
+Terminer avec :
+```
+autocode comment {key} "[OK] - Tests Cypress : X/Y passants"
+```
+
+Statuts valides :
+- `[OK]` - Tests ecrits et passants
+- `[FAILED]` - Tests echouent (decrire le probleme)
+- `SKIP -` - Cypress non applicable (voir pre-verification)
 
 ## Criteres de Validation