Router /aiad <sub>

/aiad — rituals, synchronisations and metrics

Where /sdd carries the development cycle, the /aiad router carries the life of the team: framework adoption, synchronisation rituals (standup, demo, retro, workshops), Tier 1 compliance, DORA and Flow metrics, dashboards — and the multi-runtime generation of agent rules.

Like every command in the framework, they support the --guided / --fast dual-mode with auto-detection based on the maturity of .aiad/. Most of them persist their data in .aiad/metrics/, which makes the metrics organic: they emerge from the process, with no manual entry.

Overview

/aiad init — bootstrap on an existing project

When. To adopt AIAD on a project that already has code — unlike /sdd init, which is designed for a fresh project.

What it does. Diagnoses the existing setup (stack, tests, CI/CD, documentation, agent rules already in place), recommends an adoption level (Light / Standard / Full), then creates the .aiad/ structure pre-filled from the real code: PRD extracted from the README, ARCHITECTURE inferred from the code, AGENT-GUIDE built from the visible conventions. Existing elements (ADRs, .cursor/rules, tickets) are migrated, not overwritten.

Output. Initialised .aiad/ structure + a progressive 3-phase adoption plan (foundations / first cycles / consolidation).

/aiad onboard — new member onboarding

When. A new PE, developer, PM, AE or QA joins the project.

What it does. Scans the artifacts (PRD, ARCHITECTURE, AGENT-GUIDE, active Intents and SPECs, governance) and generates a briefing tailored to the role and to the level of AIAD familiarity — readable in 15 minutes at most, with links to the sources rather than copy-paste.

Output. Contextualised briefing + Day 1 / Week 1 / Week 2 checklist with an actionable "recommended first step".

/aiad status — project state

When. At standup, at session start, or for an on-demand status check.

What it does. Scans .aiad/, CLAUDE.md and the installed commands, then produces a macro report: foundational artifacts (OK / Template / Missing), active Intents and SPECs, average SQS, installed governance agents, SDD maturity level from 0 (not initialised) to 5 (complete).

Output. Text dashboard + the next 3 priority actions according to the detected maturity level.

/aiad health — artifact health

When. At end of iteration, or when an alarm signal appears (inconsistent agent, frequent drifts). Where status gives a macro view, health diagnoses artifact by artifact.

What it does. Detects the pathologies: orphan Intents (without a SPEC) or zombie Intents (active > 30 days with no activity), SPECs without an SQS, blocked or not archived, desynchronised indexes, stale AGENT-GUIDE. Includes the anti "dock rot" measure: npx aiad-sdd archive --delivered lists the closed artifacts to move out of the hot context without digging a traceability gap.

Output. Health report (HEALTHY / WARNING / CRITICAL) + prioritised corrective actions.

/aiad gouvernance — Tier 1 compliance

When. Before merging a PR or validating a SPEC affecting regulatory aspects.

What it does. Determines the Tier 1 agents applicable to the deliverable — AIAD-AI-ACT (AI component), AIAD-RGPD (personal data), AIAD-RGAA (user interface), AIAD-RGESN (resources), plus the AIAD-CRA agent shipped as a complement for software products (Cyber Resilience Act — reporting obligation to ENISA in force since 11 September 2026) — then checks each requirement point by point. Each agent holds a veto right: a single blocking point is enough to refuse the merge. When applicability is in doubt, the precautionary principle applies.

Output. Compliance report per framework + overall verdict COMPLIANT / NON-COMPLIANT — VETO + corrective actions.

/aiad tech-review — technical review

When. Monthly ritual (1 to 2 h), facilitated by the Tech Lead, or after a major architectural change. Focuses on long-term architecture — not on the quality of a PR (that is the role of /sdd validate).

What it does. Assesses each component of ARCHITECTURE.md (healthy / warning / critical), analyses recurring drifts, lists the ADRs to create or revise and inventories the prioritised technical debt (criticality × effort).

Output. .aiad/metrics/tech-review/YYYY-MM-DD.md + documented ADRs + update of ARCHITECTURE.md and the changelog.

/aiad standup — daily standup

When. Daily or twice daily, 15 min max, synchronous or asynchronous. Optional: it is a tool, not an obligation.

What it does. Reads the in-progress SPECs (the WIP), the previous standup and the unresolved drifts, then collects 3 answers per person: delivered / in progress / blocked. Blockers are escalated according to their nature (technical → Tech Lead, clarification → PE, external → PM).

Output. .aiad/metrics/standup/YYYY-MM-DD.md with WIP, blockers and actions.

/aiad demo — demo & feedback

When. Weekly according to the doctrine, or after each major feature, 30 min to 1 h, with external participants (fewer than 2, and the demo does not fulfil its purpose).

What it does. Builds the demo from the done SPECs, structured around the original Intent Statements (the why before the what). Collects each piece of feedback with a signal, without defending the implementation choices, and detects patterns (3 converging feedbacks = strong signal). A rejection on a core feature triggers an Intent Workshop.

