agentleFS
Sign inStart free
SupabaseKnown publishersupabase/cli/.agents/skills/test-audit/SKILL.md

test-audit

Skill2.4k starsChanged 20 days agoMITView on GitHub

Load whenever a test is authored, changed, or reviewed. Gates new tests before they are added and audits existing suites for low-value, duplicated, or implementation-coupled coverage across the unit/integration/e2e/live tiers.

We split this skill into the rules it gives an agent

3 rules. 0 are common, 3 are distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 64 edited versions we read keep these.

  • 3

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Before adding any test, answer all four questions.

    line 18
  2. Distinctive:

    test names that promise more than the test exercises

    line 49
  3. Distinctive:

    Always keep the test that gives a public CLI behavior, config, persistence, security, platform, or published package contract its distinct …

    line 55

“Common” is measured: kept by at least 6 in 10 of the 64 edited versions of this file we could read. “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

Test Audit

Two modes share one value bar. Authoring gates every new or changed test at write time. Audit sweeps existing tests, read-only until each candidate has recorded evidence. Both apply the junk patterns and retention bar below. See Test quality for tiers, naming, and flake-resistance rules this skill assumes.

Authoring gate

Before adding any test, answer all four questions. A missing answer means don't add it yet. Apply the same questions to review suggestions that add tests or assertions, and push back when they protect nothing:

  1. What behavior does it protect?
  2. What credible regression makes it fail?
  3. Why doesn't existing coverage already catch that failure?
  4. Does it need a test-only production seam that only exposes internals (an export, flag, or wrapper)? If so, move the test to the real boundary. A controlled clock, or a budget or config value production also reads, is fine.

Level rule

Each contract gets one primary test at the strongest boundary that can reach it: unit for pure logic, integration for handlers and Effect layers, e2e for the subprocess boundary through runSupabase(), live only when the command must reach the real platform or data plane. A second level needs a distinct risk the first can't reach, not the same contract replayed. Command e2e stays at one to three golden paths. Prefer a new row in an existing table-driven case over a near-duplicate test.

Junk patterns

Reject a new test, or flag an existing one, that matches any of these:

  • the same contract replayed at several tiers (unit, integration, e2e, live all asserting the same branch)
  • mocks or Effect test layers that implement the behavior being asserted, rather than standing in for a real collaborator
  • expected values produced by the helper under test instead of an independent source
  • negative controls that pass for an unrelated reason, such as a different guard rejecting input before the path under test ever runs
  • test names that promise more than the test exercises
  • real-time waits on production timeouts or backoff, such as an it.live case sleeping through a retry schedule; use a controlled clock or an injected budget instead

Retention bar

Always keep the test that gives a public CLI behavior, config, persistence, security, platform, or published package contract its distinct proof. Being slow or static is never a reason to delete it; a copy at another tier asserting the same thing can still be consolidated.

Regression tests

A bug-fix test must be shown to fail on the pre-fix code for the intended reason, then pass after the fix. A regression test that never demonstrably failed proves the mock, not the fix.

Audit mode

Discovery stays read-only: no edits until every candidate has recorded evidence. Before touching anything, record for each candidate:

  • what the test can actually detect
  • the stronger proof that remains, or would remain, without it
  • any test-only production seam its deletion would free

Then mark it in a short ledger, one evidence line per mark:

  • R retain — names the contract and the regression it catches
  • F fix — keep the contract, repair a weak or vacuous assertion
  • C consolidate — names the owner absorbing it (a sibling table row, a stronger boundary suite)
  • D delete — names the proof that remains, or that no contract exists

Report the ledger in the audit response, or in the campaign's tracking issue when there is one, never in a PR description. Prefer a few high-confidence candidates over a large speculative sweep.

Download now (ZIP)

Trending

Quiet since September.about the whole repository

Dec 2025: 0 mentionsJan 2026: 1 mentionFeb 2026: 0 mentionsMar 2026: 4 mentionsApr 2026: 2 mentionsMay 2026: 1 mentionJun 2026: 1 mentionJul 2026: 2 mentionsAug 2026: 0 mentionsSep 2026: 14 mentionsOct 2026: 0 mentionsNov 2026: 0 mentions
Dec 2025Jun 2026Nov 2026
Mentions a month of the supabase/cli repository that our weekly crawl found. There is no adoption data for this file yet.

Who's talking about supabase/cli

The biggest 5 of 41 mentions linking to the repository that our crawl found. Each line is their own headline.

See all 41

Talked about on GitHub, Stack Overflow and Bluesky (41 times).

On GitHub · 32

27 more on GitHub
  • Other versions67 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 67

    1. moltbot/moltbot★ 393ksame name
    2. clawdbot/clawdbot★ 393ksame name
    3. steipete/warelay★ 392ksame name
    4. moltbot/clawdbot★ 392ksame name
    5. steipete/clawdis★ 392ksame name
    6. molt-bot/clawdbot★ 391ksame name
    7. openclaw/openclaw★ 391ksame name
    8. garrytan/gstack★ 138ksame name
    9. paperclipai/paperclip★ 107ksame name
    10. simstudioai/sim★ 30ksame name

    57 more not listed

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • Used alongsideProjects with it also use how, cleanup and 10 more.

    Other files people use alongside this one.

    Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
    • jaydubya818Skill

      how

      Use for runtime, ownership, layering, code-walkthrough, and placement questions.

      Also in 4 projects that use this

    • MicrosoftSkill

      cleanup

      Also in 3 projects that use this

    • AnthropicSkill

      eli5

      Explain a topic like I'm a 5 year old. Use when the user types /eli5 <topic> or asks for a dead-simple picture explainer of how something works.

      Also in 3 projects that use this

    • dragonflydbSkill

      benchmark

      Benchmark Dragonfly (and compare against Valkey/Redis) on local or remote cloud instances, then produce a performance + memory report with charts and a raw-data appendix. Use this whenever the user runs /benchmark, or asks to benchmark / load-test / measure throughput, QPS, latency, or memory efficiency of Dragonfly or another Redis-compatible server, to compare Dragonfly vs Valkey or Redis, or to generate a benchmark report. Trigger it even when the user just describes the goal ("see how fast Dragonfly is on this box", "compare memory per key vs Valkey") without saying the word "benchmark".

      Also in 3 projects that use this

    • SentrySkill

      deslop

      Strip AI-generated noise from the diff before pushing — extra comments a human wouldn't write, defensive try/catch in trusted code paths, casts to any, inline imports in Python, and other style inconsistencies with the surrounding file. Use this immediately before commit so the diff stays clean.

      Also in 3 projects that use this

    • SentrySkill

      review

      Fixture review skill.

      Also in 6 projects that use this

  • In this repository5 other files it gives its agents.

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.

Check your setup, free