odin-code

Use when asked to design or change a public API, route, CLI flag, or module boundary. It documents the contract with semantics and errors, then migrates every consumer so no legacy path remains. Don't use for remote, credential, publish, deploy, or irreversible changes.

Use when asked to run AST-based structural search, lint, or rewrite of code when regex is too fragile. Pattern is validated, blast radius reviewed, and rewrite landed at the correct scope. Don't use for remote, credential, publish, deploy, or irreversible changes.

Use when setting up or modifying CI/CD pipelines, quality gates, test runners, or deployment pipeline configuration through workflow files. Authors in-repository pipeline and deployment configuration with blocking gates, secret references, and rollback. Also handles configuring a deployment pipeline through CI or workflow files without triggering a deployment.

Use when the user says "CI is red", "fix the checks", or "make CI green" on a PR or branch. Diagnoses failing GitHub Actions checks, fixes the root cause, and re-verifies to green. Interactive mode applies a local fix; autonomous mode pushes to a fix branch. Not for deploys, credentials, permission-widening, or rerun-as-fix; non-CI bugs use strike-the-root.

Use when a CI check is failed, absent, pending too long, unstable, or reported unexpectedly. Classify it into a deterministic failure class with the next owner, then emit a reviewable fix plan, without patching. Not for sweeping and patching — use ci-sweeper.

Use when the user asks to simplify, clean, or refine code. Measured mode cuts duplication or branch complexity under a green test gate; clarity mode refines readability while preserving behavior by reasoning. Not for new abstractions or whole-codebase refactors.

Use when designing or improving a module interface, locating a seam, or increasing testability; the chosen module ends up with a small interface that hides complexity and is testable through seams. Not for system-level architecture decisions — use architect.

Use when a user asks to commit or save staged or unstaged changes, create a typed branch, or format history for changelog generation. Each logical concern is committed with a conventional-commits message carrying SemVer effect and issue-closing footers. Not for rewriting existing commit messages; use commit-economy.

Use when the user asks to clean up a finished commit message or bring it to handoff-ready form. Rewrites only messages of HEAD or a short unpushed range; the tree stays byte-identical and dates are preserved by position. Not for creating new commits — use commit.

Use when asked to implement under explicit non-negotiable constraints such as performance budgets, platform limits, or legal or API rules. Extracts constraints into checkable invariants, implements with fast-check loops, and verifies no constraint worsened against a baseline guard. No remote, credential, publish, deploy, or irreversible mutation.

Use when crossing a public API boundary, guarding complex invariants, or hardening untrusted input or integration seams. Implements PRE/POST/INV contracts at the appropriate enforcement layer; violations fail explicitly at the boundary. No remote or irreversible mutation.

Use when the user asks to create a new branch or start work on one. Creates a local git branch named <type>/<short-description> on the correct base with no name collisions. Don't use for remote, credential, publish, deploy, or irreversible changes.

Use when dependency upgrades need tiered batches for CVEs, a major release, forced compatibility, scheduled hygiene, a pre-release lockfile audit, or a cadence-driven or vulnerability-triggered sweep. Classifies each update on a risk ladder, verifies it, or defers it with a reason. Not for PR queue triage; use github-backlog-triage.

Use when the user says deslop, debloat, tidy, simplify, clean up this diff, or deslop a branch diff, or asks to remove dead code, placeholders, stubs, dead fields, redundant wrappers, or stale config, or the slop skill routes here. Not for remote, credential, publish, deploy, or irreversible changes.

Use when adding a new devcontainer or isolated Claude Code dev environment to a repo that lacks one, for Python, Node/TypeScript, Rust, Go, or a combination. Not for editing an existing devcontainer. No remote, credential, publish, deploy, or irreversible changes.

Use when the user asks for a call graph, class hierarchy, module dependency map, containment view, complexity heatmap, or data-flow view derived from code. Emits valid Mermaid from actual structure or explains why no edges exist. Not for embedded rendering — use embed-diagram; not for architecture diagrams — use visual-diagram.

