odin-code

Plugin odin-code from marketplace odin-marketplace in OutlineDriven/odin-claude-plugin. Commands read from the repo's manifest — 1 month ago.

Skills (35)

• api-and-interface-design

  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.

• architect

  Use when non-trivial code needs a design, codebase design or architecture needs improving, or one module needs targeted interface narrowing, seams, or testability. Not for diagrams, deploy, or irreversible changes.

• ast-grep

  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.

• breaking-driven

  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.

• clean-clean-cut

  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.

• code-simplification

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

• constraint-driven-development

  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.

• contract-driven

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

• deprecate-and-migrate

  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.

• deps-upgrade

  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.

• design-it-twice

  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.

• deslop

  Use when the user says deslop, debloat, tidy, simplify, clean a diff, cleanup codebase, or deslop branch diff, or remove dead code or config. Not for remote, credential, publish, deploy, or irreversible changes.

• dimensional-analysis

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

• document-api-endpoint

  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.

• explore

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

• fromzero

  Use when replacing a greenfield attempt with a clean pad of verified requirements. Not for rebuilding from primitives: use from-first-principle. Requires a committed, VCS-recoverable attempt.

• guillotine

  Use when dead, duplicate, superseded, or generated residue must leave more than one artifact class of a repo or subsystem, preserving behavior. Not for one enumerated record set: use clean-clean-cut.

• incremental-implementation

  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.

• minimalism-driven

  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.

• no-comments

  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.

• offense

  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.

• optimize

  Use when asked to optimize code, make a path faster, make this as fast as possible, reduce allocations, repair a regression, profile a target, grill every inefficiency, or run a subsystem or repo-wide performance campaign against a measured floor; when a performance requirement, slowness report, Cor

• principles

  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.

• refactor-break-compat

  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.

• reproduce-and-fix-issues

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

• restart-keeping-lessons

  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.

• simplify

  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.

• slicing-code-context

  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.

• source-driven

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

• spec-driven-implementation

  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.

• strike-the-root

  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.

• to-greenfield

  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.

• type-driven

  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.

• universal-invariant-baseline

  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.

• unleak-abstraction

  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.

Similar plugins