rails-clean-test-output
Skill2 starsChanged 8 days agoMITView on GitHub
Use when a Rails test suite (RSpec or Minitest) prints anything besides results, such as warnings, deprecations, stray puts/p/pp or leaked log lines, and the user wants it cleaned up, silenced or explained.
In this repository24 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- rails-activestorageSkill
- rails-apiSkill
- rails-auditSkill
- rails-controllersSkill
- rails-coreSkill
- rails-database-performanceSkill
- rails-i18nSkill
- rails-jobsSkill
- rails-loggingSkill
- rails-mailersSkill
- rails-migrationsSkill
- rails-modelsSkill
- rails-multi-tenancySkill
- rails-performanceSkill
- rails-philosophySkill
- rails-project-setupSkill
- rails-securitySkill
- rails-stimulusSkill
- rails-styleSkill
- rails-testingSkill
- rails-turboSkill
- rails-upgradeSkill
- rails-viewcomponentsSkill
The file
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 2 are distinctive, and 3 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 19
Before anything else, determine which framework the repo uses, and say which you detected:
- Very specific: line 21
RSpec: if the Gemfile/Gemfile.lock includes rspec-rails and there is a spec/ directory.
- Distinctive: line 24
If both are present, ask the user which suite they want cleaned.
- Very specific: line 28
Read and follow ../../vendor/clean-rspec-output/SKILL.md end to end — its fix-scope rules (change *how* a test runs, never *what* it …
- Very specific: line 57
Use bin/rails test (or bundle exec rails test) rather than rake so the right environment loads.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Clean Up Unexpected Rails Test Output
This skill wraps thoughtbot's clean-rspec-output,
vendored in this plugin at ../../vendor/clean-rspec-output/. That skill is the authoritative,
detailed per-issue workflow (capture → scan → isolate → fix → verify → simplify → commit). This
wrapper adds two things on top:
- It is framework-agnostic. The vendored workflow is written for RSpec, but the same approach works for Minitest. Detect which the project uses and translate the commands.
- Logging
p/putscalls become logger calls, not deletions. See Override B below.
Step 0 — Detect the test framework
Before anything else, determine which framework the repo uses, and say which you detected:
- RSpec if the
Gemfile/Gemfile.lockincludesrspec-railsand there is aspec/directory. - Minitest otherwise (a
test/directory withminitest, the Rails default).
If both are present, ask the user which suite they want cleaned.
The workflow
Read and follow ../../vendor/clean-rspec-output/SKILL.md end to end — its fix-scope rules
(change how a test runs, never what it covers), its hard gate on reproducing each issue in
isolation before fixing, its one-fix-per-commit discipline, and its commit-message format all
apply unchanged. The two overrides below take precedence wherever they conflict with it.
One reading note: where the vendored loop warns against "thinking ahead about the fix while still locating the source test", read it as a rule about acting — don't edit code until the issue reproduces in one scoped command. Forming a hypothesis early is fine; applying it early is not.
Override A — Minitest command map
The vendored workflow hardcodes bundle exec rspec commands. When the project uses Minitest,
substitute the equivalents below. Everything else (the verification loop, the anchored Grep
patterns for locating stray output, the isolation gate) carries over identically.
| Purpose | RSpec | Minitest |
| Capture full run | bundle exec rspec 2>&1 | tee tmp/rspec-output.log | bin/rails test 2>&1 | tee tmp/test-output.log |
| Locate the source test | bundle exec rspec --format documentation 2>&1 | tee tmp/rspec-output-doc.log | bin/rails test -v 2>&1 | tee tmp/test-output-doc.log |
| Reproduce / verify in isolation | bundle exec rspec spec/path_spec.rb:LINE | bin/rails test test/path_test.rb:LINE |
Notes for Minitest:
- Minitest has no separate documentation format;
-v(verbose) prints each test name inline and plays the role of the documentation log — stray output appears between the named test lines, so the "locate the test immediately preceding the stray output" technique still works. - System/integration tests live under
test/systemand run the same way (bin/rails test:systemfor the whole system suite). - Use
bin/rails test(orbundle exec rails test) rather thanrakeso the right environment loads. The plain log is still the only log you scan for issues; the-vlog is only for locating the test that produced an already-identified issue.
Override B — logging p/puts become Rails.logger calls, not deletions
The vendored workflow's default for a stray p/puts/pp is to delete it. Keep that for
genuine debug leftovers, but do not blanket-delete output that is actually conveying
operational information. Decide per call:
- Leftover debug artifact — a bare
p value/pp obj/puts varwith no semantic message, left over from troubleshooting → delete it (same as upstream). - Operational / progress message — a
p/putsthat reports what the code is doing (progress, a recoverable problem, a failure) → replace it with a severity-appropriateRails.loggercall, so the message routes through the configured log level instead of dumping to stdout (which is what makes it noisy in test output).
Pick the level from the message's severity rather than applying one blanket replacement:
Rails.logger.info— normal progress ("Sending Test Email…","Converting #{show_title}…","Adding Team Members")Rails.logger.warn— recoverable problems ("WARNING: Could not save…","…cannot be converted to a show")Rails.logger.error— actual failures
Where several adjacent p lines form one logical message, collapse them into a single
Rails.logger.info call. This is an application-code (or rake-task / service) fix, not a test
fix — it belongs in the code that emits the output, leaving assertions untouched.
For the separate case where a test needs to assert on logged output, keep the vendored advice:
refactor to expect(Rails.logger).to receive(...) (RSpec) or
assert_*/a stubbed logger (Minitest) instead of letting output leak.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

