Claude project template

Le cadre que j'utilise pour tous mes projets

Claude project template est le squelette que je clone au démarrage de chaque nouveau projet. Il câble un framework de dev avec Claude Code autour d'un cycle simple :

/next-issue → /start-issue → coder → /open-pr → /merge-pr

Le pilotage projet — issues, ADR, sprints — vit dans un vault Obsidian local, en frontmatter YAML strict. Le code, les PR et la CI restent sur GitHub. Un bridge CI léger garde la note du vault à jour quand une PR merge, même depuis l'interface web de GitHub. Pas de dépendance à GitHub Projects v2, qui sature trop vite côté quota GraphQL.

Pourquoi un vault plutôt que Projects v2

Les ADR et le grooming contiennent de la stratégie ; je préfère les garder dans un espace privé, versionné, lisible hors-ligne dans Obsidian, plutôt que dans un outil propriétaire. Le vault est la source de vérité du quoi et du pourquoi ; GitHub reste la source de vérité du code. Le board Kanban est une simple vue Obsidian Bases groupée par status.

Le cycle de vie d'un ticket

Une casquette PM (/roadmap) définit la vision et priorise les épics. Une casquette PO (/groom) découpe un épic en issues bien formées, directement en notes vault. Puis /next-issue choisit la prochaine issue prête, /start-issue crée la branche et passe le statut en cours, et après implémentation /open-pr puis /merge-pr lancent le reviewer, attendent la CI verte et squash-mergent. Un hook pre-push bloque les push directs sur main.

Migrer un projet existant

Le template fournit des scripts pour basculer un projet déjà en place vers ce workflow : import des issues GitHub (open + closed, REST uniquement), conversion des ADR legacy en frontmatter YAML avec patch des cross-références. Mon bot Luchamon a été migré par cette même chaîne — 156 issues et 23 ADR d'un coup.

Ce template n'a pas de roadmap publique : il évolue au fil des best practices que je définis dans mes projets actifs, comme Orfeo et Luchamon Bot.