review
Use when critiquing a document against its intent and acceptance criteria, or reviewing completed work, before advancing status.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Use when critiquing a document against its intent and acceptance criteria, or reviewing completed work, before advancing status.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
| name | review |
| description | Use when critiquing a document against its intent and acceptance criteria, or reviewing completed work, before advancing status. |
CONFORMANCE FIRST, QUALITY SECOND
Do NOT review quality before conformance. The document's acceptance criteria and declared intent come first; block on any conformance failure before looking at quality.
Do NOT approve without fresh verification evidence gathered in this session.
- Do NOT write document files directly. Use `lazyspec create` and `lazyspec link`.
- Do NOT edit a document you haven't read. Always `lazyspec show --json` or `Read` first.
- Do NOT skip the workflow pipeline. Respect the configured `parent_type` chain and `rules`.
Documents stored in GitHub Issues (store = "github-issues") are managed through the GitHub API. The `.lazyspec/cache/` directory contains read-only mirrors.
- Never edit files under `.lazyspec/cache/`. Use `lazyspec update --body` to modify content.
- Always use shorthand IDs (e.g. STORY-095) not cache file paths when referencing documents in `lazyspec link`, `lazyspec update`, `lazyspec show`, etc.
- To set body content at creation: `lazyspec create --body "content"`.
- To modify after creation: `lazyspec update <ID> --body "new content"`.
</GITHUB-ISSUES-DOCUMENTS>
Always run lazyspec help <subcommand> before using unfamiliar commands. Always pass --json. Read type/lifecycle facts from the CLI, never from .lazyspec/ graph files directly. On failure, check --help before retrying.
lazyspec config --json -- read the type's intent (the bar to critique against) and its lifecycle (to know which status review precedes, so the pass-route to /advance targets the right edge).lazyspec show <id> --json -- read the document and its acceptance criteria.lazyspec context --json -- read the chain (parent intent and ACs) so conformance is judged against the right spec.Two-stage critique:
Stage 1 -- Conformance. Does the document satisfy its declared intent and its acceptance criteria? For work being reviewed, verify each acceptance criterion with fresh evidence run in this session. Block on any conformance failure.
Stage 2 -- Quality. Only after conformance passes: critique quality -- clarity, correctness, cohesion, and (for work) test quality. Flag unjustified tradeoffs.
Express targets generically: "the document's acceptance criteria", "its declared intent". No type name is baked in.
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.