Finding simplifications

Turn a broad "find things to simplify" request into evidence-backed Agent Notes that remove or collapse existing surface across code, docs, and skills. It is guidance, not a checklist: follow the code, keep judgment active, and prefer a few well-proven candidates over a pile of thin guesses.

Start with repo context

• Read the root AGENTS.md — the pre-release stance when present, and conventions such as tests-are-not-golden-truth and Agent Notes-are-not-golden-truth doctrines — plus the repository's defensive-patterns and testing docs when they exist.
• Skim the architecture doc before judging core code; simplifications that fight the service map or event taxonomy need extra evidence.
• Use the Agent Note tree and its rules to understand intentional architecture; a recorded decision needs new evidence to overturn, not a "looks complex" flag. Start with high-signal implemented examples — capability seams, twin adapters, and persistence notes — when the tree has them.
• Treat recorded architectural twins — dual LLM adapters and dual persistence backends — as intentional by default. Do not propose deleting either side as "low effort" unless the user explicitly overrides that constraint. Removing an unused method or hook inside a protected seam can still be valid if it does not collapse the protected design.

What counts as a strong candidate

A strong simplification removes, folds, or demotes something real and has clear evidence that the current design costs more than it buys: