Odin Code

Use when asked to explore the codebase to map structure, symbols, and dependencies. Not for a single file under 50 LOC: read it directly.

Use when a human says "overhaul", "rebuild this subsystem", or "rewrite it from scratch". Not for thin-slice features: use incremental-implementation. Not for root-cause repair: use strike-the-root.

Use when asked to run AST-based structural search, lint, or rewrite of code when regex is too fragile. Not for remote, credential, publish, deploy, or irreversible changes.

Use when the user says "simplify this diff" or asks for a compression pass over a change-set. Not for dead-code sweeps: use deslop.

Use when a request names a working principle (subtract before you add, idempotent operations, never block on the human) or asks which principle applies. Not for running a repair: use strike-the-root.

Use when asked to audit comments in code files and propose structural replacements or deletions with per-candidate approval. Not for deterministic commented-out-code removal: use deslop.

Use when modeling a domain, encoding a state machine, hardening APIs, making invalid states unrepresentable, or parsing instead of validating. Not for TypeScript: use typescript-best-practices.

Use when dependency upgrades need batching for CVEs, a major release, forced compatibility, a scheduled or vulnerability-triggered sweep. Not for PR queue triage: use github-backlog-triage.

Use when writing or verifying framework-specific code, boilerplate, or a documented, correct implementation. Not for remote, credential, publish, deploy, or irreversible changes.

Use when the user says greenfield this or rescue this codebase, names a field (dark, red, blue, or brown), or diagnoses a subsystem. Not for specs: use to-spec. Not for remote or irreversible changes.

Use when bloated code needs clean re-derivation, or the user says "this module is bloated" or "break it and rebuild". Not for untracked data or changes without VCS rollback.

Use when asked to run /clean-clean-cut to cut accumulated records and residue. Not for untracked or non-VCS changes, or branch/worktree cleanup: use git-cleanup.

Use when crossing a public API boundary, guarding complex invariants, or hardening untrusted input or integration seams. Not for remote or irreversible changes.

Use when asked to design a module interface, seam, or testable boundary. Not for UI direction picking: use design. No source or remote-system changes.

Use when optimizing estimated hot and complexity-neutral cold paths while refusing complexity theater. Not for measured-floor rebuilds: use extremely-optimize. Not for hypothesis-only: use fastopt.

Use when a bug, failure, flake, regression, review finding, or ticket needs the core fixed so it cannot recur. Not for greenfield features: use tdd. Not for style-only review or typo-class one-liners.

Use when writing or restructuring code, before adding a helper, wrapper, config key, or dependency, or when the user asks for minimal or DRY code. Not for performance tuning: use optimize.

Use when asked to run a performance campaign against a measured floor. Not for hypothesis-only analysis without mutation: use fastopt.

Use when an abstraction leak must be sealed as a module seam, configuration option, or explicit override, or exposed as a named boundary. Not for detecting concealment patterns: use no-hide.

Use when the user asks to simplify, clean, or refine code. Not for new abstractions or whole-codebase refactors.

Use when code mixes units, fixed-point precisions, scaling factors, rates, prices, shares, or conversions. Not for type-level unit modeling: use type-driven.

Use when an exact symbol, path, entrypoint, or line range can bound a focused code question or patch proposal under a fixed source budget. Not for source changes or broad repository exploration.

Use when asked to remove old code, migrate consumers, or decide whether to maintain or sunset a system. Not for untracked data or changes without VCS rollback.

Use when reconciling an API endpoint's generated OpenAPI schema and declared response types with its actual runtime response. Not for general API documentation: use docs-and-adrs.

Use when modernizing APIs, removing compat shims, killing feature flags, or rewriting a subsystem cleanly. Not for additive refactors that must preserve the old path.

Use when an implementation has more workarounds than structure and another patch will not pay. Not for in-place re-derivation: use breaking-driven. Not for one-artifact rewrites: use rewrite-clean-v0.

Use when asked to design or change a public API, route, CLI flag, or module boundary. Not for remote, credential, publish, deploy, or irreversible changes.

Use when a trusted bug or performance report needs reproduction and fix. Not for untrusted reports or scope beyond the named feature.

Use when implementing a multi-file change, building a feature from a breakdown, or writing a large amount of code. Not for a single settled ticket: use work.

Use when a feature begins or specs are checked in: author or update behavioral specs and keep them current with what ships. Not for producing the initial approved spec and plan: use spec-driven.

Use when invoked to apply an invariant-first, fail-fast, special-case-eliminating baseline. Not for domain models in types: use type-driven. Not for design-by-contract: use contract-driven.

Use when asked to implement under non-negotiable constraints: performance budgets, platform limits, legal or API rules. Not for remote, credential, publish, deploy, or irreversible changes.