odie

Analyze recurring failure evidence and produce a hard-rule plan: which patterns can be enforced mechanically, which existing tools should enforce them, where the checks should run, and which patterns must remain human judgment.

Contract

• Run when there is recurring or high-signal evidence from transcripts, commit history, Sentry issues, GitHub issues or PRs, CI failures, reviewer feedback, Garfield findings, or an explicit request to codify a repeated failure pattern.
• Treat the source repository as the active repo being improved.
• Prefer evidence that is cross-checked across at least two sources, such as transcript findings plus bugfix commits, or Sentry events plus follow-up PRs.
• Discover existing tooling before recommending new tooling.
• Recommend only hard, mechanically enforceable rules with a clear pass/fail signal.
• Prefer strengthening existing adequate tools over adding duplicate tools; prefer repo-standard or maintained rule frameworks over one-off scripts.
• Prefer existing generalized runners such as lint, check, or test. If a separate command is justified, use one aggregate tool runner such as lint:ast-grep, not finding-specific runners such as lint:comments.
• Before recommending a custom script, first try to express the exact signal with an existing repo tool, maintained linter rule, structural-search rule, schema check, generated-artifact diff check, or deterministic test helper.
• Recommend custom scripts only for stable repo-specific invariants that cannot be expressed by those frameworks without overmatching and have small valid/invalid fixtures.
• Do not implement checks, install dependencies, edit CI, or change configs unless the user explicitly asks for implementation.
• Do not propose checks for one-off, judgment-heavy, product-requirement, or intentionally accepted tradeoff findings.
• Run a secondary verification pass before final output to remove candidates that still require true human judgment.
• If current tool capabilities, install commands, or migration paths matter and are not already present in the repo, verify them from official docs when possible and cite the source in the handoff.

Inputs