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.
From casaflownpx claudepluginhub casaperks/casaflow --plugin casaflowThis skill uses the workspace's default tool permissions.
Designs and optimizes AI agent action spaces, tool definitions, observation formats, error recovery, and context for higher task completion rates.
Enables AI agents to execute x402 payments with per-task budgets, spending controls, and non-custodial wallets via MCP tools. Use when agents pay for APIs, services, or other agents.
Compares coding agents like Claude Code and Aider on custom YAML-defined codebase tasks using git worktrees, measuring pass rate, cost, time, and consistency.
This skill governs what happens at the end of every build stage. The gate exists to keep the developer in comprehension of the codebase as it grows. Claude pauses here and does not continue until both parts are complete.
The gate has two parts:
Both are required. The gate cannot be skipped. This discomfort is the learning mechanism — if a developer can't answer these questions, the next stage will be harder to debug.
/casaflow:build stage/casaflow:approveBefore asking any questions, Claude produces the following report:
An exact list of every file created or modified. For each file:
Step-by-step commands to start the app and exercise what was just built. Not "run the app and test it" — specific commands, specific URLs, specific interactions to perform. Number every step.
A checklist derived from the feature spec acceptance criteria:
- [ ] [user action] → [expected result]
- [ ] [user action] → [expected result]
An honest list of deferred items with brief reasons. This prevents the developer from assuming the current stage is more complete than it is.
For every significant implementation decision in this stage:
This section is not optional. If no significant decisions were made, say "No significant tradeoffs in this stage." But that is rare.
After the stage report, Claude asks exactly three questions.
Question 1 — Structural
"Walk me through what happens when [key interaction from this stage]. Start from the user action and trace it to the data layer."
Question 2 — Failure mode
"What happens in the code if [a realistic failure condition for this stage]? Where would you look to debug it?"
Question 3 — Change impact
"If we needed to change [a specific thing Claude just built], what other files would you need to touch and why?"
Claude chooses questions that are specific to what was built in this stage. Generic questions that could apply to any stage are not acceptable.
Acceptable: Answer traces the correct code path, names the right files, identifies the right failure point, or correctly maps the change surface. Minor gaps are fine if the core understanding is there.
Not acceptable: Vague answers ("it would just error"), circular definitions ("it would fail because it fails"), or responses that reveal the developer hasn't read the code that was just written.
If an answer is not acceptable:
If the developer runs /approve without answering the comprehension
questions, respond:
"Before I continue, I need you to answer the three comprehension questions above. This isn't a formality — if you can't answer these, we'll hit problems in the next stage that are harder to debug."
Pass → Confirm stage complete. Open the next stage with:
Redirect → Developer specifies a change. Claude adjusts scope or approach. Small changes (a different variable name, a different endpoint path) do not require re-running comprehension questions. Large redirects (architecture changes, new data flows, additional acceptance criteria) require re-running all three questions.
Pause → Developer needs time. Claude summarizes:
Teams override these in casaflow.config.md. These are the defaults:
| Stage | Scope |
|---|---|
| 1 — Scaffold | Project structure, dependencies, config, CI skeleton |
| 2 — Backend | API endpoints, data layer, auth, validation, security |
| 3 — Frontend | UI components, API integration, error handling, UX |
| 4 — Polish | Tests, docs, edge cases, performance, accessibility |
For large features, Claude may propose splitting a stage. This should happen at plan time, not mid-stage.
Stage 4 (Polish) special behavior: Before the comprehension questions,
invoke review-tests for the four-phase test audit. Passing the gate
requires both the test review and the comprehension questions.