Executes an implementation plan created by the make_plan skill. Use when the user says "exec_plan", "run the plan", "execute the plan", "implement the plan in plans/<feature>", or "continue the plan for <feature>". Accepts a feature name and an optional commit-mode flag: --ask-commit (default, ask after each verified task), --no-commit (never commit), or --auto-commit (commit + push after each verified task). Reads plans/<feature>/99-execution-plan.md, finds the next incomplete task, and runs the per-task loop (implement -> update the execution plan immediately -> verify -> commit per mode) following specification-first task ordering. When the repo's CLAUDE.md carries a CodeOps quality-profile block, a profile-gated quality loop reviews each executed phase (reviewer + auditor agents); critical/major findings pause for a user ruling in every commit mode.
Relentlessly interrogate a design to eliminate ambiguity before any planning, requirements, or implementation work begins. Use for "grill me", "grill_me", "disambiguate", "deep-dive", or "interview me about this". Runs a structured, branch-by-branch interview: maps the design tree of major decision branches, walks each branch surfacing options, assumptions, and sub-decisions one at a time, resolves cross-branch dependencies, and confirms explicit shared understanding. Acts as a senior architect conducting a design review — never accepts vague answers, names every decision/assumption/constraint, resolves dependencies first, and tracks the decision tree until zero ambiguity remains.
Creates a detailed, multi-document implementation plan for a software feature or task before any code is written. Use when the user wants to "make a plan", types "make_plan", or asks to "plan this feature", "create an implementation plan", "plan out this work", or "write a spec/plan" for something to be built. Drives a mandatory clarifying-questions interview, a hard Zero-Ambiguity Gate, and produces a `plans/<feature>/` document set ending in a task-by-task execution plan. For EXECUTING an existing plan, use the exec_plan skill instead.
Gather and document requirements, turn an idea into formal requirement documents (RDs). Use for "make_requirements" (full discovery: brain dump or bare idea into a structured requirements/ set), "add_requirement" (add one new RD to an existing set), and "review_requirements" (health check / gap analysis on an existing set). Trigger when the user wants to capture, expand, structure, or audit what a system must do before building it — e.g. "help me spec out my app", "document requirements", "what features am I missing", "add a feature to the requirements", "review my requirements for gaps". Acts as a proactive domain consultant: absorbs the seed idea, expands it with comparable-system features, challenges it with edge cases, then decomposes it into numbered RDs behind a hard Zero-Ambiguity Gate.
Runs a rigorous multi-dimensional quality audit of a plan, requirements, or any artifact, grounded in the actual codebase. Use for "preflight", "quality audit", "review gate", "audit this plan", "audit these requirements", or "review my plan/requirements before I build it". An adversarial review gate that hunts for every ambiguity, contradiction, gap, and risk, verifies every claim against the real code, scores findings on a 13-dimension scan, and presents each one with options and a recommendation for the user to decide — it never fixes silently. Takes an artifact target (e.g. requirements, requirements RD-03, <feature-name>, <feature-name> 03-api-design, or a file/dir path) plus optional --continue to resume an interrupted session.
Reverse-engineer an existing codebase into structured requirements. Use for "retro_requirements", "reverse requirements", "reconstruct requirements from code", "requirements archaeology", or "reverse-engineer this codebase". Trigger when the user wants to reconstruct requirements from an existing, undocumented, or legacy codebase — for documentation, migration, or a from-scratch rebuild — e.g. "document what this app does", "extract requirements from this code", "reverse-engineer this service into a spec". Analyzes any language/framework through a 9-phase archaeology pipeline and produces a reconstruction brief that feeds the make_requirements skill. Extracts WHAT the system does (not HOW), classifies every behavior by confidence (✅/⚠️/🔴), and enforces a hard Bug-or-Feature Triage Gate so bugs are never silently documented as features. Supports --scope <path> to analyze one module/package and --continue to resume an interrupted session.
Tracks features across their lifecycle in a live, per-repo roadmap — every RD, plan, and task and the lifecycle stage each is in. Layout-aware: a single plans/00-roadmap.md in flat layout, or a two-tier per-feature + portfolio roadmap under codeops/ in nested layout. Use when the user says "roadmap", "make_roadmap", "update_roadmap", "review_roadmap", "show_roadmap", "archive_roadmap", or "compact_roadmap". Covers six actions: make_roadmap (create + seed rows from disk), update_roadmap (re-infer stages, sync to disk, cascade to the portfolio), review_roadmap (read-only health check for drift/broken links), show_roadmap (read-only status overview — progress, stages, and next steps), archive_roadmap (move a completed feature to the archive), and compact_roadmap (slim a bloated roadmap: strip the legacy Notes log and trim fat cells). Detects the action from the user's phrasing or arguments and branches. The roadmap is the cross-session source of truth at the RD/plan altitude, above any single execution plan.
Sets up the CodeOps nested codeops/ layout in the current git repo — scaffolds a fresh skeleton or auto-migrates an existing flat-layout repo (requirements/ + plans/) into it. Use when the user says "setup_codeops", "/setup_codeops", "set up codeops", "initialize codeops", "migrate to the nested layout", "convert my plans/requirements to codeops/", or "scaffold the codeops structure". Detects repo state and dispatches: a marker (codeops/.codeops.yml) already present → no-op status report; a flat layout → migration (deterministic preview via scripts/codeops-migrate.sh, one confirmation, then git mv); neither → minimal fresh scaffold. Supports --dry-run (preview only) and --yes (apply without the prompt). Migration is git-mv-only, refuses a dirty tree, rejects path-traversal slugs, and is idempotent. setup_codeops is the SOLE writer of the layout marker.