Menu
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`.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
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 | generate |
| description | 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`. |
WRITE THE WHOLE BODY, THEN ASK FOR REVIEW
--json. Read parent/relation/gate facts from the CLI, never from .lazyspec/ graph files directly. On failure, check --help before retrying.
The authorship order is scaffold < co-write < generate. A type's authorship value in config is the ceiling.
Generate is the top rung. It is permitted only when the type's authorship is generated.
Refuse for human and assisted types. This is the headline ceiling-refusal case. Read the ceiling from lazyspec config --json and report it together with the permitted verb. The refusal text reads the ceiling string out of config; there is no baked type-to-ceiling table:
Type
<type>ceiling = co-write; drop to /co-write.
or, for a human-authored type:
Type
<type>ceiling = scaffold; drop to /scaffold.
where <type> and the ceiling are the actual values read from config for that run. Map ceiling to verb by the order itself: human -> scaffold, assisted -> co-write, generated -> generate.
lazyspec config --json -- read the target <type>: its intent, its authorship ceiling (gate the verb on this), section guidance, parent_type, and relation names.lazyspec context --json -- assemble source material: parent docs, related docs, and referenced code. Expand @ref directives and pull referenced code with lazyspec show -e <id>.lazyspec create <type> "<title>" --author <name>, then lazyspec link <new-id> <relation> <parent-id> with the configured relation when a parent exists.@ref targets, and the codebase, not on the human. So capture lightly -- resolve every decision you can from gathered context yourself, then surface ONLY the decisions the context cannot settle. Ask those as a short batch (one at a time, each with your recommended answer); skip the question entirely when the context already answers it. This is a lighter touch than /co-write's full interview -- you are filling gaps, not eliciting the whole design.intent and section guidance. Write to a file.lazyspec update <id> --body "content".When interviewing, grill me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.
Ask the questions one at a time.
If a question can be answered by exploring the codebase, explore the codebase instead.