Toolkit qui transforme Claude Code en équipe Aigile complète. Tout tient en 4 phases de travail + des outils transverses.
Toute la stack repose là-dessus. Comprendre ces 3 mots, c'est comprendre Aigile Stack.
Une commande /aigile-<nom> que tu déclenches toi-même. C'est ton interface avec la stack.
Jamais lancé à la main. Un skill le déclenche pour un audit indépendant en lecture seule. Un œil critique, pas de l'auto-évaluation.
Intercepte une action de Claude (commande, édition, fin de session) pour confirmer, bloquer ou suggérer. En arrière-plan.
Ces skills ne suivent pas le flux d'un projet : tu les actives quand le contexte l'exige. On les pose d'abord, pour les sortir du chemin.
Garde-fous activables. Une fois actifs, ce sont les hooks check-careful et check-freeze qui appliquent les règles.
Pour piloter Aigile Stack au quotidien : démarrer une session, capitaliser, mettre à jour, mesurer.
up · down · status · doctor · isolate — Supabase local + Next sur les ports dédiés du projet, isolation des builds.learn (learnings) · update (mise à jour) · analytics (stats usage) · help (aide offline).Brique d'automatisation ponctuelle, créée quand le projet en a besoin — pas une étape du cycle de lot.
Retravaille un texte pour lui enlever le côté « généré par IA » et le rendre naturel.
Chaque skill (bleu) est listé dans sa phase, avec, dessous, les sous-agents verts qu'il déclenche automatiquement.
Transformer un prospect en proposition signée : cadrer, chiffrer, proposer.
De l'identité client aux pages Next.js statiques production-ready. Un seul skill à 3 modes — la sortie est le vrai code du projet.
brief (design system) → shotgun (variantes, optionnel) → nextjs (pages Next.js + composants UI + Vercel preview + smoke tests Playwright). Pas de maquette HTML jetable : le code produit est réutilisé directement en dev. Emails fictifs : @team383451.testinator.email.Le cœur du dev : scaffolder, développer par lots, et garantir la qualité à chaque clôture de lot. Le quality gate est l'étape de clôture.
playwright.config.ts + dossier e2e/).start vérifie qu'il y a une seule story, clarifie en 5 questions max, écrit le plan par phases ([P] = parallélisable) et génère e2e/lot-N.spec.ts depuis les scénarios d'acceptation ; close déclenche le gate.aigile-precheck.sh d'abord (arbre propre, build, lint, tests, suite e2e complète une fois, secrets, RLS, conventions — déterministe, chronométré), puis les sous-agents en parallèle, dimensionnés par palier (XS ≤ 3 fichiers : reviewer security seul, 3 min · S ≤ 10 : + lot-reviewer + un reviewer pour le reste, 6 min). Budget contractuel : au double, verdict et reste en backlog. Un finding préexistant ne bloque pas le lot et part au backlog Critique, jamais corrigé dans le gate. Bloque le merge si un feu est rouge.code (relit le diff) · app (teste l'app qui tourne) · security (14 phases). Le quotidien passe par le gate (auto).Mettre en prod, livrer au client, suivre dans la durée.
dev, PR dev→main, puis tag sur le merge commit. Jamais de commit de release en direct sur main.--doc seule), accès, formation, backup, support 30j.Les 9 sous-agents ne se lancent jamais seuls. Voici qui les déclenche, et pour quoi.
| Sous-agent | Déclenché par | Mission (lecture seule) |
|---|---|---|
| cadreur | /aigile-cadrage | Audit cadrage : complétude, libellés non techniques, zones floues, risques projet |
| chiffreur | /aigile-chiffrage | Audit chiffrage : ordre de grandeur global, sur- et sous-estimations, incohérences, tarifs |
| design-reviewer | /aigile-design nextjs | Audit pages Next.js : design system, composants, responsive, WCAG, perf |
| rls-auditor | /aigile-supabase-rls · /aigile-gate | Audit RLS : USING(true), couverture, indexes, SECURITY DEFINER |
| code-reviewer | /aigile-audit code · /aigile-gate | Audit du diff multi-focus (security, perf, testing…), en parallèle |
| security-verifier | /aigile-audit security · /aigile-gate | Filtre les false positives sécurité via exploit scenarios |
| qa-reporter | /aigile-audit app · /aigile-gate (si UI) | Catégorise les findings QA, calcule le health score |
| lot-reviewer | /aigile-gate (clôture lot) | Fiche ↔ diff : critères de fin couverts, dérive de périmètre, doc. Le mécanique est fait par aigile-precheck.sh |
| livraison-auditor | /aigile-livraison | Audit livraison : tech, doc, accès, backup, Notion, Airtable… |
/aigile-gate est le seul skill orchestrateur : il lance scripts/aigile-precheck.sh (déterministe, une seule fois) puis 3 à 6 sous-agents en parallèle selon le palier du diff (S / M / L) à la clôture d'un lot (qa-reporter ne lit le rapport Playwright que si la suite e2e du précheck a un échec ; bloquant si le lot touche l'UI). Objectif : moins de 6 min pour un lot d'une story. Les sous-agents à checklist tournent sur Sonnet ; code-reviewer garde le modèle de la session.
Les 8 gardes automatiques, la statusline, et les variables qui pilotent tout ça.
.git/, supabase/migrations/ et .env* demandent validation. Toujours actif, indépendant de /aigile-safety./aigile-safety careful. Respecte les exemptions de portée : suppression dans le projet et SQL destructif sur base locale passent sans demande./aigile-safety freeze.localhost (instance Docker locale du projet) — db reset, DROP, TRUNCATE compris, c'est une base de test — et bloque toute cible prod.npm run build et rm -rf .next tant qu'un serveur de dev du projet écoute — le build écraserait son .next. Rediriger vers npm run build:check.next dev sur les ports dédiés du projet (PORTS.md). Idempotent.next dev de la session, purge les builds isolés .next-*. Supabase reste en marche.
Statusline en temps réel · variables : AIGILE_LEARNING_PROMPT, AIGILE_ANALYTICS, AIGILE_PROJECTS_ROOT (toutes désactivables avec =0).