Slop Audit
Audit Fallow for unnecessary code, misleading tests, redundant abstractions, avoidable...
Install
npx skills add fallow-rs/fallow --skill slop-audit -g -a claude-code -y- Repository
- fallow-rs/fallow5.3k
- Category
- Testing
- Updated
- 3d ago
- License
- MIT
- Context cost
- Lightabout 874 tokens
- Runs scripts
- No, instructions only
What it does
Audit Fallow for unnecessary code, misleading tests, redundant abstractions, avoidable copying, and stale maintenance guidance. Use for a requested slop audit or deep cleanup pass.
Slop audit
Use the native implement lifecycle for accepted changes, including its ready
PR requirement. Finish with review, ship when authorized, and sweep.
Read docs/development/repo-map.md to choose concrete ownership boundaries.
Evidence before cleanup
Maintain a temporary ledger outside tracked files. For a repository-wide pass, cover the analyzer pipeline, engine/API/output/CLI, protocol hosts, editor and web consumers, packaging/sidecars, and maintenance tooling. Inspect these axes within each relevant domain:
- tests: tautologies, shadow implementations, unreachable assertions, weak failure injection, and duplicate behavior coverage;
- abstractions: forwarding wrappers, test-only seams, speculative options, duplicated normalization or derived state;
- runtime cost: avoidable owned copies, intermediate collections, repeated work;
- failure behavior: swallowed errors, stale fallbacks, lifecycle and cleanup;
- ownership: public contracts, dynamic entrypoints, security/release boundaries;
- maintenance: obsolete comments, copied catalogues, dead routes and dependencies.
Record exact paths, real callers, the proposed simplification, retained behavioral coverage, and validation evidence. Distinguish inspected/no-change from unexamined or blocked areas. A search hit is a hypothesis, not a finding. Use disjoint subagents for independent domains when available, then have a reviewer challenge both accepted changes and plausible no-change decisions.
Before removing a test, establish which executed assertion implies its useful
contract. For misleading tests, inject a realistic production fault and show
that the old test accepts it while the replacement rejects it. Keep the
replacement on the runtime path, not a second implementation in test code.
Similar bodies, assertion counts, or deletion targets do not prove redundancy.
Apply the test evidence rules in docs/development/quality-gates.md to each
kept or replacement test.


