Skip to content
BranchesTags

Latest commit

 

History

697 Commits

Folders and files

NameName
Last commit message
Last commit date
.claude
.claude
 
 
.vscode
.vscode
 
 
TEMPLATE_claude
TEMPLATE_claude
 
 
.gitignore
.gitignore
 
 
CLAUDE.md
CLAUDE.md
 
 
README.md
README.md
 
 
init-project.md
init-project.md
 
 

Repository files navigation

Claude Code Project Template

Template de gestion de projet pour Claude Code. Fournit un ensemble de commandes, agents et contextes partagés pour orchestrer le développement, la qualité, le déploiement et la communication de release.

Installation

Option A — Launcher tmux (recommandé)

Hub tmux pour piloter plusieurs projets Claude Code en parallèle (sessions groupées, panes colorés par agent, auto-update silencieux, sync automatique de init-project.md) — maintenu dans son propre repo, compagnon de celui-ci :

curl -fsSL \
  https://raw.githubusercontent.com/CCoupel/Claude-Launcher/main/claude-launcher.sh \
  -o ~/claude-launcher.sh && chmod +x ~/claude-launcher.sh && ~/claude-launcher.sh

Documentation complète (configuration, EXTRA_ENVS, mise à jour) : CCoupel/Claude-Launcher · site

Déjà installé avant v3.0.0 ? Le launcher vivait ici auparavant — votre script cherche encore ses mises à jour sur ce repo, qui ne l'héberge plus. Relancez une fois la commande ci-dessus (même URL, elle pointe déjà vers le nouveau repo) pour basculer définitivement ; votre config (~/.config/claude-launcher.conf) n'est pas touchée. Détails : notes de la release v3.0.0 · procédure de migration complète.

Lancer ensuite /init-project dans Claude Code.

Option B — Fichier seul

mkdir -p <mon-projet>/.claude/commands

curl -fsSL \
  https://raw.githubusercontent.com/CCoupel/claude_project_template/main/init-project.md \
  -o <mon-projet>/.claude/commands/init-project.md

Ouvrir le projet dans Claude Code et lancer /init-project.

/init-project fetche automatiquement TEMPLATE_claude/ depuis GitHub, détecte la stack et génère la configuration complète.

Architecture

