agent-anti-pattern

# Agent Anti-Pattern Audit Treat a static hit as a candidate, never as a finding. Prove the failure mechanism, affected consumer, and safe correction before changing code. Read [references/field-guide.md](references/field-guide.md) before triage. It defines the source grades, six anti-pattern families, false-positive boundaries, finding record, and deletion gate. ## Workflow 1. Freeze the base commit, tracked scope, exclusions, and generated inventory. 2. Reuse existing linters, dependency checks, slop scans, and test collectors. Do not create another scanner for a check they already perform. 3. Trace each candidate through static callers plus entrypoints, registries, decorators, import-by-string, side-effect imports, subprocess workers, schemas, public exports, persisted data, and compatibility contracts. 4. Apply AP-1 through AP-6 from the field guide. Record a harmful consequence or measured non-contribution; size, duplication, or unfamiliarity alone is insufficient. 5. Map affected tests to behavior and invariants. Detect source-string false positives, broad-exception false greens, private-shape pinning, environment leakage, duplicated scenarios, and tests that exist only to keep dead production seams alive. 6. Report every candidate as `KEEP`, `SHRINK`, `DELETE`, `MEASURE`, or `DEFER`. Stop for review before a whole-repository audit edits production or tests. 7. Apply accepted cleanup in small causal groups. Preserve one canonical implementation and rerun objective gates after every group. ## Verdicts | Verdict | Meaning | |---|---| | `KEEP` | A named behavior, safety, evidence, compatibility, or operational consumer justifies the surface. | | `SHRINK` | The contract is real, but a wrapper, branch, payload, capability, or test can be narrowed. | | `DELETE` | The complete deletion gate passes and no contribution remains. | | `MEASURE` | A suspected problem has a falsifiable hypothesis but insufficient evidence. | | `DEFER` | The problem is real but ownership, migration, dependency, or approval blocks safe change. | ## GEODE Routing Use the repository's existing surfaces when present: - `.geode/skills/slop-audit/SKILL.md` and `scripts/slop_audit.py` for discovery-only heuristics; - `.claude/skills/codebase-audit/SKILL.md` for general refactor workflow; - `.claude/skills/anti-deception-checklist/SKILL.md` after every cleanup diff; - Ruff, mypy, deptry, import-linter, architecture baseline, and pytest for deterministic verification. Do not copy their instructions into this skill. Their results remain separate authorities because they scan different scopes and definitions. ## Boundaries - Do not impose universal tool-count, context-token, file-size, parameter, or line-count thresholds. Treat published numbers as setup-specific unless the target contract makes them normative. - Do not infer dead code from zero textual imports. Check dynamic and external consumers first. - Do not infer duplication from a shared method name or protocol signature. - Do not delete tests together with code and call the resulting green suite proof. Name the surviving invariant. - Do not convert a safety, migration, evidence, redaction, or rollback surface into slop merely because it adds code. - Do not add a framework, store, registry, schema, dashboard, or automation without a named consumer and a repeated deterministic gap. - Fail closed to `MEASURE` or `DEFER` when evidence is incomplete. ## Output Report: 1. base SHA, included/excluded inventory, and checks actually run; 2. coverage by audit bucket, without claiming every line was manually read; 3. findings with exact paths, evidence, falsifier, verdict, and smallest fix; 4. explicit false positives and retained surfaces; 5. cleanup order, verification, skipped/live gates, and remaining uncertainty.