odin-run

Use when a completed agent run must be recorded as durable, queryable evidence. Appends one entry to the JSONL run log under an ISO date guard, prunes expired entries, and updates the last-run pointer. Don't use for remote, credential, publish, deploy, or irreversible changes.

Use when the user says "atomic PRs" or requests one issue or PR per logical change. Don't use for single-change pushes or uncommitted change-sets.

Use when the user says release this, publish this package, or cut a release for a changesets-based npm package. Not for non-npm packages or releases without a changesets workflow.

Use when the user runs /browser-cookie-store to populate the session cookie store from installed browsers for authenticated browsing. Discovers browser profiles, reads and decrypts local cookie databases, extracts session cookies, and writes them to the destination store. Not for remote, credential, publish, deploy, or irreversible changes.

Use when the user runs /browser-qa to run the QA verification pass and return report-only results without entering a fix loop. Runs configured build, test, and lint checks in order, collects findings, and writes one local report. Not for remote, credential, publish, deploy, or irreversible changes.

Use when the user asks to cherry-pick, backport, or apply a hotfix to a release branch. Not for merging feature branches or cutting new release branches.

Use when the user wants to batch-close resolved or outdated tracker items. Fetches item metadata, filters by evidence-backed criteria, and presents a prepared batch for the user to close manually. The agent never closes tracker items itself. Not for individual item closure or items still under active work.

Use when the user asks to create a PR, open or update a draft PR, write or refresh a PR description, or summarize changes for review. Runs the full template-gated flow by default; a quick mode opens a lightweight PR when the user asks for speed. Not for multi-PR stacks or release publishing.

Use when the user asks to cut, trigger, or start a release candidate for a release branch. Validates the branch against configured channel prefixes, dispatches the release workflow, receives the run URL, and posts a status notification. Don't use for full releases, hotfixes, or non-release-candidate workflow dispatches.

Use after a build, QA pass, demo, user complaint, or abandoned attempt when the next pass needs lessons rather than code. Writes an evidence-backed memo and next-cycle plan so a fresh agent can preserve working assets, reject failed patterns, and test the right gates first. Not for changelog extraction; not for session handoff — use handoff.

Use when the user invokes /duet, says pair on this, or faces aesthetic, architectural, or irreversible decisions. Surfaces every genuine fork as a user pick at the moment of decision so no review-bottleneck diff is produced. Not for one-shot fork resolution — use decide.

Use when the user needs to restore service from a specific known failure by applying a single prescribed recovery operation. Verifies the symptom, validates the prescription against its authority source, records the rollback path, applies the operation, and confirms restoration via a health signal. Not for design-time failure definition or open-ended debugging.

Use when implementation is complete and the full test suite is green and an integration decision is needed for a development branch or worktree. Don't use for branches with failing tests or for starting new work.

Use when the user says ship it now, no phases, or finish it now, or when in-scope work would otherwise be deferred to phases, rollouts, follow-up PRs, or TODOs. Implements every in-scope path in one change. Not for remote, credential, publish, deploy, or irreversible changes.

Use when the user asks to fix P0s, address critical issues, or work on priorities from the weekly product briefing. Don't use for non-P0 issues or local bug fixes.

Use when a set of open PRs needs landing together: gate, fix minor findings, merge parent-first. Not for single-PR review feedback — use resolve-pr-feedback. Not for gate-only evaluation without merge — use gate-proposed-change. Human-only.

Use when the user asks to find PRs to review or check the team review queue. Returns a table of open PRs needing review with URLs and reasons. Not for summarizing PR feedback — use get-pr-comments. Read-only.

Use when the user explicitly invokes branch or worktree cleanup for a repo with accumulated local branches. Also handles tidy's scratch-file cleanup when the user says tidy and the target is scratch artifacts. Don't use for remote branch deletion or force-push operations.

Use when the user asks for release, version bump, changelog, or branch workflow beyond a single commit. Don't use for single commits or for publishing to a package registry.

Use when the user explicitly invokes backlog triage for a GitHub repository's open pull requests and issues. Don't use for proactive triage, non-GitHub trackers, or single-issue bug triage — use github-bug-report-triage for one bug issue.

Use when evaluating whether a bug issue has sufficient detail and identifying missing information from the reporter. Don't use for feature requests, questions, non-bug issues, or repo-wide backlog triage — use github-backlog-triage.

Use when finding duplicate GitHub issues or checking for similar issues against a target issue. Runs a multi-strategy search and returns a duplicates classification. Don't use for closing, labeling, or modifying any duplicate issue.

Use when a durable effort needs an approved, checkable success predicate before work starts; writes the goal, verifier, budget, and run-log scaffold. Not for requirement-to-evidence contract ledgers. Never remote, credential, publish, deploy, or irreversible.

Use when a task carries guardrail-adjacent material — stealth, scraping, privacy, IP, policy, security — or mixes reversible work with irreversible, credential, data-at-rest, migration, or deletion work, or the user says "autobahn this", or the moment the agent is about to hedge, soften, or silently skip. Carves risky items into a descope ledger, then runs the safe remainder in a fresh subagent. Not for performing the carved risky work.

