recipe-prepare-implementation

Execute Skill: llm-friendly-context before writing Agent prompts, handoffs, or generated artifacts.

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.

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

Pre-execution Prerequisites

# 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 Readines