agentleFS
mickzijdelmickzijdel/rails-toolkit/skills/rails-clean-test-output/SKILL.md

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.

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
  1. Distinctive:

    Before anything else, determine which framework the repo uses, and say which you detected:

    line 19
  2. Very specific:

    RSpec: if the Gemfile/Gemfile.lock includes rspec-rails and there is a spec/ directory.

    line 21
  3. Distinctive:

    If both are present, ask the user which suite they want cleaned.

    line 24
  4. Very specific:

    Read and follow ../../vendor/clean-rspec-output/SKILL.md end to end — its fix-scope rules (change *how* a test runs, never *what* it …

    line 28
  5. Very specific:

    Use bin/rails test (or bundle exec rails test) rather than rake so the right environment loads.

    line 57

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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:

  1. 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.
  2. Logging p/puts calls 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.lock includes rspec-rails and there is a spec/ directory.
  • Minitest otherwise (a test/ directory with minitest, 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.

PurposeRSpecMinitest
Capture full runbundle exec rspec 2>&1 | tee tmp/rspec-output.logbin/rails test 2>&1 | tee tmp/test-output.log
Locate the source testbundle exec rspec --format documentation 2>&1 | tee tmp/rspec-output-doc.logbin/rails test -v 2>&1 | tee tmp/test-output-doc.log
Reproduce / verify in isolationbundle exec rspec spec/path_spec.rb:LINEbin/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/system and run the same way (bin/rails test:system for the whole system suite).
  • Use bin/rails test (or bundle exec rails test) rather than rake so the right environment loads. The plain log is still the only log you scan for issues; the -v log 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 var with no semantic message, left over from troubleshooting → delete it (same as upstream).
  • Operational / progress message — a p/puts that reports what the code is doing (progress, a recoverable problem, a failure) → replace it with a severity-appropriate Rails.logger call, 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.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.