blendsdk

exec_plan

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.

preflight

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.

upgrade_plan

Upgrades an outdated plan or requirements set to current CodeOps standards. Use when the user says "upgrade_plan", "upgrade_requirements", "upgrade my plan", "upgrade my requirements", "bring my plan up to date", "bring my requirements up to date", or asks for a "version upgrade" of a plan/requirements set. ONE skill covers both targets: "upgrade_plan [feature-name]" re-evaluates a plan in plans/<feature>/ against current standards, and "upgrade_requirements" re-evaluates the set in requirements/. It detects the target from the phrasing/arguments and branches. The flow is: detect version, assess gaps, present an upgrade report BEFORE changing anything, pass a non-negotiable Content Quality Gate, apply upgrades preserving all user-authored content verbatim, then verify. Does NOT auto-advance the roadmap.

grill_me

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.

make_plan

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.

make_requirements

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.

retro_requirements

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.

roadmap

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.

setup_codeops

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.

setup_routing

Configures per-project model and effort routing so Opus + high/xhigh thinking is spent only where it changes output quality and high-volume mechanical work runs on Sonnet. Use when the user says "setup_routing", "/setup_routing", "set up model routing", "configure model routing", "route tasks by model", or "make this project use Opus/Sonnet per task". Independently analyzes the repo, classifies it into a sensitivity profile (Opus-dominant, Mixed core/scaffold, Sonnet-default, or a Balanced fallback), proposes a tag-driven routing policy, waits for explicit confirmation, then writes a sentinel-delimited routing block into the project CLAUDE.md. The pinned-model executor subagents the policy references ship with the plugin (agents/); customized per-project copies in .claude/agents/ are an opt-in override.

techdocs

Creates and maintains VitePress-compatible technical architecture documentation and architecture decision records (ADRs). Use when the user says "make_techdocs", "review_techdocs", "techdocs", "document the architecture", "create architecture docs", "write ADRs", or "architecture decision records". Covers two modes: make_techdocs to create or comprehensively regenerate the docs/ set (system overview, data model, API design, infrastructure, security, ADRs, developer guides, reference), and review_techdocs to run a 7-dimension health check (staleness, completeness, accuracy, ADR coverage, link health, diagram accuracy, getting-started) and produce a diagnostic report. Also fires automatically as an incremental or comprehensive update when an exec_plan phase or plan completes, or when make_requirements completes — but only if the project has opted in. Scope is technical/architectural docs for developers, NOT product/end-user documentation.