Apply Elon Musk's Five-Step Algorithm to any requirement or plan before building. Use in the intake/plan stages to question, delete, simplify, accelerate, and automate — in that order. Prevents the expensive mistake of optimizing or automating something that should have been deleted.
Greenfield-only intake gate. Apply founder/startup best-practice (from the Founder's Playbook) before any PRD on a NEW project — who is the user, the smallest valuable slice, the riskiest assumption, the build-measure-learn loop. Skip for existing projects.
Entropy garbage-collection. Periodically scan for drift — stale docs, dead "always-loaded" context, smells, mismatched conventions — and open small targeted fixes. Use to keep the smart zone smart and the repo coherent for future agent runs. Runs orthogonally to the main lifecycle.
Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".
This project runs on harness-mini. For non-trivial work — a feature, a multi-step or ambiguous change, anything cross-cutting — route it through the stage-viewer skill first and prefer harness-mini's lifecycle, skills, and sub-agents (read .claude/skills/ /SKILL.md) over ad-hoc tools or other installed plugins. When a…
Fan out the horizontal expansion of the implement stage to parallel generators. Use AFTER the vertical walking skeleton passes evaluate, to build independent features concurrently. The main agent dispatches one generator per issue; parallelism is gated on disjoint file footprints. Vertically related, horizontally…
Drive a long-running "work → check → repeat" loop until an exit condition is met, max iterations hit, or a human-judgment flag is raised. Use for autonomous long tasks where an agent does work and an evaluator decides whether it passes (e.g. "keep fixing until all reviewers pass"). Backed by bin/ralph.sh.
The recovery code-quality constraint (Refactoring). Use to improve code structure without changing behavior — smell → named refactoring, always under green tests, one move at a time. Used by the generator (in the tdd refactor step) and the gardener (entropy cleanup).
Cut a versioned release of harness-mini — bump VERSION, roll the CHANGELOG, tag, and publish a GitHub release. Use when shipping a new version. Wraps bin/harness.sh release; covers the human-judgment steps (semver choice, changelog curation) the script can't make.
The horizontal+vertical coding constraint. Use in the implement stage to decide build order and enforce layering. Vertical = one feature end-to-end as a thin walking skeleton first; Horizontal = forward-only dependencies through a fixed layer stack. Read before writing code.
View and advance the lifecycle stage of every requirement. Main-agent only — the single authority that moves a plan through intake→prd→issues→implement⇄evaluate→checkpoint→done. Use to see what stage work is in, route simple vs complex requests, and promote a plan (no sub-agent may self-promote).
Implement code test-first via the red→green→refactor loop. Use in the implement stage for every issue. Never write implementation before a failing test; never refactor on red. The generator's core working rhythm.
Decompose a PRD into atomic, testable issues — the executable work units the generator implements one at a time. Use in the issues stage. Each issue is independently verifiable and maps to one vertical slice or a step within one.
Turn a raw idea or requirement into an executable PRD document — a versioned artifact the harness treats as a first-class source of truth. Use in the prd stage after founder-check/five-step. Output is agent-readable, testable, and committed.