Build ready

build-ready

Red-team a spec from a cold builder's seat. You simulate a fresh AI builder agent with zero prior context that must implement the spec end-to-end with no human to ask. Every point where that builder would have to stop-and-ask or stop-and-guess is a finding. Then — inverting the usual "ask the human" move — you propose a concrete default for each gap so the spec becomes buildable without an interview.

This is not a checklist (checklists test what's present and miss what's structurally absent). It is a simulated cold build that surfaces the unknown-unknowns which only appear when you actually try to build.

When to use

Trigger on natural-language requests like: "is my plan ready to build", "can an agent build this", "what's missing before I hand this to a builder", "build-readiness check", "red-team my spec". Works standalone; complementary to (never dependent on) Spec-Kit.

Workflow

Follow these steps in order. Steps 1–4 are read-only; never edit the spec before the report is shown. Step 5 edits only after explicit approval.

1. Locate the spec

If the user gave a path, use it. Otherwise look in the working directory for, in order: PLAN.md, SPEC.md, PRD.md, DESIGN.md, README.md. If several exist or the choice is ambiguous, list what you found and confirm which one to score before continuing.

2. Cold-read traversal

Read the file once, top to bottom, role-playing a zero-context builder. Use no outside knowledge of this project — not the repo, not the git history, not this conversation, not what you can guess the author "probably meant." The only inputs a real disposable builder session gets are the spec text and general world knowledge (languages, frameworks, common conventions). At every point where you would have to stop-and-ask a human or stop-and-guess to keep building, log it.

The full traversal method, the categories of gap to watch for, and worked examples are in references/traversal.md. Read that file now before classifying.

3. Classify & score

Assign every finding one type:

• Blocker — a cold builder literally cannot proceed. Any single blocker caps the verdict at NOT READY.
• Forced assumption — builder must guess, and different reasonable guesses yield materially different products. These are the dangerous ones.
• Ambiguity — underspecified but low-risk; guesses converge on similar results.
• Placeholder — literal TBD / TODO / FIXME / ??? / {{…}} / "(fill in)". Any placeholder is a hard fail → NOT READY.

Apply the score rubric in references/report-format.md.

4. Report

Output the verdict (READY / NOT READY) + score, then a findings table ranked most-severe-first, using the exact format in references/report-format.md. Findings must be concrete and spec-specific ("no data store named, so a builder can't choose between Postgres and in-memory and the two produce different deploy artifacts") — never generic advice like "add more detail." Always show this report before any edit.

5. Defaulting pass (opt-in)

After the report, offer to patch the spec. Do not proceed without approval. On approval, for each blocker and forced assumption propose a concrete, reasonable default decision, then Edit the spec to append a "Build Assumptions & Resolved Decisions" section capturing those decisions — preserving the spec's existing structure, headings, and voice. Do not rewrite the rest of the document. The spec-patch format is in references/report-format.md.

Portability

This skill uses only universal agent capabilities: read a file, reason, and (on opt-in) edit a file. It references no Claude-Code-only tooling, so the same SKILL.md runs in opencode and other skill-aware agents. Perform each step with whatever file-read / file-edit primitive the host agent provides.