sdd-compile

/sdd-compile — Execution Brief

The user may name a spec path and whether to run tests after the command. If the spec is not given, ask which one. Run the tests unless the user explicitly declines — the project has a test command if its manifest declares a test script or .memory-bank/techContext.md documents one.

Gather context first

Run git status --short and git log --oneline -10 (if this is a git repository) and use the results. Read the referenced spec, its plan — the .plan.md sibling, or for a completed iteration the archive entry its **Plan:** line names — AGENTS.md, and .memory-bank/activeContext.md. The scope and docs-sync checks operate on git diff <baseline>, where <baseline> is the plan's Baseline: line; if none is recorded, use the commit before the plan's first step commit (step IDs in commit messages) and say so.

Re-derive every verdict from the repository, not from the plan's checkboxes. Read the code and the tests before the plan's claims about them, and treat a ticked box as a claim to check. Delegate this brief to a subagent that receives only the file paths (no conversation history) whenever your tool supports it — mandatory if this session implemented the work: the context that produced a gap is the worst placed to find it. If delegation is impossible, say so in one line at the top of the brief and re-run every check yourself, trusting no note from your own session.

Expected state and verdict rubric

This check normally runs before the done/ move: the state it certifies is the spec In Progress in active/ with its plan Done beside it. That state is correct, never a finding — and the done/ move is never a readiness fix: the move follows READY (/sdd-lifecycle demands this brief first), so naming it under next steps as a way to become ready is circular. A spec already in done/ makes this a post-hoc audit — say so and read the plan from the archive.