agentleFS
Sign inStart free
bighamxbighamx/openclaw-android-node-apk/.agents/skills/test-audit/SKILL.md

test-audit

Skill59 starsChanged 16 days agoMITView on GitHub

Writing/changing/reviewing/sweeping tests: reject duplicate or implementation-coupled proof; remove test-only production seams.

We split this skill into the rules it gives an agent

6 rules. 0 are common, 5 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 62 edited versions we read keep these.

  • 5

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Before adding test, answer:

    line 14
  2. Distinctive:

    Use boundary and cost guide.

    line 24
  3. Distinctive:

    Keep independent API, SDK, protocol, config, migration, storage, security, platform, default, prompt-byte, generated-language, package, …

    line 42
  4. Very specific:

    Before audit edit: read candidate evidence and workflow.

    line 51
  5. Distinctive:

    Delete obsolete production seams with tests.

    line 53
  6. Distinctive:

    Follow proof policy; preserve active Vitest checkouts.

    line 54

“Common” is measured: kept by at least 6 in 10 of the 62 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

  • Authoring gates every new/changed test.
  • Audits: remove low-value proof in coherent owner batches; never chase deletion counts.
  • Whole-subsystem campaign: read CAMPAIGN.md first.

Authoring gate

Before adding test, answer:

  1. Protected observable behavior, invariant, or independent contract?
  2. Credible regression that makes it fail?
  3. Why existing proof misses it? Each contract: one primary owner at strongest boundary. Another layer needs distinct transport/lifecycle risk. Extend tables/shared fixtures; consolidate repeated setup.
  4. Export, flag, wrapper, injection hook with no production caller needed? Move proof to real boundary instead.
  • Use boundary and cost guide.
  • Regressions must fail pre-fix for intended reason, pass after repair; report unavailable baseline proof.
  • One owner regression covers bug; never replay at every crossed layer.
  • Behavior-preserving refactors should not break test.

Junk patterns

  • Reject self-comparisons, copied inventories, source greps, implementation/call-shape assertions, duplicate contracts, test-only seams, subject-generated expected values, mocks supplying asserted behavior.
  • Fixtures must not fabricate owner receipts/order or claim persistence path never writes.
  • Negative controls must fail at intended guard; names must match exercised behavior.
  • Auditing candidates: use full checklist.

Retention bar

  • Keep independent API, SDK, protocol, config, migration, storage, security, platform, default, prompt-byte, generated-language, package, release, architecture, observable-ordering contracts. Static/slow ≠ disposable.
  • Source inspection must survive identifier-only refactors and guard independent user-facing contract.
  • Baseline failures may be bugs to repair, not tests to delete.

Audit and validation

  • Before audit edit: read candidate evidence and workflow; inspect full owners/callers/history; record remaining proof before deletion.
  • Delete obsolete production seams with tests; never optimize for deletion counts.
  • Follow proof policy; preserve active Vitest checkouts; run owner/sibling proof + changed checks; then autoreview.
  • Report causes, retained contracts, proof/cost, production versus test LOC, follow-ups. Commit/push/land only with task authority.

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.

Check your setup, free