Help us improve
Share bugs, ideas, or general feedback.
From RGR
Enforces strict Red-Green-Refactor cycles with recorded proof of test failure before implementation, protected red tests, and replay verification.
npx claudepluginhub kingbootoshi/rgr --plugin rgrHow this skill is triggered — by the user, by Claude, or both
Slash command
/rgr:rgrThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Goal: ship code changes through strict Red-Green-Refactor proof.
Enforces test-driven development with a strict red-green-refactor cycle. Use when building new features to ensure test coverage and correct design from the start.
Enforces RED-GREEN-REFACTOR TDD cycle: write a failing test first, then minimal code to pass, then refactor. Use when implementing features or fixing bugs during the implement phase.
Share bugs, ideas, or general feedback.
Goal: ship code changes through strict Red-Green-Refactor proof.
Success means:
rgr green.Stop when every active RGR cycle has Green, rgr verify --ci --replay -- bun test passes, and the final response reports the proof.
Use this order in Claude Code and Codex:
rgr --help. Claude Code installs this plugin's bin/rgr wrapper onto PATH, so this should work when the plugin is enabled.bun run ./src/cli/index.ts --help.RGR_CLI, run bun run "$RGR_CLI" --help.If none of those works, stop and ask the user to install or link RGR before making production changes. Do not simulate RGR receipts by hand.
Use rgr in the examples below. Replace it with bun run ./src/cli/index.ts or bun run "$RGR_CLI" only when needed.
Capture Red:
rgr --root "$REPO" red --strict --goal-id "<goal-id>" --test "<test-file>" -- bun test "<test-file>"
Protect a helper, fixture, snapshot, or config file that defines the Red oracle:
rgr --root "$REPO" red --strict --goal-id "<goal-id>" --test "<test-file>" --protect "<support-file>" -- bun test "<test-file>"
Prove Green:
rgr --root "$REPO" green
Inspect test quality:
rgr --root "$REPO" inspect-test --json
Validate refactor:
rgr --root "$REPO" refactor -- bun test
Run the final gate:
rgr --root "$REPO" verify --ci --replay -- bun test
If an older completed cycle has known replay-only environment noise, use targeted replay as an exception path instead of skipping verification entirely. Report the replay selector and skipped active cycles in the handoff.
rgr --root "$REPO" verify --ci --replay --cycle latest -- bun test
rgr --root "$REPO" verify --ci --replay --from-cycle "<cycle-id>" -- bun test
rgr red --strict with the focused test file.rgr green to prove the exact Red command now passes.rgr inspect-test --json; revise weak or wrong tests through rgr revise-test.rgr refactor -- bun test after Green for broader validation.rgr verify --ci --replay -- bun test before handoff.Use --test only for root assertion-bearing tests. Use --protect for support files that change what the Red test means. Do not pass helpers or fixtures as --test.
Choose tests that exercise the public contract callers rely on. Assert a concrete payload, state change, side effect, permission boundary, persistence result, error boundary, or emitted event.
Include tenant, auth, permission, time, ordering, persistence, concurrency, and rollback constraints when those define correctness.
Use mocks at external seams only. Keep assertions pointed at behavior the production caller observes: returned payloads, state transitions, side effects, emitted events, and errors.
Prefer one focused Red for the next behavior step. Add broader integration or e2e coverage when the risk crosses service boundaries, storage, auth, routing, or user workflow.
When Red passes, strengthen the test until it proves missing behavior and fails cleanly.
When Red fails from setup noise, repair the test setup and rerun Red before production edits.
Use --allow-source-changes only for reviewed source dirtiness that existed before Red starts. RGR snapshots that dirty source for replay. If the Red command creates commits or modifies source files, stop and fix the workflow before recapturing Red.
When the test is wrong, run:
rgr --root "$REPO" revise-test --reason "<why the old Red was wrong>"
Then capture a new Red proof.
When a protected file changes during Green, restore your own accidental edit or supersede the cycle through revise-test and recapture Red.
When a same-file multi-cycle change extends a test file after Green, checkpoint the prior Green state before capturing the next Red so CI replay has a stable base.