casaflow

Pass the current stage gate by answering three comprehension questions. Run after each build stage completes.

Use when starting creative work — designing features, adding functionality,

Execute an implementation plan — analyzes task graph and picks parallel (team-dev) or serial (sdd) automatically.

Use when encountering any bug, test failure, or unexpected behavior, before

Use the `casaflow:eng-copywriting` skill to handle this request.

Use the `casaflow:eng-logging` skill to handle this request.

Use the `casaflow:eng-testing` skill to handle this request.

Deep technical explanation of code just written — approach, failure modes, change surface, what to test, and what to refactor.

Use when creating new skills, specialists, agents, or packs for the Jig

Use when implementation is complete, all tests pass, and you need to decide

Use when starting development work on a bug, feature, improvement, or task. Orchestrates the full pipeline: discover, brainstorm, plan, execute, review, ship.

Use when you have an approved design or requirements for a multi-step task,

Use when a PR has been merged after receiving review feedback and you want to

Use when creating a pull request. Analyzes branch changes, writes a clear

Use when reviewing PR comments, responding to code review feedback, or

Use when capturing product requirements for features, improvements, or bugs

Post-feature retrospective. Captures what surprised you, what you'd spec differently, codebase discoveries, AI collaboration lessons, and your one rule for next time.

Full four-phase test quality audit: coverage, mutation testing, rubric evaluation, and letter-grade summary.

Use when reviewing code before PRs or as quality gate during parallel execution. Dispatches parallel specialist review agents via swarm architecture.

Use when executing implementation plans with independent tasks in the current

Write a feature spec before any code is written. Guides you through feature summary, acceptance criteria, non-goals, test spec, architecture sketch, and open questions.

Use when implementing any feature or bugfix, before writing implementation

Execute implementation plans in parallel using agent teams with quality gates.

Create a ticket in your team's tracker (Linear, GitHub Issues, Jira). Interviews, writes, files, and sets up the branch.

Use when about to claim work is complete, fixed, or passing, before committing

Use when committing code. Triggered by "commit the work", "commit this", or "commit with {name}". Reads jig.config.md for conventions, respects existing hooks, supports co-author resolution.

Use when reviewing code before opening a PR. Triggered by "review my code", "review my changes", or "run the review swarm". Dispatches the review swarm and produces a confidence-scored report.

Use when posting inline code review comments on a PR. Triggered by "post review comments", "leave feedback on PR", or "post inline comments". Pairs with code-review agent (analyze) then this agent (post).

Use when starting development work on a bug, feature, improvement, or task. Guides engineers through the full development pipeline: discover, brainstorm, plan, execute, review, ship. Invoked by "let's work on", "I need to build", "fix this bug", "start a new task", or /kickoff.

Use when writing a feature spec before any code is written. Guides the developer through feature summary, acceptance criteria, non-goals, test spec, architecture sketch, and open questions. Invoked by /spec or by kickoff when no spec exists for a feature.

Use when a build stage has just completed. Enforces the CasaPerks comprehension gate — stage report plus three mandatory questions the developer must answer before the next stage begins. Invoked automatically at the end of every build stage and by /approve.

Use when the developer wants a deep technical explanation of code just written. Covers approach and tradeoffs, failure modes, change surface, what to test, and what to refactor. Can be invoked mid-stage, at a gate, or after the fact. Invoked by /explain.

Use when auditing test quality after implementation. Runs four phases: coverage audit, false positive detection via mutation testing, quality rubric evaluation, and letter-grade summary with action items. Invoked by /review-tests and automatically during Stage 4 (Polish) approve-gate.

Use when a feature has shipped and the developer wants to capture what was learned. Runs a five-question conversational retrospective and saves the output as a team artifact. Invoked by /retro and prompted automatically after finish/merge.

Use when starting creative work — designing features, adding functionality, modifying behavior, or exploring approaches. Guides collaborative design exploration through one-at-a-time questions, approach proposals, and incremental design approval. Hard gate: no code until design approved.

Use when capturing product requirements for features, improvements, or bugs before brainstorming or implementation. Triggered by "create a PRD", "capture requirements", "document requirements", "write a PRD", or /prd.

Use when you have an approved design or requirements for a multi-step task, before touching code. Turns designs into implementation plans with bite-sized TDD-oriented tasks, exact file paths, and verification steps. Save to docs/plans/.

Use when you have an implementation plan and want to execute it. Analyzes the plan's task graph, determines the best execution strategy (parallel via team-dev or serial via sdd), and orchestrates the full build with quality gates. The single entry point for plan execution — you don't need to choose between team-dev and sdd yourself.

Execute implementation plans in parallel using agent teams with quality gates. Spawns implementer teammates in split panes, orchestrated by a team lead who enforces spec compliance and code quality reviews.

Use when executing implementation plans with independent tasks in the current session. Dispatches a fresh subagent per task with two-stage review (spec compliance then code quality) after each. Serial execution for coupled tasks or when agent teams are unavailable.

Use when reviewing code before PRs or as quality gate during parallel execution. Dispatches parallel specialist review agents via the swarm architecture. Invoked by code-review agent, team-dev quality gate, or /review.

Use when creating a pull request. Analyzes branch changes, writes a clear PR description with friendly tone, and generates a structured test plan. Triggered by "create a PR", "open a pull request", or /pr-create.

Use when reviewing PR comments, responding to code review feedback, or addressing reviewer suggestions on the current branch. Triggered by "respond to PR comments", "address review feedback", or /pr-respond.

Use when a PR has been merged after receiving review feedback and you want to extract lessons learned. Analyzes reviewer comments, identifies gaps in skills and specialists, and applies fixes. Triggered by "run a postmortem", "PR retro", "lessons learned from this PR", or /postmortem.

Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes. Enforces root cause investigation through four phases: investigation, pattern analysis, hypothesis testing, and implementation. Prevents guess-and-check thrashing.

Use when about to claim work is complete, fixed, or passing, before committing or creating PRs. Requires running verification commands and confirming output before making any success claims. Evidence before assertions, always.

Use when implementing any feature or bugfix, before writing implementation code. Enforces red-green-refactor cycle where every piece of production code is preceded by a failing test. Language-agnostic TDD discipline.

Use when implementation is complete, all tests pass, and you need to decide how to integrate the work. Guides completion of development work by verifying tests, presenting structured options (merge, PR, keep, discard), executing the choice, and cleaning up worktrees.

Use when creating a ticket, filing an issue, or opening a task in your team's tracker. Triggered by "create a ticket", "file an issue", "new ticket", "open a ticket", or /casaflow:ticket. Reads ticket-system from jig.config.md and routes to the appropriate tracker pack.

Use when creating new skills, specialists, agents, or packs for the Jig framework. Guides the user through an interview to determine what to build, scaffolds the artifact with valid frontmatter, checks for overlap with existing artifacts, and verifies it loads correctly. Triggered by "create a skill", "add a specialist", "extend the framework", or /extend.

Use when writing ANY user-facing text -- UI labels, button text, error messages, notifications, tooltips, placeholders, or application content.

Use when implementing logging in application code. Covers log level selection, structured logging, error tracking integration, and avoiding noise.

Use when writing tests, designing test strategy, or reviewing test coverage. Covers test pyramid, naming, mocking, and flaky test policy.

Use when syncing a feature spec to Jira after it is saved. Handles four states — no epic/ticket, epic only, both exist, or dev opts out. Invoked automatically by the spec skill after the spec file is saved. Also invoked after stage approvals to update ticket status.