Spec-Kitty vs Superpowers : deux frameworks pour structurer Claude Code

Claude Code est puissant, mais livré à lui-même il fonce tête baissée dans le code sans planifier, sans tester, et sans structure. Deux projets open-source proposent de corriger ça : Spec-Kitty (Priivacy-ai) et Superpowers (Jesse Vincent / obra). Même ambition, transformer Claude en ingénieur senior discipliné, mais des philosophies radicalement différentes.

Le problème commun

Par défaut, Claude Code :

Saute la phase de conception : il code avant de comprendre
Ne fait pas de TDD : les tests arrivent après, ou jamais
Perd le fil sur les features complexes : pas de suivi de progression
Mélange tout dans une seule branche : merge conflicts garantis

Les deux frameworks imposent une structure au workflow de développement. Mais l’un pense “spécifications exécutables”, l’autre pense “compétences composables”.

Workflow comparé

flowchart LR
    subgraph SK["Spec-Kitty"]
        direction TB
        SK1[Constitution] --> SK2[Specify]
        SK2 --> SK3[Plan]
        SK3 --> SK4[Tasks / Work Packages]
        SK4 --> SK5[Implement<br/>git worktree isolé]
        SK5 --> SK6[Review]
        SK6 --> SK7[Merge]
    end

    subgraph SP["Superpowers"]
        direction TB
        SP1[Brainstorm] --> SP2[Write Plan]
        SP2 --> SP3[Execute Plan<br/>subagents]
        SP3 --> SP4[TDD Red-Green-Refactor]
        SP4 --> SP5[Code Review]
        SP5 --> SP6[Finish Branch]
    end

Figure 1: Comparaison des workflows Spec-Kitty et Superpowers

Architecture comparée

Spec-Kitty : le chef de projet avec dashboard

Spec-Kitty est un CLI Python (spec-kitty-cli) qui orchestre le développement autour de spécifications vivantes. Il traite les specs comme la source de vérité : chaque ligne de code doit être traçable à une exigence.

flowchart TB
    CLI["spec-kitty CLI<br/>(Python 3.11+)"]
    CONST["Constitution<br/>.kittify/memory/"]
    SPECS["Specs & Plans<br/>Markdown + YAML frontmatter"]
    WP["Work Packages<br/>WP01, WP02, WP03..."]

    CLI --> CONST
    CLI --> SPECS
    SPECS --> WP

    subgraph EXEC["Exécution parallèle"]
        WT1["Worktree 1<br/>Claude Code"]
        WT2["Worktree 2<br/>Cursor"]
        WT3["Worktree 3<br/>Gemini CLI"]
    end

    WP --> WT1
    WP --> WT2
    WP --> WT3

    DASH["Dashboard Kanban<br/>WebSocket temps réel<br/>port 3000-5000"]
    CLI --> DASH
    WT1 -.-> DASH
    WT2 -.-> DASH
    WT3 -.-> DASH

Figure 2: Architecture Spec-Kitty

Ce qu’il installe :

.claude/commands/ : 13 slash commands pour Claude Code
.kittify/ : scripts, templates, mémoire projet, constitution
Un dashboard kanban local avec mise à jour en temps réel

Le state management repose sur du YAML frontmatter dans les fichiers Markdown des work packages :

title: Ajouter l'authentification JWT
status: doing  # planned | doing | for_review | done
assigned_to: claude
dependencies: [WP01, WP03]

Chaque activité est loguée avec timestamp ISO 8601. Pas de base de données séparée, tout est dans les fichiers, versionné avec Git.

Superpowers : le coach de méthodologie

Superpowers est un plugin Claude Code qui enseigne des compétences à l’agent via des fichiers SKILL.md. Pas de CLI externe, pas de dashboard, juste des instructions structurées que Claude lit et applique.

flowchart LR
    PLUGIN["Plugin Claude Code"] --> META["Meta-skill<br/>using-superpowers"]
    META -->|"active le skill<br/>pertinent"| SKILLS

    subgraph SKILLS["Skills par catégorie"]
        direction TB
        CAT1["Conception<br/>brainstorming · writing-plans"]
        CAT2["Exécution<br/>executing-plans · TDD · debugging"]
        CAT3["Qualité<br/>code-review · verification"]
        CAT1 --> CAT2 --> CAT3
    end

    SKILLS --> MAIN["Agent principal<br/>(manager)"]
    MAIN --> SUB1["Subagent<br/>tâche + review spec"]
    MAIN --> SUB2["Subagent<br/>tâche + review qualité"]

Figure 3: Architecture Superpowers