Use when a ticket DAG from a complete specification needs parallel execution into a green draft PR. A single approved feature is the degenerate one-ticket DAG. Not for a single settled ticket with no spec — use work; not for ticket decomposition — use to-tickets.

Use when the user explicitly asks to choose which issues or pull requests to abandon interactively. Don't use for closing items without per-item selection and explicit approval.

Use when filing an approved task spec as a GitHub issue with a local archive and optional worktree implementer. Don't use for spec drafting without human interrogation and redaction gates.

Use when a human asks to compare one closed or stale tracker issue with current reality and mark it done or update it. Don't use for bulk issue reconciliation or multi-issue sweeps.

Use when a human invokes triage on a new configured Slack issue report. Produces a single classified verdict and posts it to the Slack thread, with deduped tracker state. Don't use for triaging reports from other channels or posting more than one verdict.

Use when a maintainer or collaborator explicitly asks to review and land one external pull request. Don't use for internal pull requests or landing without preserving contributor authorship.

Use when the user says "loop me" or asks to design a recurring workflow. Produces workflow specs that an implementer can build without another question. Don't use for remote, credential, publish, deploy, or irreversible changes.

Use when a human explicitly asks to reshape or annotate one pull request for review. Don't use for pushing the rewritten branch or mutating any remote.

Use when a browser extension that talks to a native messaging host fails: the extension reports disconnected, tools time out, or the wrong host spawns because two client applications registered manifests for the same host name. Reconciles to exactly one active host with a reachable socket. Not for network, browser-install, or unrelated extension failures.

Use when a human explicitly asks to ship work through a clean branch and pull request. Don't use for force-pushing, reusing conflicting branches, or widening the change scope.

Use when a user starts a new work session and asks to split human decisions from agent execution. Writes a contract-bound brief under run/<session-id>/ and runs spawn, work, review, and human-gate phases to completion. Not for remote, credential, publish, deploy, or irreversible changes.

Use when a project is between phases, the author asks what to do next, too many threads are open, or work needs re-entry. Returns exactly one next action with an observable done-when and a cited reason it beats other visible options. Not for gating whether one named task may proceed.

Use when the user explicitly asks to create, update, query, or archive Notion pages, databases, or blocks. Not for bulk operations, recursive edits, or widening the workspace scope.

Use when the user asks to choose, reconcile, or apply an open-source license and package metadata. Classifies candidates using standard OSI families, checks dependency license compatibility against the reciprocity goal, and when requested applies the chosen license atomically across LICENSE, package metadata, and README. Not for readiness auditing.

Use when a plan must be stress-tested, iteratively improved, and scored against a 5/5 quality bar across six dimensions. Drafts, scores with a deterministic rubric, and revises up to a fixed iteration limit. Not for a committed-direction brief; use plan. Not for task breakdown; use planning-and-task-breakdown.

Use when a human explicitly requests the daily on-call Sentry issue digest for a configured Slack channel. Not for posting without explicit human authorization for that run.

Use when a landed merge, release, or completed change needs its cleanup surface reconciled. Scans the diff for stale TODOs, satisfied deprecations, unused flags, and documentation gaps; applies bounded local fixes in a worktree and files tickets with assigned ownership for the rest. Not for unrelated refactoring.

Use when a user explicitly asks to post, update, or check cherry-pick status for a release as a single Slack Block Kit status board. Lists PRs belonging to the release, maps observed evidence to defined cherry-pick statuses, merges manual overrides, and posts or updates exactly one message. Not for mutating pull requests or posting to multiple messages.

Use when the user explicitly asks to share a message on Slack through an incoming webhook. Not for posting without an explicit request or for retrying an ambiguous delivery.

Use when a human explicitly asks to link a GitHub issue and Linear ticket to a pull request body. Appends one Issues block with the supplied references. Not for unlinking, searching for issues, or substituting missing identifiers.

Use when asked to prepare a repository for public launch: audit for secrets, harden licensing, documentation, CI, and release automation; stop before the visibility switch. Don't use for remote, credential, publish, deploy, or irreversible changes.

Use when the user asks to propose an issue, file or open a bug report, or turn a reported defect into a tracked issue. Grounds the defect in cited source, gates it, and files one issue. Don't use for fixing the defect, triaging existing issues, or reviewing PRs.

Use when asked to commit and push to the currently checked-out branch, including the default branch. Don't use for creating branches, opening PRs, force pushes, or pushing any branch other than the current one.

Use when the user decides to ship a release. Bumps version, commits, writes release notes, and pushes a signed tag after two explicit human confirmations. Not for running workflow-owned steps by hand — use the CI/CD workflow. Not for PR-based releases — use publish-release-pr.

Use when the user runs /release-landing-report to summarize landed changes and return a landing summary report. Not for tasks that require source or remote-system changes.

Use when a scheduled or watcher tick requests a repository-health pass. Classifies CI, PR, issue, commit, discussion, and run-state signals as High, Watch, or Noise with evidence, then persists a bounded report. Not for source, label, merge, or close mutation.