Fix branch-caused RSpec failures by selecting the affected spec set, repairing real failures, and committing each major repair round.
UTILITY SKILL. INVOKES: repo-specific RSpec runners such as Croft's RAILS_ENV=test bin/rails run specs, bundle exec rspec, git status/diff, write-commit-name, optional enable-remote-publication.
Use for end-to-end RSpec repair on the current branch. Default base is main; do not run the full suite unless the branch blast radius requires it.
Read spec repair workflow before running specs or editing code. Read publication safety before committing or pushing.
DO NOT USE FOR:
- Non-RSpec projects or product test failures outside the current branch.
- CI monitoring or GitHub Actions repair after a PR already exists.
- General code review, branch splitting, or broad correctness review.
- Requests to only run tests, report status, or execute a single command.
Workflow
- Inspect
git status -sb, the branch diff againstmain, and changed files. - Build a concrete affected spec list from changed files and nearby dependencies.
- In Croft, run affected specs with
RAILS_ENV=test bin/rails run specsso they use the repo's parallel runner against test databases. In generic Rails repos, runbundle exec rspecwith explicit spec paths or line numbers. - Fix real branch-caused failures, iterating on the narrowest failing subset.
- Rerun the full affected spec set; widen only when failures prove broader impact.
- Commit each major repair round intentionally and push only when publication safety says the target is verified.
- Stop when affected specs are green, the branch must be split, or an environment blocker remains.
Output
Summarize review base, affected specs, widened scope, repair commits, and final green commands. Use inline code paths.
Examples
fix all specsmake the failing RSpec tests pass for this branch
Troubleshooting
If specs cannot run because setup, dependencies, or database state is broken, stop and report the environment blocker. If branch scope is too mixed, use split-branch-into-stack.