Repo template (ce repo)          Projet cible après /init-project
─────────────────────────        ──────────────────────────────────
README.md                        README.md  (projet)
init-project.md          ──┐
CLAUDE.md                  │     .claude/
TEMPLATE_claude/           │     ├── commands/
├── commands/              │     │   ├── *.md          ← sync depuis TEMPLATE_claude/ (gitignore, /xxx)
│   └── context/           │     │   └── init-project.md ← point d'entrée (tracké git)
├── agents/                │     ├── agents/
│   └── context/           └──►  │   ├── *.template.md ← sync depuis TEMPLATE_claude/ (gitignore)
├── templates/                   │   ├── *.md          ← adaptations projet par agent (tracké git)
│   └── workflows/               │   ├── context/*.template.md ← sync (gitignore)
├── INITIALIZATION.md            │   ├── context/*.md  ← adaptations projet par contexte (tracké git)
├── CLAUDE_TEMPLATE.md           │   └── dev-*.md      ← généré stack (tracké git)
└── .template-source.json        ├── CLAUDE.md         ← généré (tracké git)
                                 ├── project-config.json ← généré (tracké git)
                                 └── memory/           ← tracké git

                                 TEMPLATE_claude/      ← gitignore (fetché depuis GitHub)
                                 .gitignore            ← généré par /init-project

Règle simple

Dossier Dans le projet cible Dans git
TEMPLATE_claude/ Source template Non (gitignore)
.claude/commands/*.md Commandes template (jamais éditées, invocables /xxx) Non (gitignore)
.claude/agents/*.template.md Agents template (jamais édités) Non (gitignore)
.claude/agents/*.md Adaptations projet par agent Oui
.claude/agents/dev-*.md Agents projet (stack-spécifique) Oui
.claude/agents/environments/{publish,deploy}.<env>.md Fichiers publish/deploy par environnement (mécanisme spécifique, un par tâche × environnement) Oui
.claude/{agents,commands}/context/*.template.md Contextes partagés template (jamais édités) Non (gitignore)
.claude/{agents,commands}/context/*.md Adaptations projet par contexte partagé Oui
.claude/CLAUDE.md, project-config.json, memory/ Config projet Oui

Séparation template / projet

Commandes : déployées en *.md, directement invocables (/feature, /bugfix...). Ne pas les éditer — elles sont écrasées à la prochaine sync, sans compagnon.

Agents : déployés en deux fichiers compagnons :

.claude/agents/cdp.template.md   ← template, jamais édité, mis à jour par sync
.claude/agents/cdp.md            ← adaptations projet, tracké git, jamais écrasé

Contextes partagés (context/COMMON.md, context/GITHUB.md... référencés par les commandes et les agents) : même convention que les agents, un compagnon optionnel par fichier :

.claude/commands/context/COMMON.template.md   ← template, jamais édité, mis à jour par sync
.claude/commands/context/COMMON.md            ← adaptations projet, tracké git, jamais écrasé

Claude lit les deux automatiquement (agents comme contextes). Les projets sans adaptation n'ont pas besoin de créer de fichier *.md.

Structure du repo template

README.md                        # Documentation utilisateur (ce fichier)
init-project.md                  # Seul fichier à copier pour bootstrapper
CLAUDE.md                        # Guide de contribution au template lui-même

TEMPLATE_claude/                 # Tous les composants livrés aux projets cibles
├── INITIALIZATION.md            # Documentation détaillée du processus d'init
├── CLAUDE_TEMPLATE.md           # Modèle de CLAUDE.md (Zone 1 projet + Zone 2 teamleader)
├── settings.json                # Configuration Claude Code (vide par défaut — extensible par le projet)
├── .template-source.json        # Référence GitHub (repo + commit du dernier fetch)
├── gitignore-for-projects       # Copié en .gitignore par /init-project
│
├── commands/                    # Commandes slash
│   ├── start-session.md
│   ├── end-session.md
│   ├── team-status.md
│   ├── team-delete.md
│   ├── feature.md
│   ├── bugfix.md
│   ├── hotfix.md
│   ├── refactor.md
│   ├── review.md
│   ├── qa.md
│   ├── secu.md
│   ├── build.md
│   ├── publish.md
│   ├── deploy.md
│   ├── backlog.md
│   ├── milestone.md
│   ├── progression.md
│   ├── context-audit.md
│   ├── marketing.md
│   └── context/
│       ├── COMMON.md
│       ├── CDP_WORKFLOWS.md
│       ├── DEVELOPMENT.md
│       ├── QUALITY.md
│       └── GITHUB.md
│
├── agents/                      # Agents spécialisés
│   ├── teamleader.md            # Teamleader — gestion team + rôle CDP
│   ├── cdp.md                   # Règles CDP — orchestration, délégation, gates
│   ├── implementation-planner.md
│   ├── test-writer.md
│   ├── code-reviewer.md
│   ├── qa.md
│   ├── security.md
│   ├── doc-updater.md
│   ├── deploy.md
│   ├── infra.md
│   ├── pr-reviewer.md
│   ├── marketing-release.md
│   └── context/
│       ├── COMMON.md
│       ├── DEV_COMMON.md
│       ├── TEAMMATES_PROTOCOL.md
│       ├── VALIDATION_COMMON.md
│       └── GITHUB.md
│
└── templates/                   # Templates par stack technique
    ├── dev-backend-go.md
    ├── dev-backend-node.md
    ├── dev-backend-python.md
    ├── dev-frontend-react.md
    ├── dev-frontend-vue.md
    ├── dev-firmware-esp32.md
    ├── environments/             # Templates publish/deploy par mécanisme (promote, rebuild-ci,
    │                             # docker-compose, kubernetes-helm, serverless, vps, paas, cloud-run)
    └── workflows/
        └── release-go-react.yml

Orchestration multi-agents

Les workflows sont orchestrés par le CDP (Chef De Projet), seul interlocuteur entre l'utilisateur et l'équipe technique. Le CDP dispatche via SendMessage vers les agents spécialisés, valide leurs livrables et reporte la progression.

Agents disponibles

Agent Rôle
cdp Orchestrateur — coordonne, dispatche, reporte
planner Plan d'implémentation + contrats API (contract-first)
dev-backend Développement backend (stack détectée)
dev-frontend Développement frontend (stack détectée)
dev-firmware Développement firmware (si configuré)
test-writer Tests TDD depuis le plan/contrats (en parallèle du DEV) — unit/integration/E2E/perf + procédures QA
code-reviewer Revue de code (qualité, sécurité OWASP, performance) + vérification couverture des contrats
qa Exécution des tests et validation (unit/integration/E2E/perf)
infra Validation des procédures de déploiement + infra Docker/Helm/CI
deployer Build (compilation locale, agnostique à l'environnement) + Publication QUALIF/PROD (mécanisme propre à chacun, voir .claude/agents/environments/) + Déploiement QUALIF/PROD — surveille activement la CI lors de PUBLISH PROD, rollback automatique sur échec, remonte les faits à main
doc-updater Mise à jour CHANGELOG, README, documentation technique
security Audit de sécurité (SAST, dépendances, secrets)
pr-reviewer Validation des Pull Requests externes
marketing Communication de release depuis les données GitHub

Principes de communication

  • Livrable = fichier : chaque agent écrit son résultat dans un fichier, le message ne contient que la référence
    • Agents d'analyse → _work/reports/[agent]-[timestamp].md
    • Agents de code → SHA du commit
  • Handoff : chaque agent écrit _work/handoff/[agent]-[timestamp].md avant son DONE — le CDP le transmet au suivant ou l'agent le transmet directement si le CDP l'autorise
  • Validation CDP : à réception de chaque DONE, le CDP lit le rapport ou handoff référencé et vérifie la conformité avant de continuer (jamais le code lui-même)
  • Teammates persistants : tous les agents sont spawned au /start-session et restent en IDLE — le teamleader n'utilise que SendMessage pendant la session, jamais de nouveau spawn

Délégation à des sous-agents temporaires

planner, code-reviewer et qa peuvent, pour un périmètre suffisamment large et décomposable en groupes/dimensions/scopes indépendants, demander au CDP de spawner des sous-agents temporaires et les piloter directement (pair-à-pair, sans relayer via le CDP) — seule exception au principe "tout passe par le CDP". Le CDP reste le seul à spawner et fermer ces sous-agents ; l'agent coordinateur gère le dispatch, la collecte et la consolidation.

Agent Sous-agents Découpage Fermeture
planner sub-planner-N Groupes d'issues indépendants Différée — sortie de Phase Plan (boucle GATE 2 comprise), pour permettre la réutilisation lors des révisions
code-reviewer sub-reviewer-<dimension> Dimensions de la revue (sécurité, performance...) Immédiate — après consolidation du verdict
qa sub-qa-<scope> Scopes de tests (unit/integration/e2e...), chacun isolé dans son propre git worktree créé/nettoyé en Bash Immédiate — après consolidation du verdict

Détail complet du protocole : TEMPLATE_claude/agents/context/TEAMMATES_PROTOCOL.md section 6.

Workflows

Phase Review/QA — parallélisation par défaut

Par défaut, qa démarre dès que test-writer a livré ses scripts — en parallèle de code-reviewer, sans attendre son verdict. Si REVIEW rejette, le travail QA en cours (ou déjà fini) est annulé/ignoré et on repart en DEV comme avant ; la durée totale n'est donc jamais pire que l'ancien enchaînement strictement séquentiel, et souvent meilleure (QA masqué sous REVIEW). Le planner fixe ce comportement via le champ qa_parallelizable: true|false du plan (true par défaut ; false justifié en une ligne si le risque de rejet en review est élevé — scope large, architecture, concurrence sensible). Sans plan, l'orchestrateur applique la même valeur par défaut. Détail complet : TEMPLATE_claude/commands/context/QUALITY.md section 12.

Feature — workflow complet

[GATE 1] Confirmation démarrage
    ↓
PLAN ──────────────────────── contrats API + contracts/CHANGELOG.md + qa_parallelizable
    ↓  (🧵 peut déléguer à des sub-planner-N — groupes d'issues indépendants)
    ↓  label PLANNING
[GATE 2] Validation plan (+ alerte breaking changes si détectés)
    ↓  label EN COURS
    ├──────────────────────────┐
  DEV                     TEST-WRITER ── depuis plan + contrats (TDD)
    └──────────────────────────┘
    ↓  (si backend+frontend parallèle → merge conflicts résolus par dev-backend)
    ↓  [GATE 2b] escalade si conflits non résolvables
    ↓  label EN REVIEW (+ EN QA si qa_parallelizable, dès TEST-WRITER DONE)
    ├──────────────────────────┐
  REVIEW                     QA ── démarre dès TEST-WRITER DONE, sans attendre REVIEW (défaut)
  🧵 sub-reviewer-<dim>       🧵 sub-qa-<scope> (worktree isolé)
    └──────────────────────────┘
    ↓  REVIEW REJECTED → annule/ignore QA ; sinon attend QA si pas encore DONE
    ↓  label DONE
DOC (brouillon) ─────────────── CHANGELOG + documentation technique — pas de version incrémentée
    ↓
INFRA validation QUALIF ────── cohérence procédure/infrastructure
    ↓  [GATE 4b] escalade si écart détecté
    ├────────────────────────────────────────┐
BUILD → PUBLISH QUALIF → DEPLOY QUALIF   DOC (finalize) ── release notes + résultats QA, sans attendre le déploiement
    └────────────────────────────────────────┘
    ↓  BUILD incrémente `a` (compilation locale, agnostique à l'environnement) · GATE 4 attend les DEUX DONE
[GATE 4] Validation manuelle ── CDP présente les scénarios à tester
    ├─ OUI → issue fermée → INFRA validation PROD → PUBLISH PROD → DEPLOY PROD (∥ marketing-release systématique) → milestone si 100%
    └─ NON → label EN COURS (retour DEV) ou PLANNING (retour PLAN) selon l'écart
    ↓  [GATE 4c] escalade si infra PROD incohérente
PUBLISH PROD → DEPLOY PROD ─── merge → tag officiel (déclenche un rebuild déterministe via CI) → installe l'artefact publié par la CI
                               succès : release + milestone
                               échec  : rollback infra → rapport à main → routing agent

Points de validation utilisateur (GATES) :

Gate Moment Action requise
1 Après analyse Confirmer le démarrage
2 Après plan Valider le plan et les contrats API
2b Conflits merge non résolvables Résoudre manuellement
3 3 cycles DEV atteints Continuer ou abandonner
4 BUILD+PUBLISH+DEPLOY QUALIF et DOC (finalize) tous les deux DONE OUI (issue fermée + publish/deploy prod) ou NON (retour DEV ou PLAN)
4b Procédure QUALIF incohérente Corriger avant build/publish/deploy
4c Procédure PROD incohérente Corriger avant publish/deploy

Limitation connue : cette orchestration (Gates 4/4b/4c) n'est câblée que pour la chaîne à 2 environnements QUALIF→PROD. Un environnement supplémentaire déclaré dans infrastructure.environments[] (DEV, PRE-PROD...) se publie/déploie manuellement via /publish <env> et /deploy <env>, hors flux CDP automatisé.

Cycles de correction (max 3 avant escalade) :

  • REVIEW refuse → si QA tournait en parallèle, annulé/ignoré → DEV corrige → REVIEW seul (+ QA si toujours parallélisable) (TEST-WRITER uniquement si scope change)
  • QA échoue → DEV corrige → REVIEW seul (+ QA) (TEST-WRITER uniquement si scope change)
  • Scope change = changement BREAKING ou CHANGED dans contracts/CHANGELOG.md

Bugfix

ANALYSE ── cause racine
    ↓  label EN COURS
    ├──────────────────────────┐
  DEV ── fix minimal       TEST-WRITER ── test de régression depuis la spec du bug
    └──────────────────────────┘
    ↓  label EN REVIEW (+ EN QA si qa_parallelizable, dès TEST-WRITER DONE)
    ├──────────────────────────┐
  REVIEW                     QA ── démarre dès TEST-WRITER DONE, sans attendre REVIEW (défaut)
    └──────────────────────────┘
    ↓  label DONE
DOC (brouillon) ── CHANGELOG (Fixed)
    ↓
BUILD → PUBLISH QUALIF → DEPLOY QUALIF ∥ DOC (finalize) ── GATE 4 attend les deux
    ↓
[GATE 4] OUI → issue fermée → PUBLISH PROD → DEPLOY PROD (∥ marketing-release systématique) ── installe l'artefact publié par la CI

Hotfix (urgence production)

DEV ── fix minimal uniquement
    ↓
REVIEW rapide
    ↓
BUILD → PUBLISH PROD → DEPLOY PROD direct (∥ marketing-release systématique) ── sans passage par QUALIF
    ↓
DOC ── post-mortem

Refactor

QA (avant) ── capture l'état actuel des tests
    ↓
DEV ── refactoring (comportement identique obligatoire)
    ├──────────────────┐
  REVIEW          QA (après) ── vérifie la non-régression, en parallèle de REVIEW (défaut)
    └──────────────────┘
    ↓
DOC (brouillon) ── CHANGELOG (Changed)
    ↓
BUILD → PUBLISH QUALIF → DEPLOY QUALIF ∥ DOC (finalize) ── GATE 4 attend les deux

Contrats API (contract-first)

Pour toute feature impliquant une API, le planner crée les contrats avant le développement :

contracts/
├── http-endpoints.md       # Endpoints REST
├── websocket-actions.md    # Messages WebSocket
├── models.md               # Modèles de données
└── CHANGELOG.md            # Historique BREAKING/NEW/CHANGED

Le frontend consulte les contrats sans les modifier. Le CDP alerte l'utilisateur en GATE 2 si des changements BREAKING sont détectés.

Suivi des issues GitHub

Le CDP met à jour les labels de l'issue associée (via plugin GitHub MCP) à chaque transition de phase :

Label Moment
PLANNING Phase 1 — plan en cours
EN COURS GATE 2 validé — DEV + TEST-WRITER démarrés
EN REVIEW Phase 3 — REVIEW en cours
EN QA Phase 3 — QA en cours (dès TEST-WRITER DONE si parallèle au défaut, sinon après REVIEW)
DONE QA validée
(issue fermée) GATE 4 — utilisateur confirme que l'implémentation est conforme

Un cycle correctif (REVIEW refuse ou QA échoue) remet le label à EN COURS. Si l'utilisateur rejette à GATE 4, le label DONE est retiré et l'issue repart vers EN COURS (correction dans le scope, retour DEV) ou PLANNING (scope invalide, retour PLAN).

Build (compilation locale, agnostique à l'environnement)

/build compile et teste une seule fois, sans dépendre d'un environnement cible, et produit un candidat local versionné (build/candidate_vX.Y.Z/) — aucune CI ni registre impliqués. Un échec ici est toujours un échec de code (compilation, tests, lint), remonté directement à dev.

Publish (mise à disposition, par environnement)

/publish <env> rend ce candidat disponible pour un environnement donné, selon le mécanisme qui lui est propre — principe BORE, voir agents/infra.md section 3 :

  • QUALIF — promote : copie/push du candidat tel quel, zéro rebuild, aucune CI impliquée.
  • PROD — rebuild-ci : merge vers main + tag officiel vX.Y.Z, qui déclenche un rebuild déterministe via la CI (même pipeline, même source figée). Le deployer surveille cette CI jusqu'à complétion et gère les échecs de façon autonome.

La procédure concrète (commandes exactes) de chaque mécanisme vit dans .claude/agents/environments/publish.<env>.md, générés à /init-project depuis TEMPLATE_claude/templates/environments/ selon infrastructure.environments[].publish.mode.

En cas d'échec de PUBLISH PROD (CI) :

Le deployer classe l'échec depuis les logs et remonte les faits, sans corriger lui-même :

Catégorie Signification Agent responsable
CODE Le code est suspect dev
FLAKY Échec non reproductible persistant qa
CONFIG La config CI est en cause, le code est sain infra
INFRA L'infrastructure CI est en cause, le code est sain infra

main décide du routing vers l'agent responsable. Le merge et le tag de la publication échouée sont annulés (rollback) — aucun artefact partiellement publié ne reste référençable.

Déploiement PROD (installation pure, sans build ni merge ni tag)

Le merge vers main et le tag officiel vX.Y.Z ont désormais lieu dans /publish prod, qui déclenche le rebuild déterministe via CI — /deploy prod installe uniquement sur la plateforme PROD l'artefact que cette CI a produit et publié, sans jamais rebuilder ni republier. Comme pour PUBLISH, la procédure d'installation propre au mécanisme (docker-compose, helm, vps...) vit dans .claude/agents/environments/deploy.<env>.md, générés depuis TEMPLATE_claude/templates/environments/ selon infrastructure.environments[].deploy.mechanism.

En cas de succès du rollout :

  • Création de la GitHub Release avec les notes
  • Vérification du milestone actif → clôture automatique si 100% des issues fermées

En cas d'échec du rollout : rollback infra (kubectl rollout undo, réinstallation de la version précédente) — la publication (/publish prod) ayant déjà réussi (CI verte), l'échec ici est toujours un échec d'installation, jamais un échec de code ni de build. Le deployer remonte les faits bruts à main, qui décide de la suite.

Clôture de milestone

Après un déploiement PROD réussi, le CDP vérifie le milestone actif :

  • 100% des issues fermées → milestone clos automatiquement
  • Issues encore ouvertes → alerte utilisateur avec la liste

Marketing en parallèle du déploiement

Le CDP dispatche systématiquement marketing-release en parallèle du deployer à chaque déploiement PROD — tous workflows confondus, y compris Hotfix — sans attendre le résultat de la CI et sans vérifier lui-même l'existence ou le contenu d'un milestone. C'est l'agent marketing qui, une fois lancé, résout lui-même le milestone correspondant à la version — par préfixe, jamais par titre exact (le titre peut porter un nom descriptif après le préfixe, séparateur non garanti, ex. v8.0.0 — Mode RAFALE ou v8.0.0 - Mode RAFALE) — et statue seul sur la pertinence d'une publication en examinant les changements réellement livrés : au moins une issue fermée avec un label visible utilisateur (feature, enhancement, breaking) → prépare du contenu ; sans changement marquant (que des fix/chore/refactor), ou aucun milestone trouvé (repli sur CHANGELOG.md), il s'arrête immédiatement, sans solliciter l'utilisateur.

S'il y a lieu de publier, l'agent prépare le contenu (release notes, posts, site) sans commit, et le CDP relaie la maquette à l'utilisateur pour validation. La publication (commit + push sur gh-pages) n'est déclenchée que lorsque les deux conditions sont réunies : maquette validée par l'utilisateur ET déploiement PROD confirmé réussi — dans n'importe quel ordre. Si le déploiement échoue, rien n'est publié.

Approche TDD

Le test-writer est déclenché en parallèle du DEV, depuis le plan et les contrats API — pas depuis le code livré. Les tests définissent le comportement attendu ; le développeur implémente pour les faire passer.

Règle de non-régression : les tests existants sont immuables. Seul un changement BREAKING ou CHANGED documenté dans contracts/CHANGELOG.md autorise leur mise à jour. Le code-reviewer vérifie que les tests couvrent bien tous les contrats.

Commandes disponibles

Session

Commande Description
/start-session Démarre la session, lit la mémoire projet, affiche le milestone actif
/end-session Clôture la session, shutdown propre des agents, met à jour la mémoire
/team-status État de la team (lecture seule)
/team-delete [--force] Ferme les teammates IDLE, ou tous avec --force
/context-audit [scope] Audit des fichiers de configuration : doublons, refs cassées, dérive template
/init-project Bootstrap, réinitialisation ou synchronisation du template

Développement

Commande Description
/feature <desc> Nouvelle fonctionnalité — workflow complet avec PLAN, DEV parallèle, tests, build, publish, deploy
/bugfix <desc> Correction de bug avec test de régression obligatoire
/hotfix <desc> Correctif urgent production — build, publish puis deploy direct (PROD uniquement, sans QUALIF)
/refactor <desc> Refactoring sans changement fonctionnel — QA avant et après

Backlog et Milestones

Commande Description
/backlog Lister les issues GitHub ouvertes
/backlog <desc> Rechercher une issue et lancer le workflow adapté
/milestone new <version> [date] Créer un milestone et associer des issues
/milestone status Progression du milestone actif (barre %)
/milestone close [version] Clôturer avec gestion des issues non terminées

Suivi d'équipe

Commande Description
/progression Tableau de bord temps réel — statut de chaque agent actif
/team-status État de la team (tableau agents + statut IDLE/EN COURS) — lecture seule
/team-delete [--force] Ferme les teammates IDLE ; --force ferme tous les teammates, y compris ceux EN COURS

Validation

Commande Description
/review Revue de code directe (sans passer par /feature)
/qa Tests et validation qualité directs
/secu Audit de sécurité complet (SAST, OWASP, dépendances, secrets)

Déploiement et Communication

Commande Description
/build Compilation/tests d'une version candidate — locale, agnostique à l'environnement
/publish qualif Mise à disposition du candidat pour QUALIF — promotion, zéro rebuild
/publish prod Mise à disposition du candidat pour PROD — merge + tag officiel, déclenche un rebuild déterministe via CI
/deploy qualif Installation en qualification de l'artefact déjà publié (avec validation infra préalable)
/deploy prod Installation en production de l'artefact publié par la CI — sans build ni merge ni tag (gate explicite requis)
/marketing [version] Release notes depuis milestone + CHANGELOG GitHub

Flux de travail type

/milestone new v1.2.0 2026-06-01    Créer le milestone + associer les issues
        ↓
/start-session                       Voir la progression du milestone
        ↓
/backlog #42                         Travailler une issue
        ↓
/feature "#42 - Auth OAuth"          Workflow complet multi-agents (build + publish + deploy qualif inclus)
        ↓
/deploy prod                         Publie (merge + tag → rebuild CI) puis installe en PROD → proposition de clôture du milestone
        ↓
/marketing v1.2.0                    Release notes depuis le milestone clos

Migration depuis v1 ou v2

Les projets créés avec une architecture antérieure sont détectés automatiquement.

Avec le launcher : ouvrir le projet depuis le menu — init-project.md est bootstrappé automatiquement, puis /init-project détecte et migre.

Sans le launcher :

curl -fsSL \
  https://raw.githubusercontent.com/CCoupel/claude_project_template/main/init-project.md \
  -o <projet>/.claude/commands/init-project.md

# Dans Claude Code :
/init-project
# → "Projet v1/v2 détecté — migration v3 requise"
# → Fetch TEMPLATE_claude/ + .gitignore + nettoyage git + commit automatique

Synchronisation du template

Pour récupérer les nouvelles fonctionnalités du template dans un projet existant :

/init-project → d) Synchroniser le template depuis GitHub

Fetche la dernière version de TEMPLATE_claude/ et :

  • Écrase les commandes (*.md), agents template (*.template.md) et contextes partagés template (context/*.template.md)
  • Met à jour le bloc <!-- BEGIN/END TEAMLEADER_PROTOCOL --> dans CLAUDE.md sans toucher au reste
  • Compare la table ## Agents Disponibles de CLAUDE.md à la structure attendue (agents génériques
    • agents dev-* selon la stack configurée) et la met à jour — documentation uniquement, cette comparaison ne crée/modifie/supprime jamais .claude/agents/*.md
  • Synchronise CLAUDE.md (bloc TEAMLEADER_PROTOCOL + table Agents Disponibles) et .claude/settings.json

Structure de CLAUDE.md — Zone projet / Zone template

CLAUDE.md est divisé en deux zones maintenues séparément :

Zone 1 — Contenu projet           Zone 2 — Règles template
─────────────────────────         ───────────────────────────────────────
Config, stack, commandes,         <!-- BEGIN TEAMLEADER_PROTOCOL -->
mémoire. Jamais écrasé            Rôle CDP, nommage canonique,
par le template.                 délégation stricte, spawn au start-session,
                                  SendMessage only, validation DONE.
                                  <!-- END TEAMLEADER_PROTOCOL -->
                                  Remplacé à chaque sync (step d6).

Table "## Agents Disponibles" — exception documentaire dans la Zone 1 : comparée à la
stack configurée et resynchronisée à chaque sync (step d5d), mais uniquement son texte —
`.claude/agents/*.md` n'est jamais touché par cette resynchronisation.

CLAUDE.md étant chargé nativement par Claude Code à chaque session, les règles de la Zone 2 survivent aux compactages de contexte sans mécanisme de hook supplémentaire.

Détection de doublons et de conflits (automatique à chaque sync)

À chaque synchronisation, Claude analyse les fichiers *.md compagnons (agents et contextes partagés) en deux passes distinctes.

1. Doublons (step d5b) — règles du compagnon qui disent la même chose que le template, devenues redondantes :

Signal Signification Action proposée
[↓] DERIVE-TEMPLATE Le template couvre maintenant ce que vous aviez customisé Simplification possible
[~] MIXTE Une partie du .md est couverte par le template, une autre reste propre au projet Retirer seulement la partie redondante
[=] IDENTIQUE Le .md duplique le template sans rien ajouter Peut être supprimé
[*] PROPRE Rien de redondant — passe à l'analyse de conflits —

La détection opère règle par règle, pas seulement fichier par fichier : dès qu'une règle du .md compagnon se retrouve — littéralement ou en substance, en disant la même chose — dans le template mis à jour, elle peut être retirée du compagnon, même si le reste du fichier reste propre.

2. Conflits (step d5c) — règles du compagnon qui portent sur le même sujet que le template mais disent autre chose (incohérence, pas simple ajout) :

Signal Signification Action proposée
[X] CONFLIT Compagnon et template se contredisent sur le même sujet Arbitrage utilisateur : template, compagnon, ou édition manuelle
— COHERENT Le compagnon ajoute du contenu spécifique sans contredire le template

Chaque conflit est présenté individuellement pour trancher : garder la règle du template (la règle projet est retirée/adaptée), garder la règle du compagnon (dérogation projet assumée, re-signalée aux sync suivantes tant qu'elle diffère), ou éditer manuellement.

Ces analyses sont silencieuses si tout est propre. Elles servent aussi de migration one-shot pour les projets qui avaient du contenu mixte avant l'introduction de la convention.

Personnalisation

Adapter les agents et contextes partagés au projet

Les commandes (*.md) n'ont pas de compagnon — leur comportement se personnalise via les contextes partagés qu'elles référencent (voir plus bas). Les agents et les contextes partagés suivent tous deux le pattern template + compagnon : créer le fichier .md compagnon à côté du .template.md pour surcharger le comportement.

# Exemple : règles spécifiques pour l'agent deployer
touch .claude/agents/deploy.md
# Adaptations projet — deploy

## Conventions de nommage
- Les tags de release suivent le pattern `v<version>-<env>`

## Règles métier spécifiques
- Ne jamais déployer en PROD un vendredi sans validation explicite

Claude lit deploy.template.md (comportement standard) puis deploy.md (règles projet). Le fichier deploy.template.md n'est jamais à modifier — il se met à jour automatiquement.

Même principe pour un contexte partagé, référencé par plusieurs commandes/agents à la fois :

# Exemple : règle de versionnement spécifique au projet
touch .claude/commands/context/COMMON.md
# Adaptations projet — COMMON

## Règle de versionnement spécifique
- Les milestones de ce projet incluent systématiquement un numéro de sprint dans leur description

Claude lit context/COMMON.template.md (règles génériques du template) puis context/COMMON.md (règles projet) — toute commande ou agent référençant "context/COMMON.md" lit en réalité les deux. Le fichier context/COMMON.template.md n'est jamais à modifier — il se met à jour automatiquement.

Forker ce template

Mettre à jour TEMPLATE_claude/.template-source.json dans votre fork :

{
  "repo": "votre-org/votre-fork",
  "branch": "main"
}

Ajouter un template de stack

  1. Créer TEMPLATE_claude/templates/dev-backend-rust.md
  2. Référencer dans init-project.md section "Agents dev-*"

Ajouter un template de workflow CI/CD

  1. Créer TEMPLATE_claude/templates/workflows/release-node-react.yml
  2. Référencer dans init-project.md section "Workflow CI/CD"

About

initialise a Claude Code habits, with commands, workflows and dev team

ccoupel.github.io/claude_project_template/

Topics

cat-ai-agentsportfoliostatus-stable

Resources

Readme
Activity

Stars

1 star

Watchers

0 watching

Forks

0 forks
Report repository

Releases

Packages

Contributors