Router /aiad <sub>

/aiad — rituels, synchronisations et métriques

Là où /sdd porte le cycle de développement, le router /aiad porte la vie de l'équipe : adoption du framework, rituels de synchronisation (standup, demo, retro, ateliers), conformité Tier 1, métriques DORA et Flow, dashboards — et la génération multi-runtime des règles agents.

Comme toutes les commandes du framework, elles supportent le dual-mode --guided / --fast avec auto-détection selon la maturité de .aiad/. La plupart persistent leurs données dans .aiad/metrics/, ce qui rend les métriques organiques : elles émergent du processus, sans saisie manuelle.

Vue d'ensemble

/aiad init — bootstrap sur projet existant

Quand. Pour adopter AIAD sur un projet qui a déjà du code — à la différence de /sdd init, pensé pour un projet neuf.

Ce que ça fait. Diagnostique l'existant (stack, tests, CI/CD, documentation, règles agents déjà présentes), recommande un niveau d'adoption (Léger / Standard / Complet), puis crée la structure .aiad/ pré-remplie depuis le code réel : PRD extrait du README, ARCHITECTURE inférée du code, AGENT-GUIDE construit depuis les conventions visibles. Les éléments existants (ADRs, .cursor/rules, tickets) sont migrés, pas écrasés.

Sortie. Structure .aiad/ initialisée + plan d'adoption progressive en 3 phases (fondations / premiers cycles / consolidation).

/aiad onboard — onboarding nouveau membre

Quand. Un nouveau PE, développeur, PM, AE ou QA rejoint le projet.

Ce que ça fait. Scanne les artefacts (PRD, ARCHITECTURE, AGENT-GUIDE, Intents et SPECs actifs, gouvernance) et génère un briefing adapté au rôle et au niveau de familiarité AIAD — lisible en 15 minutes maximum, avec liens vers les sources plutôt que copier-coller.

Sortie. Briefing contextualisé + checklist Jour 1 / Semaine 1 / Semaine 2 avec un « premier pas recommandé » actionnable.

/aiad status — état du projet

Quand. En standup, en début de session, ou pour un état des lieux à la demande.

Ce que ça fait. Scanne .aiad/, CLAUDE.md et les commandes installées, puis produit un rapport macro : artefacts fondamentaux (OK / Template / Absent), Intents et SPECs actifs, SQS moyen, agents de gouvernance installés, niveau de maturité SDD de 0 (non initialisé) à 5 (complet).

Sortie. Dashboard texte + les 3 prochaines actions prioritaires selon le niveau de maturité détecté.

/aiad health — santé des artefacts

Quand. En fin d'itération, ou quand un signal d'alarme apparaît (agent incohérent, drifts fréquents). Là où status donne une vue macro, health diagnostique artefact par artefact.

Ce que ça fait. Détecte les pathologies : Intents orphelins (sans SPEC) ou zombies (actifs > 30 jours sans activité), SPECs sans SQS, bloquées ou non archivées, index désynchronisés, AGENT-GUIDE obsolète. Inclut l'anti « dock rot » : npx aiad-sdd archive --delivered liste les artefacts clos à sortir du contexte chaud sans creuser de gap de traçabilité.

Sortie. Rapport de santé (SAIN / ATTENTION / CRITIQUE) + actions correctives priorisées.

/aiad gouvernance — conformité Tier 1

Quand. Avant le merge d'une PR ou la validation d'une SPEC impactant des aspects réglementaires.

