lazyspec

Use when carrying out the work a delivery document describes -- the build loop -- against its task breakdown and acceptance criteria.

Use as the entry point for any work, including reported bugs, defects, and unexpected behaviour. Reads the configured DAG and the user's position, then dispatches the right verb -- advancing within the current document automatically but stopping at type boundaries.

Use when moving a document to its next status along the type's lifecycle DAG, maintaining links and checking gates at the transition.

Use when drafting a document of a configured type collaboratively -- AI proposes a draft body, the human edits, iterate -- up to the type's authorship ceiling.

Use when adding a new custom document type to a lazyspec project. Interviews the user to co-author the type's methodology -- intent, authorship, lifecycle, gates, relations -- then writes its enriched template and `[[types]]` config via the config-write CLI. One type per run.

Use when running a criteria-based review (health check, security audit, accessibility review, pen test, bug bash, spec compliance). Creates an Audit document with findings and presents them to the user for triage.

Use when authoring a full document body of a configured type from context -- AI writes the complete body, then asks for review -- only permitted when the type's authorship ceiling is `generated`.

Use when critiquing a document against its intent and acceptance criteria, or reviewing completed work, before advancing status.

Use when creating a new document of a configured type at the most manual authorship level -- AI creates the file and frontmatter, surfaces intent and section guidance, then hands the body back to the human.

Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes

Use when a Plan has a task breakdown and is ready for implementation. Dispatches subagent per task with review between tasks.

Use when running a criteria-based review (health check, security audit, accessibility review, pen test, bug bash, spec compliance). Creates an Audit document with findings and presents them to the user for triage.

Use when planning implementation against a Spec or as a standalone plan for bug fixes, tweaks, and refactors. Creates Plan documents with task breakdown and test plan. Supports parallel subagent dispatch for Specs with multiple contract groups.

Use when locking down technical contracts for a vertical slice. Creates Spec documents with data models, API surface, validation rules, error handling, edge cases, and optional acceptance criteria. Specs can be standalone or linked to an RFC. Supports parallel subagent dispatch for RFCs with multiple slices.

Use when starting new work, planning a feature, or deciding what to implement next. Detects existing RFCs, Specs, and Plans to determine the right starting point. Supports lightweight paths for bug fixes and small tweaks.

Use when an agent needs full context before beginning work on a Spec or Plan. Gathers the document chain from plan through spec to RFC.

Use when a Plan is complete and ready for review. Two-stage review -- spec contract compliance first, code quality second. Block on contract failure before reviewing code.

Use for heavy, cross-cutting, or architecturally significant designs. Creates an RFC document with intent, interface sketches, and identifies the Specs that fall out of it. Most features skip RFCs and go straight to Spec.