Loop/loopDocslow riskintermediatesafety C · 55Forward Futurepre-dates current gate · under review

Close the gaps before you build

Fill documentation gaps until requirements, technical design, acceptance criteria, and test strategy describe one buildable system.

prompt
→ Claude Code
Prepare [project] for implementation. Ensure its documents cover requirements, technical design, tasks with acceptance criteria, and test strategy. Each round, fix the largest gap or contradiction that could make two competent engineers build different systems. Keep details traceable, record assumptions, and ask before product forks. Recheck consistency, then have two independent reviewers describe the components, data model, dependencies, and definition of done. Stop when they materially agree and every artifact is testable, or a decision needs the user.
claude-code · codex

Use this when

Use this before building a new software project when its idea or early documents still leave important implementation decisions open to interpretation.

How it runs

  1. Inventory the current project documents and identify the missing requirements, technical design, task breakdown, acceptance criteria, or test strategy needed before implementation.
  2. Find the single largest gap, contradiction, or vague requirement that could make competent engineers build different systems, then close it with concrete detail traceable to a stated requirement.
  3. Record assumptions that can be made safely, ask the user about genuine product forks, and recheck every edited document against the others for consistency.
  4. Have two independent reviewers describe the intended components, data model, dependencies, and definition of done; repeat until their descriptions materially agree or a required decision blocks progress.

Done when

✓ Two independent reviewers derive substantially the same build from the project documents. Their descriptions agree on the components, data model, dependencies, and definition of done, and every required artifact is specific, consistent, traceable, and testable.

Why it works

A concrete convergence test exposes ambiguity that a single author may read past. Fixing one divergence at a time keeps the documents coherent and turns project preparation into evidence that another engineer can follow rather than a pile of planning text.

Implementation note

Do not add detail merely to make the documents longer or invent product requirements to force agreement. Keep every claim tied to a stated requirement, record assumptions, and return unresolved product choices to the user.

Source: Forward Future ↗graded C · 55/100 — how grades work →

More docs loops

Set "remove every TODO comment in src/ and…

Loop/goalGitHubB

Community goal loop for docs, sourced from github. Verified exit condition, evaluator-gated.

prompt
→ Claude Code
/goal set "remove every TODO comment in src/ and explain each removal" stop after 8 turns

Cadence: weekly. you are my presale-question compiler. read…

Loop/loopXA

Community loop loop for docs, sourced from submission. Verified exit condition, evaluator-gated.

prompt
→ Claude Code
/loop cadence: weekly. you are my presale-question compiler. read presale-q-STATE.md: the question tally and the answer bank index. sweep the week's inbound [DM export / comments / presale emails] for questions from people who had not bought yet; tally them, the same question in different words counts as one. each round, take the single most-asked question without a bank entry and write a full FAQ answer plus a short paste-able DM snippet; answers get LINKED from then on, never retyped. if a new question contradicts an existing bank entry, flag it. append the tally and the new entry to presale-q-STATE.md; draft only, never publish the FAQ yourself. verification: a round is valid only when the new entry is appended and readable in presale-q-STATE.md. stop after 10 iterations, or until no question remains above [X] asks without an entry, whichever comes first; a contradiction escalates as BLOCK.

Ralph the docs backlog

Document one undocumented public module per fresh-context iteration, verifying every code sample compiles and accumulating style rules in guardrails so the docs read like one author wrote them.

prompt
→ Claude Code
/loop fresh context each iteration: read docs-backlog.json, docs/STYLE.md, and .ralph/guardrails.md; pick the top undocumented module, write its reference page with a runnable example, execute the example to prove it works, and mark the module done; add any style or structure decision to .ralph/guardrails.md; stop when the backlog is empty or after 20 turns