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
/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
claude-code · codex

Implementation note

Executing every example is the anti-hallucination guarantee — docs written this way cannot describe an API that does not exist. Seed docs/STYLE.md with a page you already like.

Source: Geoffrey Huntley (Ralph technique)

More docs loops

Changelog generation from commits

/goalloopreponew

Turn the commit history since the last release tag into a human-readable, categorized CHANGELOG entry ready for the next version.

prompt
→ Claude
/goal CHANGELOG.md has a complete entry for the next release — read every commit since the last version tag, group changes into Added, Changed, Fixed, and Removed, write user-facing descriptions (not commit messages), link PR numbers, and flag anything that looks like a breaking change; stop after 5 turns
docslow risk

Close the gaps before you build

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

prompt
→ Claude
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.
docslow risk

Fix doc drift, ship a PR

/scheduleForward Futurenew

Compare every doc against the current code, fix what's stale, verify commands and links, and open a reviewable PR.

prompt
→ Claude
Whenever a documentation pass is needed, review the codebase in full and make sure all documentation reflects the current implementation. Update stale documentation, verify the changes, then open a pull request.
docslow risk