From cape
Internal skill called by execute-plan before implementation begins. Takes a single br task and expands it into a concrete, zero-context implementation plan with exact file paths, line numbers, code changes, and verification commands. Never called directly by users — execute-plan invokes this automatically when a task lacks an expanded plan. Do NOT use for creating epics (use cape:write-plan), stress-testing edge cases (use cape:task-refinement), or executing the plan itself (use cape:execute-plan).
npx claudepluginhub sqve/cape --plugin capeThis skill uses the workspace's default tool permissions.
<skill_overview> Ground a br task in codebase reality before implementation begins. Read the task,
Guides Next.js Cache Components and Partial Prerendering (PPR) with cacheComponents enabled. Implements 'use cache', cacheLife(), cacheTag(), revalidateTag(), static/dynamic optimization, and cache debugging.
Guides building MCP servers enabling LLMs to interact with external services via tools. Covers best practices, TypeScript/Node (MCP SDK), Python (FastMCP).
Generates original PNG/PDF visual art via design philosophy manifestos for posters, graphics, and static designs on user request.
<skill_overview> Ground a br task in codebase reality before implementation begins. Read the task, investigate the actual files and patterns, and produce a step-by-step plan where every change references a real file at a real line number with a concrete verification command.
Core contract: no step references an imagined file. No step lacks a verification command. Someone picking this plan up cold can follow it without asking questions. </skill_overview>
<rigidity_level> MEDIUM FREEDOM — The investigation phase and output structure (steps with file paths, changes, verification) are non-negotiable. How deep you investigate and how granular the steps are adapts to the task's complexity. </rigidity_level>
<when_to_use>
Don't use for:
cape:write-plan)cape:task-refinement)cape:execute-plan)</when_to_use>
<critical_rules>
cape br expanded-check before doing work</critical_rules>
<the_process>
Read the task and its parent epic:
br show <task-id>
br show <epic-id>
Check whether the task already has an expanded plan:
cape br expanded-check <task-id>
If hasExpandedPlan is true, skip expansion — the task is already grounded. If the command fails
(non-zero exit), stop and surface the error — do not fall back to reading the design field manually.
Extract from the task:
Extract from the epic:
This is the step that separates a grounded plan from a speculative one. Dispatch
cape:codebase-investigator to answer the questions below. Fall back to Grep/Glob/Read if agent
dispatch isn't available.
Capture findings as you go. Every file path you reference must come from this investigation, not from the task description or your imagination.
Build a step-by-step plan where each step is exactly one TDD cycle — one behavior, one failing test,
one implementation pass. Map each behavior from the task's ## Behaviors section to its own step.
The step defines WHAT behavior to add; TDD decides HOW to test it.
Calibrate granularity to complexity:
If a task needs more than 10 steps, it should be split. Instead of producing a sprawling plan,
append a ## Split recommendation section to the task's design field listing the natural split
points and recommended subtask titles. Do not produce the expanded plan — execute-plan will handle
the split.
Each step must include:
### Step N: [What this step delivers — one testable behavior]
**Pattern:** [file:line — the existing implementation to follow]
**Changes:**
- `path/to/file.ts:L23-30` — [what to change and why]
- `path/to/new-file.ts` (new) — [what it contains, following pattern from X]
**Verify:** `[exact command to run]`
npm test -- --grep 'auth strategy' or
go test ./internal/auth/... -run TestGoogleStrategy.Do NOT include test descriptions in steps. Test design belongs to implementation-time TDD — it must emerge from the current state of the code, not from a plan written before implementation began.
Include a final verification step that runs cape check, confirming the complete change works
together.
Append the expanded plan to the task:
cat <<'EOF' | cape br design <task-id> "Expanded plan (expand-task)"
### Investigation findings
**Files to modify:**
- `path/to/file.ts` — [role in this change]
**Patterns to follow:**
- `path/to/similar.ts:L10-45` — [what it demonstrates]
**Reusable code:**
- `path/to/utils.ts:functionName()` — [what it does]
**Blast radius:**
- [Callers/importers/tests affected by this change]
### Steps
[Steps from Step 3]
### Final verification
`cape check`
EOF
Control returns to execute-plan, which follows the expanded steps using TDD.
</the_process>
Task says "add OAuth strategy following local strategy pattern" but doesn't specify filesInvestigation finds:
auth/strategies/local.ts:1-30 — existing strategy patternauth/passport-config.ts:23 — strategy registration arraytests/auth/local.test.ts — existing test patternWrong: Produce steps referencing auth/strategies/google.ts without verifying the directory
exists or checking how passport-config.ts imports strategies.
Right: Investigation confirms auth/strategies/ exists, discovers strategies are registered via
dynamic import at passport-config.ts:23-28, and finds the test helper at
tests/helpers/auth-fixture.ts:15. Steps reference all of these with real line numbers.
Wrong: Produce 10 steps with elaborate investigation. The overhead of expansion exceeds the implementation work.
Right: 2-3 steps: find all references (investigation reveals 3 files), update each reference, run tests. Quick investigation, minimal plan.
Investigation reveals the task needs more than 10 stepsWrong: Produce a 15-step plan that will exhaust context before completion.
Right: Flag to execute-plan: "This task covers too much ground for a single implementation pass. Recommend splitting into: (1) [first natural boundary], (2) [second natural boundary]." Don't produce the expanded plan — let execute-plan handle the split.
<key_principles>
</key_principles>