Ce que ça fait. Détermine les agents Tier 1 applicables au livrable — AIAD-AI-ACT (composant IA), AIAD-RGPD (données personnelles), AIAD-RGAA (interface utilisateur), AIAD-RGESN (ressources), auxquels s'ajoute l'agent AIAD-CRA livré en complément pour les produits logiciels (Cyber Resilience Act — obligation de signalement à l'ENISA en vigueur depuis le 11 septembre 2026) — puis vérifie chaque exigence point par point. Chaque agent dispose d'un droit de veto : un seul point bloquant suffit à refuser le merge. En cas de doute sur l'applicabilité, principe de précaution.

Sortie. Rapport de conformité par référentiel + verdict global CONFORME / NON CONFORME — VETO + actions correctives.

/aiad tech-review — revue technique

Quand. Rituel mensuel (1 à 2 h), animé par le Tech Lead, ou après un changement architectural majeur. Porte sur l'architecture long terme — pas sur la qualité d'une PR (rôle de /sdd validate).

Ce que ça fait. Évalue chaque composant d'ARCHITECTURE.md (sain / attention / critique), analyse les drifts récurrents, recense les ADRs à créer ou réviser et inventorie la dette technique priorisée (criticité × effort).

Sortie. .aiad/metrics/tech-review/YYYY-MM-DD.md + ADRs documentés + mise à jour d'ARCHITECTURE.md et du changelog.

/aiad standup — standup quotidien

Quand. Quotidien ou bi-quotidien, 15 min max, synchrone ou asynchrone. Optionnel : c'est un outil, pas une obligation.

Ce que ça fait. Lit les SPECs in-progress (le WIP), le standup précédent et les drifts non résolus, puis collecte 3 réponses par personne : livré / en cours / blocage. Les blocages sont escaladés selon leur nature (technique → Tech Lead, clarification → PE, externe → PM).

Sortie. .aiad/metrics/standup/YYYY-MM-DD.md avec WIP, blocages et actions.

/aiad demo — demo & feedback

Quand. Hebdomadaire selon la doctrine, ou après chaque fonctionnalité majeure, 30 min à 1 h, avec des participants externes (moins de 2, et la démo ne remplit pas son rôle).

Ce que ça fait. Construit la démo depuis les SPECs done, structurée autour des Intent Statements d'origine (le pourquoi avant le quoi). Collecte chaque feedback avec un signal, sans défendre les choix d'implémentation, et détecte les patterns (3 feedbacks convergents = signal fort). Un rejet sur une feature cœur déclenche un Atelier d'Intention.

Sortie. .aiad/metrics/demo/YYYY-MM-DD.md + feedbacks catégorisés + actions post-démo.

/aiad retro — rétrospective

Quand. En fin d'itération — hebdomadaire ou bi-hebdomadaire selon la doctrine, ou après un incident majeur.

Ce que ça fait. Catégorise strictement les apprentissages : Lessons Learned (erreurs récurrentes de l'agent) et Human Learnings (défaillances de l'intention humaine) — si aucun Human Learning n'émerge, c'est suspect. Calcule les métriques d'itération (taux de réussite au premier passage, drifts). La doctrine v1.9 ajoute une catégorie à part parmi les Human Learnings, les défaillances de supervision, et une question à poser : à quel moment un humain aurait-il dû être consulté, et pourquoi ne l'a-t-il pas été ?

Sortie. Entrées Lessons Learned + Human Learnings intégrées à l'AGENT-GUIDE + métriques d'itération + 1-3 actions responsabilisées.

/aiad intention — Atelier d'Intention

Quand. Rituel mensuel fondamental : « Construisons-nous toujours ce que nous voulions ? ». Pas de métriques, pas de vélocité — uniquement l'intention.

Ce que ça fait. L'agent prépare le terrain (PRD, Intents actifs, Human Learnings) puis facilite les 5 questions : alignement, valeur, intention vs exécution, priorisation, bien-être de l'équipe face aux agents IA. Il documente les réponses telles quelles — jamais il ne décide à la place des humains.

Sortie. Compte-rendu .aiad/intents/ATELIER-INTENTION-YYYY-MM.md avec décisions humaines, responsables et échéances.

/aiad sync-strat — alignement stratégique

Quand. Mensuelle ou bi-mensuelle, quand un Product Goal est atteint ou après un pivot stratégique, 1 h 30 à 2 h, avec PM, PE, AE et Tech Lead — avant le standup pour cascade immédiate.

Ce que ça fait. Facilite 5 blocs time-boxés : contexte et changements externes, révision des Intents actifs, priorisation du backlog, gouvernance, actions. Vérifie la validité du PRD et révise les Outcome Criteria si nécessaire. Un Intent en drift depuis plus de 2 semaines déclenche un Atelier d'Intention.

Sortie. .aiad/metrics/sync-strat/YYYY-MM-DD.md + compte-rendu exécutif avec décisions documentées et Intents mis à jour.

/aiad dora — DORA Metrics

Quand. En rétrospective ou en revue de performance de livraison.

Ce que ça fait. Calcule les 4 indicateurs — Deployment Frequency, Lead Time for Changes, Change Failure Rate, MTTR — depuis .aiad/metrics/deployments/, et positionne chaque métrique sur les niveaux de référence Élite / Haute / Moyenne / Faible.

Sortie. Rapport DORA avec niveau par métrique, analyse causale AIAD et recommandations.

/aiad flow — Flow Metrics

Quand. Pour analyser la fluidité du flux de valeur et détecter les goulots d'étranglement du cycle SDD.

Ce que ça fait. Calcule les 5 indicateurs — Cycle Time, Lead Time, Throughput, WIP, Flow Efficiency — depuis les données persistées, vérifie la loi de Little (Lead Time = WIP / Throughput) et identifie l'étape qui ralentit la livraison.

Sortie. Rapport Flow avec décomposition du Lead Time, goulot principal identifié et recommandations d'optimisation du WIP.

/aiad dashboard — dashboard ASCII

Quand. En rituel d'équipe : hebdomadaire (opérationnel, 15-20 min) ou mensuel (stratégique, 30-45 min).

Ce que ça fait. Agrège toutes les données de .aiad/metrics/ sur la période (deployments, specs, standup, drift, retro — et demo / sync-strat / tech-review en mensuel), calcule les métriques de flux et de qualité et applique des seuils visuels. Les données manquantes sont signalées explicitement : ce sont des signaux de processus, pas des trous à combler par des estimations.

Sortie. Dashboard ASCII structuré, prêt à diffuser, + actions prioritaires.

/aiad dashboard-html — dashboard HTML

Quand. Pour le pilotage continu — un snapshot toujours disponible dans le navigateur, complémentaire du dashboard ASCII de rituel.

Ce que ça fait. Wrapper léger sur la CLI aiad-sdd dashboard : génère un site statique multi-pages dans dashboard/ (vue d'ensemble, intents, specs, traçabilité, métriques, gouvernance, drifts, changelog) + data.json. Options : --out, --serve (+ --port), --source-base pour préfixer les liens vers les sources (GitHub Pages).

Sortie. Dossier dashboard/ régénéré à la demande.

/aiad emit-rules — multi-runtime

Quand. Après toute modification de .aiad/AGENT-GUIDE.md ou de .aiad/gouvernance/, pour réaligner tous les runtimes IA.

Ce que ça fait. AIAD se positionne en source amont : au lieu de maintenir N copies divergentes, la commande régénère toutes les cibles depuis l'AGENT-GUIDE et la gouvernance — AGENTS.md (standard inter-outils, Copilot), le header de CLAUDE.md (Claude Code), .cursor/rules/*.mdc (Cursor, dont les règles Tier 1 scopées par globs), .codex/AGENT.md (Codex), GEMINI.md (Gemini) et, depuis aiad-sdd 1.19.0, les fichiers de steering .kiro/steering/aiad*.md (Kiro). Chaque fichier émis porte un header DO NOT EDIT et un source-hash SHA-256. Régénération idempotente ; ciblage possible via --runtime cursor,codex.

Sortie. Résumé + créés ↑ régénérés ✓ inchangés. En mode --check (CI), exit 1 si divergence — le workflow aiad-emit-rules-check.yml bloque toute PR qui modifie l'AGENT-GUIDE sans régénérer les cibles, ou qui édite manuellement un fichier dérivé.

Alias plats dépréciés