
Guides structured design brainstorming — explores the codebase, asks clarifying questions, proposes multiple approaches with trade-offs, and writes an approved spec to the project. Use before implementation to think through design decisions and avoid premature coding. Produces a persistent artifact that feeds into plan mode and TDD. For stakeholder-facing or acceptance-criteria-driven work, the spec includes a Given/When/Then Scenarios section consumed by /optimus:tdd.
Use when starting a new project or product and you want a docs-first plan before writing code — scaffolds an empty, product-neutral spec-driven-development cascade (product vision, MVP PRD, target tech-stack) for a human to fill, then hands off to brainstorm. Emits skeletons only; it never authors product content and never overwrites existing docs.
Crafts optimized, copy-ready prompts for any AI tool — LLMs, coding agents, image generators, workflow tools. Extracts intent, selects the right template, runs a diagnostic checklist, and delivers a token-efficient prompt. Accepts input in any language; English output by default. Use when writing, fixing, improving, or adapting a prompt for any AI tool.
Creates or updates a pull request (GitHub) or merge request (GitLab) for the current branch using the Conventional PR format — intent, summary, changes, rationale, and test plan. Captures the implementation conversation's intent into the PR description when run in the same session. Use when a branch is ready for review, or to update an existing PR/MR description.
Guides test-driven development — decompose a feature or bug fix into behaviors, then cycle through Red (failing test) → Green (minimal implementation) → Refactor for each one. Requires /optimus:init and working test infrastructure. Use when starting a new feature or bug fix with test-first discipline.
Fetches and optimizes context from a JIRA issue for AI-assisted development. Searches assigned issues or fetches by key. Distills title, description, acceptance criteria, sprint context, and comments into a structured task description. Analyzes the codebase to surface missing criteria, scope, and risks. Optionally enriches the JIRA issue with a structured analysis comment, and for Complex-scope work can spawn implementation tickets in JIRA. Re-running on the same key refreshes the local task with the latest JIRA state instead of overwriting prior enrichment. Use before /optimus:tdd, /optimus:brainstorm, or /optimus:branch to pull task context from JIRA, or to refresh existing context after JIRA edits.
Improves unit test coverage on demand — discovers testing gaps and generates tests that follow project conventions. Requires /optimus:init to have set up test infrastructure first. Conservative — only adds new test files, never refactors existing source code. Supports `deep` mode for iterative in-conversation test generation and `deep harness` mode for an automated multi-cycle unit-test + testability-refactor loop with fresh context per phase. Use when test coverage is low, after adding new code that lacks tests, or when you want an automated coverage-improvement harness.
Compacts the current conversation into a single self-contained handoff document under docs/handoffs/ so a fresh agent — a new session, a different AI tool, or another developer on a different machine — can resume the work by reading only that file. References committed artifacts (PRDs, plans, ADRs, issues, commits) by path or URL and inlines anything not yet pushed. Redacts secrets and PII. Re-running on an existing handoff lets you enhance the shared doc or overwrite it. Use when pausing work that someone else or a future session will pick up, or when a long conversation needs a durable summary.
Suggests conventional commit messages by analyzing staged, unstaged, and untracked git changes — read-only, never commits. Use when a commit message suggestion is needed without actually committing.
Creates and switches to a new, conventionally named branch — derives the name from an inline description, conversation context, or local git diffs. Preserves all local changes. Never commits or pushes. Use when you want a properly named branch for new or in-progress work.
Stages, commits, and optionally pushes local changes with a conventional commit message — analyzes diffs, generates the message, confirms with the user, and commits. On protected branches, offers to create a feature branch automatically. Multi-repo aware. Use when ready to commit work in one step.
Generates or updates a project's HOW-TO-RUN.md — a single document that teaches a new developer how to set up their environment and run the project locally. Detects build system, toolchain, SDKs, source dependencies (git submodules, sibling repos), external services, environment config, and hardware/OS requirements. Works for web apps, C/C++ desktop apps, native mobile, JVM/Android, game engines, embedded/firmware, and backend services. Audits an existing HOW-TO-RUN.md against actual project state. Learns from setup info found in README.md / CONTRIBUTING.md / docs but never modifies those files — any outdated info found elsewhere is reported to the user at the end. Use after /optimus:init or standalone when onboarding feels broken. Handles single projects, monorepos, and multi-repo workspaces. When the file already exists, also offers a guided in-chat walkthrough where the user runs each documented step locally — the skill never executes commands itself. Use the walkthrough when onboarding a new developer.
--- description: Reviews local changes, PRs/MRs, or branch diffs against project coding guidelines using 5 to 7 parallel review agents (bug detection, security/logic, guideline compliance x2, code simplification, test coverage, contract quality). Use before committing, on open PRs/MRs, or to review any branch diff. HIGH SIGNAL only: real bugs, logic errors, security concerns, and guideline violations. Supports a "deep" mode for iterative auto-fix — reviews and fixes code in a loop until clean. d
Refactors existing code for guideline compliance and testability using 4 parallel analysis agents (guideline compliance, testability barriers, duplication/consistency, code-simplifier). Two goals — align code with project guidelines AND make untestable code testable so /optimus:unit-test can safely increase coverage. Use after /optimus:init to align existing code, before /optimus:unit-test to remove testability barriers, or periodically to prevent tech debt. Supports "testability" focus (after unit-test flags untestable code) or "guidelines" focus (after init establishes rules) to prioritize finding categories, flexible scoping, and a "deep" mode for iterative refactoring (default 8, up to 10 iterations).
Removes files installed by /optimus:init and /optimus:permissions from the project. Compares each file against plugin templates and classifies as unmodified, likely generated, or user-modified. Always asks before deleting. Git-tracked files are noted as recoverable. Tests are never touched. Monorepo and multi-repo aware. Use for clean reinstall or to stop using optimus.
Configures Claude Code permissions for safe agent autonomy. Creates settings.json with allow/deny rules and a path-restriction hook. Use after /optimus:init to enable autonomous agent workflows, or standalone to lock down a project's permission boundaries.
Prepares a project for Claude Code — generates CLAUDE.md with progressive disclosure docs, auto-format hooks, and test infrastructure (framework, coverage tooling, testing docs). Detects empty directories and offers new-project scaffolding via official stack tooling before setup. Also audits and syncs existing documentation against source code. Replaces /init. Supports single projects, monorepos, and multi-repo workspaces (separate git repos under a shared parent directory). Use to bootstrap a new or existing project for Claude Code, or re-run to update an outdated setup.
Creates a git worktree for isolated parallel development — new branch in a separate directory with project setup and test baseline. Enables multiple Claude Code sessions on different tasks simultaneously. Multi-repo aware. Use when you need to work on something else without disturbing current work.