| name | slop-audit |
| description | 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.
Trace private helpers through all callers before inlining. Preserve public
facades, dynamic consumers, compatibility fallbacks, distinct regressions, and
integrity guards. An always-true private option may be removed only after all
callers are verified; retain its required behavior unconditionally.
For ownership changes, prove lifetimes and error/ordering parity. Measure
allocations or runtime before claiming a performance gain. Avoid generalizing
an abstraction merely to merge two similar implementations.
Completion
Run focused checks, realistic public-project validation, and the relevant full
suites from docs/development/quality-gates.md. Compare nonempty outputs and
negative controls; include cold/warm/no-cache modes when analysis changes.
Bug fixes require the normal failing reproduction and real-world validation.
In a second pass, revisit previous assumptions with new callers, counterexamples,
or runtime probes. Repeating searches or passing the same suite is not deeper
coverage. Stop when accepted findings are resolved, independent review has no
blockers, and remaining hypotheses have explicit evidence or stated limits.
Report concrete changes and verification, without claiming the repository is
free of defects. An authorized merge is complete only after merged-commit CI.