Use when a non-trivial decision sits under uncertainty and correctness matters more than speed. Returns fresh-context adversarial findings with classified reconciliation and a stop condition. Not for patch review — use review; not for plan attacks — use advocate.

Use when auditing the developer-facing surface of a CLI, SDK, library, or package: API contracts, errors, CLI behavior, public types, onboarding, and config. Returns bounded, severity-tiered findings with root-cause analysis and committable fixes.

Use when asked to explore the codebase to map structure, symbols, and dependencies. Produces a structured orientation report with architecture, pattern, tooling, dependency, and critical-file sections.

Use when implementing a multi-file change, building a feature from a breakdown, or writing a large amount of code. Each slice is individually tested and committed; the full suite passes and the feature works end-to-end. Not for a single settled ticket — use implement.

Use when a run needs its own branch and checkout to avoid collisions with concurrent work. Creates an isolated worktree, tracks a five-status lifecycle in a manifest, and removes only terminal worktrees. Not for feature-work isolation — use isolate-workspace-gate.

Use when asked to start feature work that needs isolation, or before executing an implementation plan. Creates an isolated git worktree with symlinked hooks, runs setup, and gates on a green baseline test suite. Not for loop-run worktree lifecycle — use isolate-work-in-worktree.

Use when verification is looping, would re-run untouched code, or duplicates an established proof. Runs the minimum complete gate once and delivers on the first green result. Don't use for tasks that require source or remote-system changes.

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. Produce the smallest complete implementation whose intent is obvious. Not for performance tuning — use the optimize skill.

Use when asked to audit comments in code files and propose structural replacements or deletions with per-candidate approval. Enumerates comments in C, JavaScript, TypeScript, HTML, CSS, and shell-style syntax, classifies each as earned or unearned, drafts structural alternatives, and returns a complete accounting ledger. Not for deterministic commented-out-code removal; use deslop.

Use when adding telemetry, composing a durable observability surface, reviewing alerting rules, shipping a production feature, or diagnosing an opaque production issue. Instruments code with structured logs, bounded metrics, and critical-path tracing, then verifies local emission. Not for diagnosing a live failure right now, profiling measured slowness, or launch-day runbooks.

Use when a human says "overhaul", "rebuild this subsystem", or "rewrite it from scratch" and the broken structure must be demolished and re-derived from its contracts. Deletes rather than deprecates, collapses special cases into the general case, and migrates every caller in one change. Not for thin-slice features — use incremental-implementation; not for root-cause bug repair — use strike-the-root.

Use when multi-step work must be broken into dependency-ordered tasks before implementation begins. Gives every task a checkable acceptance criterion and a coherent size bound, then requires explicit user approval. Not for scoring a plan; use planning. Not for a committed-direction brief; use plan.

Use when a request names a working principle (subtract before you add, idempotent operations, never block on the human) or asks which principle governs a decision. Returns the law and its bite point; routes to the owning skill for execution. Not for running a repair — use fix.

Use when a trusted bug or performance report needs reproduction and fix. Drives the application, captures reproduction evidence, implements the minimal fix, and opens one draft PR with human approval. Not for untrusted reports or scope beyond the named feature.

Use when a bug report or UI-visible defect exists. Spawns repro agents to reproduce it locally and writes an artifact directory containing a structured summary with status, steps, environment, evidence, and next step. Not for fixing the bug — use reproduce-and-fix-issues.

Use when a merge, rebase, cherry-pick, or stash pop stops on conflicts. Read both intents from primary sources, resolve every hunk, verify with scoped checks, and finish the integration. Not for people-mediation conflicts — use culture-conflict-mediation.

