analyze

name	analyze
description	Check for drift between spec.md, plan.md, tasks.md, and the actual code. Reports the gaps; does not fix them.
metadata	{"aiadev":{"version":"0.2.0","inputs":[{"type":"dir","path":"specs/<branch>/"}],"outputs":[{"type":"text","description":"A gap report. Optionally written to specs/<branch>/analysis.md."}],"requires":["constitution"],"handoffs":["plan","tasks","clarify"]}}

Analyze

Compare what the spec said, what the plan scheduled, what the tasks listed, and what the code actually did. Return a report of the drift.

Announce at start: "Using the analyze skill. I will report gaps; fixes are a separate pass."

When to use

Run pre-flight first: aiadev preflight analyze --feature <slug>. Abort on non-zero exit unless AIADEV_PREFLIGHT=warn is set.

• Before opening the PR — sanity check that implementation matches spec.
• Mid-implementation, when something "feels off" — usually a missing task or a spec the plan ignored.
• After a long break — quickly regain context on a branch.

Loop

1. Collect. Read spec.md, plan.md, tasks.md, and the diff of the branch vs its base.
2. Map acceptance scenarios → tasks → commits. Build a small table.
3. Report four gap classes:
   • Spec without plan coverage — an acceptance scenario that no plan phase addresses.
   • Plan without task coverage — a plan entry with no corresponding task.
   • Task without code — a task marked done whose files are missing or unchanged in the diff.
   • Code without task — files changed in the branch that no task asked for.
4. Check the Constitution. Article by article, does the current state still pass? Flag any that silently slipped to FAIL.
5. Report. Short, structured. Each gap has a file:line or commit hash and a suggested skill to invoke next.

Rules

• Do not fix anything. Analysis and remediation are separate passes; mixing them hides the drift.
• Do not open issues or edit skill files — drop your report in specs/<branch>/analysis.md (optional) or straight to the user.
• No silent "looks fine". If there is truly no drift, say so explicitly.

Graph provider (optional)

When a knowledge-graph context provider is configured (the optional knowledge-graph preset declares it in mcps.yaml, spec 0017), ground the gap classes in facts from the provider instead of inference alone. Follow rules/graph-facts.md for how to cite and label every fact.

• Task without code (provider-grounded). Query the provider's drift operation; for each fact in missing, report the gap citing the expected-and-absent path:symbol.
• Code without task (provider-grounded). For each fact in extra, list the changed file with the graph edge to its subsystem, so the drift reads as "this file belongs to subsystem X but no task asked for it".
• Confidence. Cite every fact with its confidence label per rules/graph-facts.md — one of explicit, inferred, or ambiguous. A fact labelled inferred or ambiguous is a signal to verify, and is not a definitive gap; only explicit facts back a definitive statement.

Graceful degradation. The provider is optional. When no provider is configured, produce the exact same report as the inference-only Loop above (the four gap classes) and never emit an error because a provider is absent. A provider that is configured but unavailable at runtime (timeout/error) is treated the same way: omit the provider-grounded contribution with a short note and keep the base report.

Hand-off

Suggest the skill most likely to close each gap:

• Spec gap → clarify or specify (for the missing scenario).
• Plan gap → plan.
• Task gap → tasks.
• Code drift → a new task plus implement.
• Constitution drift → open an amendment PR per constitution.md's amendment process.