Output. .aiad/metrics/demo/YYYY-MM-DD.md + categorised feedback + post-demo actions.

/aiad retro — retrospective

When. At end of iteration — weekly or bi-weekly according to the doctrine, or after a major incident.

What it does. Strictly categorises the learnings: Lessons Learned (recurring agent mistakes) and Human Learnings (failures of the human intent) — if no Human Learning emerges, that is suspicious. Computes the iteration metrics (first-pass success rate, drifts). Doctrine v1.9 adds a separate category among the Human Learnings, oversight failures, and a question to ask: at what point should a human have been consulted, and why were they not?

Output. Lessons Learned + Human Learnings entries integrated into the AGENT-GUIDE + iteration metrics + 1-3 actions with owners.

/aiad intention — Intent Workshop

When. Foundational monthly ritual: "Are we still building what we wanted?". No metrics, no velocity — only the intent.

What it does. The agent prepares the ground (PRD, active Intents, Human Learnings) then facilitates the 5 questions: alignment, value, intent vs execution, prioritisation, team well-being in the face of AI agents. It documents the answers as they are — it never decides in place of the humans.

Output. Minutes .aiad/intents/ATELIER-INTENTION-YYYY-MM.md with human decisions, owners and deadlines.

/aiad sync-strat — strategic alignment

When. Monthly or bi-monthly, when a Product Goal is reached or after a strategic pivot, 1 h 30 to 2 h, with PM, PE, AE and Tech Lead — before the standup for immediate cascading.

What it does. Facilitates 5 time-boxed blocks: context and external changes, review of active Intents, backlog prioritisation, governance, actions. Verifies the validity of the PRD and revises the Outcome Criteria if necessary. An Intent in drift for more than 2 weeks triggers an Intent Workshop.

Output. .aiad/metrics/sync-strat/YYYY-MM-DD.md + executive minutes with documented decisions and updated Intents.

/aiad dora — DORA Metrics

When. In a retrospective or in a delivery performance review.

What it does. Computes the 4 indicators — Deployment Frequency, Lead Time for Changes, Change Failure Rate, MTTR — from .aiad/metrics/deployments/, and positions each metric on the Elite / High / Medium / Low reference levels.

Output. DORA report with a level per metric, AIAD causal analysis and recommendations.

/aiad flow — Flow Metrics

When. To analyse the fluidity of the value stream and detect the bottlenecks of the SDD cycle.

What it does. Computes the 5 indicators — Cycle Time, Lead Time, Throughput, WIP, Flow Efficiency — from the persisted data, verifies Little's law (Lead Time = WIP / Throughput) and identifies the step that slows down delivery.

Output. Flow report with a Lead Time breakdown, the main bottleneck identified and WIP optimisation recommendations.

/aiad dashboard — ASCII dashboard

When. As a team ritual: weekly (operational, 15-20 min) or monthly (strategic, 30-45 min).

What it does. Aggregates all the data from .aiad/metrics/ over the period (deployments, specs, standup, drift, retro — plus demo / sync-strat / tech-review in monthly mode), computes the flow and quality metrics and applies visual thresholds. Missing data is flagged explicitly: it is a process signal, not a hole to be filled with estimates.

Output. Structured ASCII dashboard, ready to share, + priority actions.

/aiad dashboard-html — HTML dashboard

When. For continuous steering — a snapshot always available in the browser, complementary to the ritual ASCII dashboard.

What it does. A light wrapper over the aiad-sdd dashboard CLI: generates a static multi-page site in dashboard/ (overview, intents, specs, traceability, metrics, governance, drifts, changelog) + data.json. Options: --out, --serve (+ --port), --source-base to prefix the links to the sources (GitHub Pages).

Output. dashboard/ folder regenerated on demand.

/aiad emit-rules — multi-runtime

When. After any modification of .aiad/AGENT-GUIDE.md or .aiad/gouvernance/, to realign all the AI runtimes.

What it does. AIAD positions itself as the upstream source: instead of maintaining N diverging copies, the command regenerates all the targets from the AGENT-GUIDE and the governance — AGENTS.md (cross-tool standard, Copilot), the CLAUDE.md header (Claude Code), .cursor/rules/*.mdc (Cursor, including Tier 1 rules scoped by globs), .codex/AGENT.md (Codex), GEMINI.md (Gemini) and, since aiad-sdd 1.19.0, the .kiro/steering/aiad*.md steering files (Kiro). Each emitted file carries a DO NOT EDIT header and a SHA-256 source-hash. Idempotent regeneration; targeting is possible via --runtime cursor,codex.

Output. Summary + created ↑ regenerated ✓ unchanged. In --check mode (CI), exit 1 on divergence — the aiad-emit-rules-check.yml workflow blocks any PR that modifies the AGENT-GUIDE without regenerating the targets, or that manually edits a derived file.

Deprecated flat aliases