--- description: Generate or refine the technical execution…
Community ralph loop for testing, sourced from github. Verified exit condition, evaluator-gated.
--- description: Generate or refine the technical execution plan (ordered steps) for an existing spec. argument-hint: "<slug>" allowed-tools: [Agent, Read, Glob, Grep, Skill] --- # /plan — Build/refine the execution plan for a spec Spec slug: $ARGUMENTS Use this when a spec.md exists (from /spec ) but the plan.md is missing, incomplete, or needs revision after spec changes. ## Steps 1. Read .claude/specs/$ARGUMENTS/spec.md . If it's missing, tell the user to run /spec first and stop. 2. If more codebase context is needed for sound step decomposition, run codebase-explorer for the specific areas. 3. Invoke the solution-architect agent to (re)write .claude/specs/$ARGUMENTS/plan.md per the spec-driven skill: architecture decisions + ordered, atomic, self-contained steps, each naming one expert agent, its FR/AC, dependencies, and the gating auditors (per the review-board skill). 4. Validate coverage: every FR and AC in the spec is satisfied by at least one step; step ordering respects dependencies (schema → backend → frontend; tests first for fixes; docs last). 5. Report the step list and any gaps. ## Hand-off End with: "Plan for $ARGUMENTS is ready. Ru
claude-code
More testing loops
Ship the release
Run tests and update changelog until both pass without altering the public API.
/goal ship the release --success "tests pass and changelog updated" --constraints "do not touch the public API" --mode ordered
testingmedium risk
/ralph-loop "fix all tests" --max-iterations 5 (iterates until…
Community ralph loop for testing, sourced from github. Verified exit condition, evaluator-gated.
/ralph-loop "fix all tests" --max-iterations 5 (iterates until passing
testingmedium risk
Trim what loads before first paint
Reduce the data downloaded before the first screen appears, with tests and screenshots guarding behavior and appearance.
Reduce the data [web app] downloads before its first screen appears. First record passing tests, mobile and desktop screenshots, and compressed transferred bytes—the data actually downloaded. Use the build report only to suggest candidates. Defer, compress, or remove one item, then rebuild and rerun every check. Keep it only if tests pass, screenshots are pixel-identical, and bytes decrease; otherwise revert. Stop when no safe candidate remains, progress stalls, or approval is needed. Return measurements, changes, and untested states.
testingmedium risk