L’insight clé : les skills ne sont pas du code, ce sont des documents d’instruction que Claude internalise. Jesse Vincent a découvert que les principes de persuasion psychologique (Cialdini) fonctionnent sur les LLMs. Chaque skill est “pressure-testé” avec des scénarios réalistes pour que l’agent ne rationalise pas de raccourcis.

Le meta-skill using-superpowers impose l’utilisation avec un langage volontairement extrême :

“IF A SKILL APPLIES TO YOUR TASK, YOU DO NOT HAVE A CHOICE. YOU MUST USE IT. This is not negotiable.”

Les 13 commandes Spec-Kitty

Commande	Rôle
`/spec-kitty.constitution`	Définir les principes du projet (ADN architectural)
`/spec-kitty.specify`	Créer la spec via interview de découverte
`/spec-kitty.plan`	Architecture technique, modèles de données, contrats API
`/spec-kitty.research`	Investiguer les bonnes pratiques
`/spec-kitty.tasks`	Découper en work packages avec dépendances
`/spec-kitty.implement`	Lancer l’implémentation (worktree isolé)
`/spec-kitty.review`	Quality gate : validation contre la constitution
`/spec-kitty.merge`	Auto-résolution des conflits, nettoyage worktree
`/spec-kitty.dashboard`	Ouvrir le kanban temps réel
`/spec-kitty.ask`	Interroger le contexte projet
`/spec-kitty.status`	Statut des work packages
`/spec-kitty.history`	Logs d’activité
`/spec-kitty.help`	Documentation

Les 14 skills Superpowers

Skill	Rôle
`brainstorming`	Questionnement socratique avant tout code
`writing-plans`	Plans détaillés en tâches de 2-5 min
`executing-plans`	Exécution par batch avec checkpoints humains
`subagent-driven-development`	Un subagent frais par tâche + review en 2 étapes
`dispatching-parallel-agents`	Workflows subagents concurrents
`test-driven-development`	RED-GREEN-REFACTOR strict, anti-rationalisation
`systematic-debugging`	Analyse root cause en 4 phases
`verification-before-completion`	Vérification obligatoire avant de marquer “done”
`using-git-worktrees`	Isolation des branches de dev
`requesting-code-review`	Checklist pré-review
`receiving-code-review`	Intégration du feedback
`finishing-a-development-branch`	Merge/PR workflow
`using-superpowers`	Meta-skill : force l’utilisation des skills
`writing-skills`	Créer de nouveaux skills

Tableau comparatif détaillé

Critère	Spec-Kitty (Priivacy-ai)	Superpowers (obra)
Type	CLI Python + slash commands	Plugin Claude Code (SKILL.md)
Installation	`pip install spec-kitty-cli`	`/plugin marketplace add` + `/plugin install`
Approche	Specification-Driven Development	Skills-Driven Development
Source de vérité	Specs YAML + Markdown	Plans Markdown + skills
Agents supportés	12 (Claude, Cursor, Gemini, Copilot…)	Claude Code (+ Codex, OpenCode)
Multi-agent	Natif : agents parallèles sur worktrees	Subagents séquentiels dans la session
Dashboard	Kanban WebSocket temps réel	Aucun (tout dans le terminal)
Git worktrees	Central au workflow	Skill optionnel
TDD	Promu dans les principes	Imposé avec anti-rationalisation
State management	YAML frontmatter + logs ISO 8601	Fichiers plan + progress.md
Autonomie agent	Heures (spec comme contrat)	Heures (plan comme contrat)
Tracking progression	Dashboard + statuts WP	progress.md + verification.md
Skills lab / expérimental	Non	Oui (superpowers-lab)
Communauté	581 stars, 47 forks	47.3k stars
Licence	MIT	MIT
Maturité	v0.14.2, changelog actif	v4.2.0, très actif

Ce que j’en retiens

Spec-Kitty excelle sur…

L’orchestration multi-agent. C’est son avantage majeur. Tu peux assigner Claude Code sur WP01, Cursor sur WP02, et Gemini CLI sur WP03, chacun dans son worktree isolé, avec le dashboard qui montre la progression en temps réel. Pour une équipe ou un dev qui jongle entre plusieurs agents, c’est un game changer.

La traçabilité. Chaque ligne de code est traçable à une spec, chaque spec validée contre la constitution. La conflict forecasting prévient les problèmes de merge avant qu’ils n’arrivent. C’est du vrai project management appliqué au code AI.

Le dashboard. Visualiser l’avancement sur un kanban avec les lanes Planned → Doing → For Review → Done → Merged, c’est concret. Surtout quand on a 5+ work packages en parallèle.

