ai

Use when the user wants to do a QA session or report multiple bugs — interactive session where bugs are reported conversationally and agents fix them in parallel

Use when executing implementation plans with independent tasks — orchestration pattern for worktree isolation, TDD discipline, and two-stage review. Referenced by execute-plan, fixit, and bugbash.

Use when the user reports a bug or issue that can be fixed without blocking their current work — backgrounds an agent in a worktree to fix and merge back without breaking stride

Use after implementing changes in an OpenSpec project to review implementation against the active change's deltas — auto-fixes confident issues, parks questions for the user

Install the anutron (claude-skills) kit into the current project — symlinks or copies skills, registers hooks, compiles CLAUDE.md from snippets.

Uninstall the anutron (claude-skills) kit from the current project — reverses everything /anutron-install did.

Reference for bash patterns that trigger Claude Code permission guardrails (static-analysis flags that allowlist rules cannot silence). Load when about to run bash with `cd <repo> && git ...`, `$(...)`, backticks, heredocs, inline `python3 -c` / `node -e` / `ruby -e` / `perl -e`, multi-line shell logic with variables/conditionals, or before allowlisting a new script path. Also covers always-prompt verbs and the `git -C` known gap.

Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes — multi-agent competing hypotheses debugging

Generate a handoff prompt to pass context to another agent thread. Use when switching repos, handing off work, or sharing context between agents.

Use at the end of a session to run a retrospective — upgrades skills, fixes codebase gaps, and captures durable knowledge

Use when starting a brand new project from scratch -- runs discovery, picks a tech stack tier, then hands off to brainstorm and build. Guides non-technical and technical users alike.

Use when a project has legacy AI-RON specs (a `.specs` file or top-level `specs/*.md`) but no `openspec/` directory and the user wants spec work. Convert a legacy AI-RON spec project (`.specs` file + `specs/*.md`) to OpenSpec layout with verifiable fidelity. One-time per project. Translator + verifier agents preserve every Given/When/Then case as an OpenSpec scenario, archive originals at `.workflow/legacy-specs/`, and install the new pre-commit hook + CLAUDE.md snippets.

Interactive spec review via Plannotator. Use after writing a spec document (design doc, SPEC file) to let the user review it with inline annotations before committing. Auto-detects the most recently written spec file.

Upload local images to Notion pages natively via the Notion API file upload flow. No external hosting needed — images live inside Notion. Use when embedding images in Notion pages.

Use when done working in a git worktree and ready to merge it back to the main branch — asks whether to merge or squash

Use when an OpenSpec change is approved and ready to implement — executes the change's tasks.md with agent-driven development, worktree isolation, TDD discipline, two-stage review, native Task dependencies for parallel execution, and `openspec archive` at the end.

Use when the user asks for a changelog, release notes, or summary of recent changes

Use before any git commit to check for secrets, security antipatterns, and test breakage

Use when the user wants to merge the current branch to master — merges via GitHub PR

Use when code is ready to ship — opens a PR, waits for CI to pass, fixes failures, addresses review comments, and loops until fully green

Use when a previous review missed something or the user wants a thorough second pass — re-review with fresh eyes, zero regressions, go slow and analyze everything

Use when ready to commit completed work — saves progress and verifies that behavioral code changes are accompanied by deltas in an active OpenSpec change (but never derives specs from code)

Audit codebase spec coverage – inventory OpenSpec capabilities, map them to code, dispatch agents to find behavioral gaps. Use when the user wants to check spec health or find coverage holes.

Use when code exists without spec coverage to detect gaps, infer intent, and recommend OpenSpec capabilities + requirements. Output points the user at `openspec instructions specs` to scaffold the right structure.

List, pick, and execute deferred work items from .workflow/todo/. Use when the user asks about backlog, deferred work, or what needs doing.

Use whenever writing or updating OpenSpec artifact text — thin orchestrator around `openspec instructions <artifact>`. Returns enriched templates plus project context per artifact (proposal, design, tasks, specs).

Use after writing or modifying code to run targeted tests and identify coverage gaps, before claiming code works

Use when the user wants to see what's changed or plan commits — shows uncommitted/unstaged changes grouped by logical commit themes

Use when creating a new skill or improving an existing one — applies best practices for structure, dynamic context, and safety

A personal skill matching the airon-* exclude pattern.

Explore ideas and design solutions collaboratively before building.

Interactive QA session for reporting and fixing bugs in parallel.

Pre-commit quality gate — checks for secrets and test failures.

A personal skill that should not appear in non-full scopes.

Open a PR, wait for CI, fix failures, address review, loop until green.

A skill with no tags field — only installable under scope=full.

You MUST use this before any creative work -- creating features, building components, adding functionality, or modifying behavior. Explores intent, designs the solution, scaffolds an OpenSpec change folder (proposal + design + delta specs + tasks), and hands off to execution.

Use when the user wants to stress-test an idea, plan, or approach — challenges assumptions and finds weaknesses before committing

Pick the long-term-correct option from the choices you just presented. Use when the user types /doitright in response to a multi-option recommendation, meaning "go with the proper long-term fix unless there's a real downside beyond effort."

Restate your prior response in plain, non-technical language and orient the user around the decision they need to make. Use when the user types /eli5 or asks to have something explained simply.