build
Use when a Plan has a task breakdown and is ready for implementation. Dispatches subagent per task with review between tasks.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Use when a Plan has a task breakdown and is ready for implementation. Dispatches subagent per task with review between tasks.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
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.
| name | build |
| description | Use when a Plan has a task breakdown and is ready for implementation. Dispatches subagent per task with review between tasks. |
NO IMPLEMENTATION WITHOUT A PLAN
If the Plan doesn't have a numbered task breakdown in ## Changes, you can't build yet. Use the /create-plan skill first.
Do NOT begin implementation without a complete Plan document with numbered task breakdown. Each task must have enough detail for a zero-context subagent. ALWAYS use subagents for development. - Do NOT implement tasks yourself. Dispatch a subagent per task. Do NOT dispatch parallel implementers.[!IMPORTANT] Read
_common.mdin the skills directory for CLI usage, forbidden actions, and subagent tiers.
lazy -> write-rfc -> create-spec -> resolve-context -> create-plan -> build
build.style.fill: "#4A9EFF"
build.style.font-color: "#FFFFFF"
lazy.style.opacity: 0.4
write-rfc.style.opacity: 0.4
create-spec.style.opacity: 0.4
resolve-context.style.opacity: 0.4
create-lazy.style.opacity: 0.4
Read plan -> Extract all tasks -> Create task tracking
Per task {
Dispatch implementer subagent -> Questions? -> Answer, re-dispatch: yes
Questions? -> Implementer works + self-reviews: no
Implementer works + self-reviews -> Dispatch reviewer subagent
Dispatch reviewer subagent -> Contract compliance passes?
Contract compliance passes? -> Implementer fixes -> Dispatch reviewer subagent: no
Contract compliance passes? -> Code quality passes?: yes
Code quality passes? -> Implementer fixes quality -> Dispatch reviewer subagent: no
Code quality passes? -> Mark task complete: yes
}
Mark task complete -> More tasks?
More tasks?.shape: diamond
More tasks? -> Per task: yes
More tasks? -> Final full review: no
Final full review -> All Spec contracts met?
All Spec contracts met?.shape: diamond
All Spec contracts met? -> Done: yes
All Spec contracts met? -> Fix gaps: no
Done.shape: double_circle
lazyspec context <plan-id> --json to see the document chainlazyspec show <plan-id> --json to get the task breakdownlazyspec show <spec-id> --json to get the contractslazyspec show <rfc-id> --json for design intent## Changes before dispatching any subagent| Operation | Agent Type | Tier | Context to provide |
|---|---|---|---|
| Implement task | general-purpose | Heavy | Full task text, RFC intent, Spec contracts, prior task results |
| Review task (contract compliance) | general-purpose | Heavy | Task text, Spec contracts, implementer report |
| Review task (code quality) | general-purpose | Medium | Changed files, test output, quality criteria |
| Final review | general-purpose | Heavy | All Spec contracts, full implementation summary |
This skill follows the obra/superpowers subagent-driven development pattern: dispatch a fresh subagent per task, with two-stage review (spec compliance first, code quality second). Each subagent starts with zero prior context to prevent pollution. The reviewer is always a separate agent from the implementer.
lazyspec context <plan-id> --json to see the full document chain at a glance.lazyspec show <plan-id> --json and lazyspec show <spec-id> --json to get the full bodies (task breakdown, contracts). If an RFC exists in the chain, also run lazyspec show <rfc-id> --json for design intent.## Changes section. Copy the full text of each task -- subagents receive text, not file references.For each task in the plan:
Use the Agent tool with subagent_type: "general-purpose". Provide:
Read the prompt template from prompts/implementer.md (relative to this skill directory) and include it in the subagent prompt.
If the implementer asks questions, answer them. Provide additional context if needed. Don't rush them into implementation.
After the implementer reports back, dispatch a separate reviewer subagent using the Agent tool with subagent_type: "general-purpose".
Read the prompt template from prompts/reviewer.md (relative to this skill directory) and include it in the subagent prompt, filling in the placeholders with the actual task text, spec contracts, and implementer report.
If the reviewer reports issues:
Update task tracking. Proceed to next task.
After completing tasks 2, 4, 6, etc., re-read the chain to prevent context drift:
lazyspec context <plan-id> --json to verify the chain is intactlazyspec show <plan-id> --json to refresh the task list and statuslazyspec show <spec-id> --json to refresh the contractsBefore the final review, verify the workflow is intact:
lazyspec show <plan-id> --json## Changes have been completedlazyspec validate --json to check document integrityIf anything is out of alignment, fix it before proceeding to final review.
After all tasks complete, dispatch a reviewer subagent. Read the prompt template from prompts/final-reviewer.md and include it in the subagent prompt, filling in the spec contracts and task summary.
If final review passes, follow the status promotion steps in _common.md.
| Red Flag | Reality |
|---|---|
| "I'll review all tasks at the end" | Per-task review catches issues early. Fixing one task is cheaper than fixing five. |
| "The implementer self-reviewed, that's enough" | Self-review is necessary but not sufficient. The reviewer is a separate subagent. |
| "I'll skip contract compliance and just do code quality" | Contract compliance FIRST. Beautiful code that doesn't meet the spec is wrong code. |
| "Let me implement two tasks before reviewing" | One task, one review. No batching. |
| "I'll provide a file reference instead of the full text" | Subagents receive full text. File references require them to read and parse, wasting context. |
Before dispatching any implementer subagent:
Before claiming build is complete:
_common.mdlazyspec validate --json passes