flowchart LR
    P["Planned"] --> D["Doing"]
    D --> R["For Review"]
    R --> DN["Done"]
    DN --> M["Merged"]

    style P fill:#e3f2fd
    style D fill:#fff3e0
    style R fill:#f3e5f5
    style DN fill:#e8f5e9
    style M fill:#f1f8e9

Figure 4: Flux Kanban Spec-Kitty

Superpowers excelle sur…

L’enforcement méthodologique. Là où Spec-Kitty structure le quoi (specs, tasks, statuts), Superpowers structure le comment. Le TDD n’est pas une suggestion, c’est une obligation avec un arsenal anti-rationalisation. Le skill inclut un tableau de “Common Rationalizations” et “Red Flags” pour contrer chaque excuse de sauter les tests.

La simplicité d’installation. Deux commandes et c’est fait. Pas de Python, pas de pip, pas de daemon. Le plugin se met à jour automatiquement via le marketplace.

Le subagent pattern. Chaque tâche est exécutée par un subagent frais (contexte propre) avec une review en 2 étapes : conformité à la spec, puis qualité du code. Le contexte principal ne se pollue pas.

L’écosystème. 47k+ stars, un marketplace de plugins compagnons (superpowers-lab, Elements of Style, Developing for Claude Code), une communauté massive. C’est devenu un standard de facto.

Les limites des deux

Spec-Kitty est plus complexe à mettre en place. Il faut Python 3.11+, comprendre le concept de constitution, rédiger les specs avant de coder. C’est puissant mais l’overhead est réel pour un petit projet solo. La v0.14 montre un projet en évolution rapide ; l’API peut encore bouger.

Superpowers ne fait pas de multi-agent cross-tool. Si tu veux orchestrer Claude + Cursor + Gemini en parallèle, il faut le gérer manuellement. Pas de dashboard, pas de tracking visuel, tout passe par des fichiers Markdown. Et le “pressure testing” psychologique des skills, aussi innovant soit-il, dépend de la compliance du modèle qui peut varier entre les versions.

Quel framework pour quel usage ?

flowchart TD
    START{{"Tu travailles avec<br/>plusieurs agents IA ?"}}
    START -->|Oui| SK["Spec-Kitty"]
    START -->|Non| Q2{{"Tu veux un dashboard<br/>de suivi ?"}}
    Q2 -->|Oui| SK
    Q2 -->|Non| Q3{{"Projet solo avec<br/>Claude Code seul ?"}}
    Q3 -->|Oui| SP["Superpowers"]
    Q3 -->|Non| Q4{{"Besoin de traçabilité<br/>spec → code ?"}}
    Q4 -->|Oui| SK
    Q4 -->|Non| SP

    style SK fill:#e8f5e9,stroke:#2e7d32
    style SP fill:#e3f2fd,stroke:#1565c0

Figure 5: Arbre de décision : Spec-Kitty ou Superpowers ?

Situation	Choix
Projet solo, Claude Code uniquement	Superpowers
Multi-agent (Claude + Cursor + Gemini)	Spec-Kitty
Feature complexe, besoin de tracking visuel	Spec-Kitty
Enforcement TDD strict	Superpowers
Installation minimale, zéro friction	Superpowers
Équipe avec process de review formel	Spec-Kitty
Debugging systématique	Superpowers
Large feature avec 10+ work packages	Spec-Kitty

Et quand on veut faire évoluer après la première livraison ?

C’est la question qu’on se pose vite en pratique : la feature est mergée, mais le besoin évolue. Faut-il tout reprendre depuis le début ?

Avec Spec-Kitty : non, on ne repart pas de zéro

La constitution reste. Elle ne change que si les principes fondamentaux du projet changent (rare). Pour une évolution de feature :

Re-specify (/spec-kitty.specify) : mettre à jour la spec existante ou en créer une nouvelle pour l’évolution. L’interview de découverte cible uniquement le delta.
Re-plan (/spec-kitty.plan) : adapter l’architecture technique au changement.
Nouveaux work packages (/spec-kitty.tasks) : seuls les WP nécessaires sont créés. Les anciens (merged) restent comme historique.

Le dashboard montre les nouveaux WP à côté des anciens. La traçabilité spec → code est préservée sur toute la durée de vie de la feature.

En pratique, si le changement est mineur (correction d’un edge case, ajout d’un champ), on peut sauter directement à /spec-kitty.tasks sans re-specify. Si c’est un pivot significatif (changement d’API, nouveau flow utilisateur), mieux vaut repasser par specify + plan pour garder la traçabilité.

