recipe-prepare-implementation

What this skill does

**Context**: Optional readiness phase between work-plan approval and recipe-*-build. Confirms the implementation will be observable from Phase 1 onward and resolves any gaps via Phase 0 tasks. Exits no-op when the readiness criteria already pass, so the recipe is safe to invoke unconditionally.

## Orchestrator Definition

**Core Identity**: "I am an orchestrator." (see subagents-orchestration-guide skill)

**Execution Protocol**:
1. **Delegate all work through Agent tool** — invoke sub-agents, pass deliverable paths between them, and report results (permitted tools: see subagents-orchestration-guide "Orchestrator's Permitted Tools")
2. **Self-contained scope**: When gaps are found, this recipe BOTH generates resolution tasks AND executes them through the standard 4-step cycle. Recipe completes only when readiness criteria pass or remaining gaps are escalated.
3. **No-op exit**: When the readiness scan finds no failing criteria, generate no resolution tasks and exit immediately, presenting the Readiness Report to the user. No files are modified in this branch.

Work plan: $ARGUMENTS

## When This Recipe Applies

Run before any recipe-*-build invocation when ANY of the following hold:
- Work plan was created from a Design Doc whose Verification Strategy references commands, files, functions, or endpoints not yet present in the codebase
- Work plan includes E2E test skeletons (seed data, auth fixture, environment variables, or external mocks may be unaddressed)
- Work plan touches UI components without a fixture entry or development route to render their visual states
- The team has not previously confirmed the local lane runs end-to-end for this feature area

When none of the above hold, the readiness scan in Step 2 will find zero failing criteria and the recipe exits no-op (see Context at the top of this skill).

## Readiness Criteria

Each criterion is a measurable check producing `pass`, `fail`, or `not_applicable` with cited evidence.

| ID | Criterion | Pass evidence |
|----|-----------|---------------|
| R1 | Verification Strategy references resolve | Every command, file path, function, endpoint, and test referenced in the work plan's Verification Strategy section either exists in the codebase (verified via Glob/Grep) or is the deliverable of a task already in this plan |
| R2 | E2E preconditions addressed | When E2E skeletons exist: every precondition mentioned in skeleton comments (seed data, auth fixture, env var, external mock) is present in the codebase or covered by a Phase 0 task in this plan |
| R3 | Phase 1 observability | The first implementation phase contains at least one task whose Operation Verification Methods can execute at task completion using only artifacts that exist before the task starts (existing code, prior Phase 0 task deliverables, or the task's own outputs) |
| R4 | UI rendering surface | When the plan implements UI components: a fixture entry, dev route, Storybook story, or equivalent rendering surface exists for the impacted components, OR a Phase 0 task adds one |
| R5 | Local lane procedure | The work plan or a referenced doc records the commands needed to start the system locally for manual verification (start commands, default ports, seed steps) |

R4 and R5 are evaluated only when their triggering signals appear in the work plan; otherwise mark `not_applicable`.

## Pre-execution Prerequisites

```bash
# Verify the work plan exists
! ls -la docs/plans/*.md | grep -v template | tail -5
```

**State check**:
- Work plan exists → Proceed to Step 1
- No work plan → Stop and report: "An approved work plan is required. Complete the upstream planning phase first, then re-invoke this recipe."

## Execution Flow

### Step 1: Load Inputs

Read the work plan path passed in `$ARGUMENTS`. Extract:
- Verification Strategy section (Correctness Proof Method + Early Verification Point)
- Quality Assurance Mechanisms table
- Design-to-Plan Traceability table
- Test skeleton references listed in the plan header
- Phase structure with each phase's tasks
- Referenced Design Doc(s) and UI Spec (when present)

### Step 2: Readiness Scan

For each criterion R1–R5:
1. Execute the scan defined in Readiness Criteria using Read / Glob / Grep
2. Record the result: `pass` / `fail` / `not_applicable`
3. Cite evidence: file:line for `pass`, the unresolved reference for `fail`, the missing trigger signal for `not_applicable`

Build the Readiness Report (see Output Format) regardless of outcome.

### Step 3: No-op Check

When every applicable criterion is `pass` (zero `fail`):
- Present the Readiness Report (see Output Format below) to the user
- Exit with `outcome: ready, gaps_resolved: 0`
- No files are modified in this branch

When one or more criteria are `fail` → proceed to Step 4.

### Step 4: Plan Resolution Tasks

For each `fail` criterion:
1. Determine the smallest concrete task that closes the gap (examples: "Add fixture entry for ComponentX covering loading/empty/error states", "Add seed script for E2E user fixtures", "Document local startup commands in docs/run/local.md")
2. Decide the task's **layer** by matching every target file path against the markers below:
   - **backend** when every target file path matches one of: `**/api/**`, `**/server/**`, `**/services/**`, `**/backend/**`, `**/handlers/**`, `**/repositories/**`
   - **frontend** when every target file path matches one of: `**/components/**`, `**/pages/**`, `**/web/**`, `**/frontend/**`, `**/*.tsx`, `**/*.jsx`
   - **mixed** (target files span both backend and frontend markers) → escalate to user; ask the user to split the gap into per-layer tasks
   - **unrecognized** (any target file matches neither backend nor frontend markers — e.g., `docs/**`, `scripts/**`, root-level configs, fixture data files outside the markers above) → escalate to user; ask the user to either (a) decide which layer's executor / quality-fixer should run the task, or (b) update the markers if the project uses different paths

   Apply the rules in the order above. The first matching rule wins; "unrecognized" is the final fallback rather than a catch-all that defaults to backend.
3. Create a Phase 0 task file at `docs/plans/tasks/{plan-name}-backend-task-prep-{NN}.md` (backend) or `docs/plans/tasks/{plan-name}-frontend-task-prep-{NN}.md` (frontend) using the task template from documentation-criteria skill. The `-task-prep-` segment lets recipe-prepare-implementation distinguish prep tasks from implementation tasks while keeping the existing `{plan-name}-{layer}-task-*` matcher used by other recipes
4. Update the work plan to insert these tasks as Phase 0 (before Phase 1)

Present the proposed resolution task list to the user with AskUserQuestion. Proceed only after explicit approval — this is the single human gate inside this recipe.

### Step 5: Execute Resolution Tasks

For each resolution task, run the standard 4-step cycle (see subagents-orchestration-guide "Task Management: 4-Step Cycle"):

1. **Agent tool** — route by filename layer segment:
   - `*-backend-task-prep-*` → `subagent_type: "dev-workflows:task-executor"`
   - `*-frontend-task-prep-*` → `subagent_type: "dev-workflows-frontend:task-executor-frontend"`
   - Filename without a recognized layer segment → escalate (the file should not exist; Step 4 prevents this)
2. Check escalation per orchestration-guide
3. **quality-fixer** — route by the same filename layer segment:
   - `*-backend-task-prep-*` → `"dev-workflows:quality-fixer"`
   - `*-frontend-task-prep-*` → `"dev-workflows-frontend:quality-fixer-frontend"`
4. **Commit** when quality-fixer returns `approved`

Append the Scope Boundary block (below) to every subagent prompt.

### Step 6: Re-scan, Present Readiness Report, Cleanup, Exit

1. **Re-scan**: Re-run the Step 2 readiness scan after all resolution tasks are committed.

2. **Present Readiness Report**: Present the Readiness Report (see Output Format below) to the user. The report is shown in-session and is not written in