Plan And Confirm

• List every file to modify or create, with the reasoning for each change
• State explicitly what will NOT be changed and why
• If the change spans multiple files with ordering constraints, explain the sequence

Risks & attention points

• Any code that could break elsewhere in the app
• Any assumption made (and why)
• Any breaking API change, DB migration, or env variable addition

Phase 3 — Wait for approval

STOP. Do not touch any file.

Output literally:

Please confirm with OKAY if the understanding and plan are correct. Otherwise, tell me what is wrong and I will adjust before coding.

Absolute rule: If the user does not say OKAY (or equivalent: "yes", "go", "ok", "c'est bon", "lance"), stay in Phase 3. Do not proceed.

Phase 4 — Implement (only after OKAY)

Once OKAY is received:

1. Implement exactly as described in the approved plan — no additions, no improvements beyond scope
2. If something discovered during implementation changes the plan → stop and re-present before continuing
3. Summarize changes with file:line references after completion

Never commit unless the user explicitly asks.

Phase 5 — Workflow GitHub (après implémentation)

Une fois le code implémenté et validé, suivre ce cycle complet. Chaque étape a un skill dédié :

/create-issue → /worktree-start → code → /commit → /create-pr → merge → /worktree-finish
      ↑                                    │                                     │
      └────────────── next issue ──────────┘                                     │
      └────────────── epic still open? ──────────────────────────────────────────┘

Étape 1 — Créer ou identifier l'issue

• Si pas d'issue existante : /create-issue (crée avec labels, scope, lien epic)
• Si issue existe déjà : noter le numéro #N
• Si c'est un lot d'un epic : lier avec Parent: #P dans le body

Étape 2 — Créer le worktree

• /worktree-start <N> → crée ../KLASSCIv2-issue-<N> basé sur origin/presentation
• Si quick fix (< 30 min) : rester sur presentation, committer avec Refs #N

Étape 3 — Coder dans le worktree

• Tous les fichiers dans ../KLASSCIv2-issue-<N>/

Étape 4 — Committer

• /commit → détecte l'issue #N automatiquement, ajoute Refs #N
• Si lot d'un epic : ajoute Lot X/Y: description dans le body
• Si dernier lot : utilise Closes #N au lieu de Refs #N

Étape 5 — Créer la PR

• /create-pr → base presentation, lien issue, tableau epic si applicable
• Tester sur le serveur après deploy si applicable

Étape 6 — Nettoyer après merge

• /worktree-finish <N> → supprime worktree + branches, ferme l'issue
• Vérifie si l'epic parent est encore ouvert → propose la suite

Decision tree : nouvelle issue ou continuer ?

Rules

• Never code without OKAY — this is rule #1
• Base all analysis on files actually read — no guessing
• If the plan is rejected, re-explore if needed then present a revised plan
• A "trivial change" (typo, single string edit) does not require this workflow

$ARGUMENTS