Avec Superpowers : nouveau cycle brainstorm → plan

Superpowers ne conserve pas d’état entre les sessions. Chaque évolution lance un nouveau cycle :

Brainstorm (/superpowers:brainstorm) : clarifier le changement, ses impacts sur le code existant.
Write Plan (/superpowers:write-plan) : nouveau plan qui référence le code déjà en place.
Execute : les subagents travaillent sur le delta.

L’ancien plan reste dans le repo comme documentation, mais il n’y a pas de lien formel entre les itérations. C’est plus léger (pas de spec à maintenir) mais moins traçable.

flowchart LR
    subgraph SK["Spec-Kitty"]
        direction TB
        SKA["Spec existante"] -->|"mise à jour"| SKB["Re-specify<br/>(delta uniquement)"]
        SKB --> SKC["Nouveaux WP"]
        SKC --> SKD["Implement + Review + Merge"]
    end

    subgraph SP["Superpowers"]
        direction TB
        SPA["Code existant"] -->|"nouveau cycle"| SPB["Brainstorm"]
        SPB --> SPC["Nouveau plan"]
        SPC --> SPD["Execute + TDD + Review"]
    end

Figure 6: Évolution d’une feature : deux approches

Peut-on utiliser les deux ensemble ?

En théorie, oui. Spec-Kitty gère l’orchestration projet (specs, work packages, dashboard) et Superpowers impose la discipline méthodologique (TDD, debugging, review) au sein de chaque session Claude Code.

En pratique, le risque de conflit est réel : les deux injectent des instructions dans le contexte de Claude, les deux veulent contrôler le workflow de planification. Mieux vaut en choisir un et s’y tenir, ou à la rigueur utiliser Spec-Kitty pour l’orchestration multi-agent et activer seulement les skills TDD/debugging de Superpowers à l’intérieur des sessions.

Combiner avec cmem ou claude-mem pour la mémoire

Spec-Kitty et Superpowers structurent le workflow, mais aucun des deux ne résout le problème de la mémoire entre sessions. Claude Code oublie toujours tout au redémarrage. C’est là que cmem ou claude-mem entrent en jeu.

Le combo naturel :

Couche	Rôle	Outils
Méthodologie	Structurer le workflow de dev	Spec-Kitty ou Superpowers
Mémoire	Se souvenir des sessions précédentes	cmem ou claude-mem

Spec-Kitty + mémoire

Spec-Kitty a déjà une forme de mémoire projet via .kittify/memory/ et la constitution. Mais c’est une mémoire structurée (specs, décisions d’architecture), pas une mémoire conversationnelle. Ajouter cmem ou claude-mem permet de retrouver le contexte des sessions passées : les bugs rencontrés, les choix techniques discutés, les patterns découverts.

Attention : les deux injectent du contexte via MCP. Avec Spec-Kitty qui gère déjà 13 slash commands + ses propres fichiers de contexte, surveiller la taille de la fenêtre de contexte. cmem est préférable ici grâce à son sub-agent pattern qui ne pollue pas le contexte principal.

Superpowers + mémoire

Superpowers ne conserve pas d’état entre sessions, c’est par design. Les plans restent dans le repo, mais Claude ne les retrouve pas automatiquement. C’est le cas d’usage idéal pour un outil de mémoire :

claude-mem capture les observations d’outils (tool usage) et les catégorise. Au lancement d’une nouvelle session, Claude retrouve les décisions passées, les bugs corrigés, les patterns du projet.
cmem indexe les sessions complètes et les synthétise à la demande via un sub-agent.

Les deux sont compatibles avec Superpowers puisque les skills ne font qu’ajouter des instructions ; ils n’interfèrent pas avec les serveurs MCP.

Pour le détail de cmem vs claude-mem, voir le comparatif dédié.

Installation rapide

Spec-Kitty

# Installer le CLI
pip install spec-kitty-cli

# Initialiser un projet existant
spec-kitty init --here --ai claude

# Vérifier le setup
spec-kitty verify-setup

# Lancer le dashboard
spec-kitty dashboard

Superpowers

# Dans Claude Code :
/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace

# Vérifier : lancer une nouvelle session et demander de planifier
# Claude devrait automatiquement utiliser le skill brainstorming

Liens

Spec-Kitty : GitHub, Documentation, PyPI
Superpowers : GitHub, Blog de l’auteur, Marketplace
Superpowers Lab (skills expérimentaux) : GitHub

Testé en février 2026. Les deux projets évoluent vite ; vérifier les versions actuelles avant installation.