Use when asked to review a pull request, examine code changes, find bugs, or audit a branch. Standard mode produces a severity-graded validated-findings report with concrete fixes; depth mode fans out parallel bug/security and quality reviewers and synthesizes a unified verdict. Not for an iterative review-and-fix loop — use audit-project.

Use when asked to receive code review feedback: clarify every item, implement accepted items locally with tests, draft technical pushback for questionable items, and stop before any GitHub reply or remote mutation. Not for posting replies — use resolve-pr-feedback.

Use when a human asks for the change shape before reading a diff. Renders a compact summary of added/removed files, line counts, and change type so the human can decide where to dive in. Not for a full findings report — use review; for an interactive walk — use show-review.

Use when asked to run smoke tests or verify a local build. Applies minimal fixes that unblock a stable passing result and reports flake risk honestly. Not for iterative bug fixing — use fix.

Use when a user supplies existing SARIF to inspect, filter, aggregate, deduplicate, diff, convert, or gate findings without running a scanner. Produces the requested findings or derived artifacts. Not for running a scanner — use the relevant security-review skill.

Use when the user says set up gitignore, fix gitignore, or untracked files keep appearing. Writes or merges .gitignore under stable section anchors and proves reruns produce no diff. Not for remote, credential, publish, deploy, or irreversible changes.

Use when installing or repairing one repository-local pre-commit hook using the project's current gates, or when a repo needs package-manager-native commit-time checks. Extends existing hook tooling instead of duplicating it; JS uses Lefthook and Biome, Python/Rust/OCaml use prek. Not for remote or irreversible changes.

Use when the user says "simplify this diff" or asks for a compression pass over a change-set. Decomposes the diff into reuse, quality, and efficiency axes; applies validated findings as atomic issue-class commits; auto-reverts regressions. Not for dead-code sweeps — use deslop.

Use when writing or verifying framework-specific code, boilerplate, or a documented, correct implementation. Backs every framework decision with a cited official source and flags unverified patterns. Not for remote, credential, publish, deploy, or irreversible changes.

Use when starting a project or feature, requirements are unclear, or a change crosses modules. Produces an approved six-area spec, plan, tasks, and an offensive-first TDD implementation. Not for implementation from existing specs — use spec-driven-implementation.

Use when a significant 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. Don't use for remote or irreversible changes.

Use when asked to develop a fix or feature test-first, plan a multi-step TDD build, or work red-to-green in slices. Writes attacks before implementation, probes the suite with mutations, and advances one vertical slice at a time. Not for hardening existing code without a change; use tests-adversarial. Not for deleting weak tests; use tests-purge-unneeded.

Use when hardening error handling, validating boundary behavior, or hunting silent failures. Not for feature development — use tdd (offensive-first); not for test deletion — use tests-purge-unneeded; not for remote or irreversible changes.

Use when settled conversation decisions need synthesis into an agent-ready implementation spec at docs/specs/<feature-slug>-spec.md, stopping before publication. Not for turning plans into tickets — use to-tickets; not for remote, credential, publish, deploy, or irreversible changes.

Use when a quick structural overview of a target directory is needed before deeper codebase analysis. Runs a read-only Trailmark summary returning detected languages, Entrypoints, and Dependencies. Not for detailed structural analysis — use trailmark-structural; not for full graph queries — use build-program-graph; not for source or remote-system changes.

Use when the work is modeling a domain, encoding a state machine, hardening an API boundary, making invalid states unrepresentable, or parsing instead of validating. Not for TypeScript-specific doctrine — use typescript-best-practices; not for remote, credential, publish, deploy, or irreversible changes.

Use when a user explicitly invokes this skill to apply an invariant-first, fail-fast, special-case-eliminating baseline to a named implementation. Not for encoding domain models in types or design-by-contract — use type-driven or contract-driven.

Use when asked to compare implementation against repository specs, report material mismatches, and resolve each one by the user's decision. Also handles acknowledged PR-review commitments when the branch has review history. Not for general fact-checking — use verify-both-ways.