codex-workflows 0.4.11 → 0.6.0

package/.agents/skills/recipe-build/SKILL.md

@@ -29,8 +29,24 @@ Work plan: $ARGUMENTS
 
 ## Pre-execution Prerequisites
 
-### Task File Existence Check
-Check for work plans in docs/plans/ and task files in docs/plans/tasks/.
+### Implementation Readiness Check
+
+Before task processing, locate the work plan to gate against.
+
+Resolution rule:
+1. If `$ARGUMENTS` contains a work plan path, use that exact file and derive `{plan-name}` from its basename. This takes precedence over task-file mtimes.
+2. If `$ARGUMENTS` is empty, list task files in `docs/plans/tasks/` matching the single-layer pattern `{plan-name}-task-*.md`.
+3. Exclude `*-task-prep-*.md`, `_overview-*.md`, `*-phase*-completion.md`, `review-fixes-*.md`, and `integration-tests-*-task-*.md`.
+4. If matching task files exist, infer `{plan-name}` from the most recent matching task file and use `docs/plans/{plan-name}.md`.
+5. If no matching task files exist, use the most recent non-template work plan in `docs/plans/`.
+
+Read the work plan header and apply the Implementation Readiness Marker Contract from `subagents-orchestration-guide`.
+
+### Consumed Task Set
+
+Compute the **Consumed Task Set** for this run: task files in `docs/plans/tasks/` matching `{plan-name}-task-*.md`, excluding `*-task-prep-*.md`, `_overview-*.md`, `*-phase*-completion.md`, `review-fixes-*.md`, and `integration-tests-*-task-*.md`.
+
+Every subsequent reference to task files in this recipe uses this set, not an unrestricted `docs/plans/tasks/*.md` scan.
 
 ### Task Generation Decision Flow
 
@@ -38,8 +54,8 @@ Analyze task file existence state and determine the action required:
 
 | State | Criteria | Next Action |
 |-------|----------|-------------|
-| Tasks exist | .md files in tasks/ directory | User's execution instruction serves as batch approval -> Enter autonomous execution immediately |
-| No tasks + plan exists | Plan exists but no task files | Confirm with user -> spawn task-decomposer |
+| Tasks exist | Consumed Task Set is non-empty | User's execution instruction serves as batch approval -> Enter autonomous execution immediately |
+| No tasks + plan exists | Consumed Task Set is empty but plan exists | Confirm with user -> spawn task-decomposer |
 | Neither exists | No plan or task files | Error: Prerequisites not met |
 
 ## Task Decomposition Phase (Conditional)
@@ -58,7 +74,7 @@ Generate tasks from the work plan? (y/n):
 Spawn task-decomposer agent: "Read work plan at docs/plans/[plan-name].md and decompose into atomic tasks. Output: Individual task files in docs/plans/tasks/. Granularity: 1 task = 1 commit = independently executable."
 
 ### 3. Verify Generation
-Verify generated task files exist in docs/plans/tasks/.
+Recompute the Consumed Task Set and verify it is non-empty.
 
 ## Pre-execution Checklist
 
@@ -123,6 +139,17 @@ After all task cycles finish, collect all `filesModified` from every task-execut
    - Maximum retry count is 1 verification fix cycle; if any failed verifier still fails after re-run, escalate to the user
 5. If both verifiers pass -> Proceed to completion report
 
+## Final Cleanup
+
+Before the completion report, delete only these files for the current `{plan-name}`:
+- Every file in the Consumed Task Set
+- `docs/plans/tasks/{plan-name}-phase*-completion.md`
+- `docs/plans/tasks/_overview-{plan-name}.md`
+
+Preserve the work plan itself.
+
+If cleanup fails, report the failed path but do not invalidate completed implementation work.
+
 **[STOP — BLOCKING]** Upon detecting ANY requirement changes, halt execution immediately.
 **CANNOT proceed until user explicitly confirms the change scope.**
 

package/.agents/skills/recipe-front-adjust/SKILL.md

@@ -0,0 +1,113 @@
+---
+name: recipe-front-adjust
+description: "Adjust an implemented UI with external resource context, focused write-set confirmation, verification, and quality checks."
+---
+
+**Context**: UI adjustment for implemented frontend features. The parent session owns the edit and verification loop; subagents handle bounded fact gathering, planning, and quality checks.
+
+## Required Skills [LOAD BEFORE EXECUTION]
+
+1. [LOAD IF NOT ACTIVE] `documentation-criteria` -- scale and planning criteria
+2. [LOAD IF NOT ACTIVE] `external-resource-context` -- external resource hearing and lookup
+3. [LOAD IF NOT ACTIVE] `subagents-orchestration-guide` -- agent coordination rules
+
+**Spawn rule**: every `spawn_agent` call MUST pass `fork_turns="none"` or `fork_context=false` for context isolation.
+
+## Execution Pattern
+
+**Core Identity**: "I am a guided executor. I run the UI adjustment and verification loop in the parent session."
+
+**Execution Protocol**:
+1. Delegate bounded one-shot work to `ui-analyzer`, `work-planner`, and `quality-fixer-frontend`.
+2. Run user dialogue, write-set confirmation, edits, and verification in the parent session.
+3. Respect every `[STOP]` marker before moving to the next phase.
+
+Adjustment request: $ARGUMENTS
+
+## Execution Flow
+
+### Step 1: External Resource Hearing
+
+Run the frontend domain hearing protocol from `external-resource-context`.
+
+### Step 2: UI Fact Gathering
+
+Spawn `ui-analyzer`:
+
+`requirement_analysis: { affectedFiles: [files inferred from request], purpose: "UI adjustment", technicalConsiderations: [] }. requirements: [adjustment request]. target_paths: [paths named or inferred from request]. target_components: [components named in request]. ui_spec_path: [path if available]. Read docs/project-context/external-resources.md, resolve relevant UI sources through declared access methods, analyze existing UI code, and populate candidateWriteSet[].`
+
+### Step 3: Confirm Write Set and Scale
+
+1. Present `candidateWriteSet[]` to the user.
+2. Ask the user to confirm high-confidence entries, confirm all entries, or provide an edited file list.
+3. Apply documentation-criteria Creation Decision Matrix to the confirmed write set:
+   - `0 files`: ask the user for the component or path that owns the change, then pause this recipe.
+   - `1-2 files`: proceed with direct adjustment.
+   - `3-5 files`: create a focused work plan.
+   - `6+ files` or ADR conditions: route to the frontend design flow.
+
+### Step 4: Plan Creation When Needed
+
+For `3-5 files`, spawn `work-planner`:
+
+`Create a focused UI adjustment plan. Adjustment request: [verbatim]. ui_analysis: [ui-analyzer JSON]. External resources: docs/project-context/external-resources.md. Confirmed write set: [files]. Each phase should be implementable as 1-3 commits. Include visual verification, accessibility, i18n parity, and generated artifact checks when relevant. Output path: docs/plans/[YYYYMMDD]-adjust-[short-description].md.`
+
+**[STOP]** Present the plan and wait for approval.
+
+For `1-2 files`, present a concise adjustment context:
+- request
+- confirmed write set
+- relevant `focusAreas[]`
+- relevant external resource summaries and access methods
+
+**[STOP]** Wait for user confirmation that the context covers the work.
+
+### Step 5: Adjustment and Verification
+
+For each adjustment unit:
+1. Plan the edit from `focusAreas[]`, confirmed write set, and relevant external resource summaries.
+2. Apply the edit in the parent session.
+3. Verify against declared access methods:
+   - design origin: compare implementation target to the recorded design source
+   - visual verification: use the recorded browser, test runner, Storybook, dev server, or manual confirmation path
+   - design system: confirm tokens, variants, and usage rules through the recorded source
+4. Refine until the implemented UI matches the design source or the user-confirmed adjustment target.
+
+### Step 6: Quality Verification
+
+Spawn `quality-fixer-frontend` for each unit:
+
+- Direct adjustment: pass `filesModified: [edited files]`
+- Planned adjustment: pass `task_file: [work plan path]` and `filesModified: [edited files]`
+
+Route `quality-fixer-frontend` results:
+- `approved`: proceed to commit
+- `stub_detected`: complete the implementation gap and rerun quality verification
+- `blocked`: surface missing prerequisites or unclear specification points to the user
+
+### Step 7: Commit
+
+Commit each approved adjustment unit with affected files and relevant generated artifacts.
+
+## Completion Criteria
+
+- [ ] External resource hearing completed or update explicitly skipped
+- [ ] `ui-analyzer` returned JSON with external resource status and `candidateWriteSet`
+- [ ] User confirmed write set before scale judgment
+- [ ] Scale judgment completed with matching branch
+- [ ] Direct context or work plan approved
+- [ ] Adjustment units edited and verified through declared resource paths
+- [ ] Each unit passed `quality-fixer-frontend`
+- [ ] Each approved unit committed
+
+## Output Example
+
+```
+Frontend adjustment completed.
+- External resources: docs/project-context/external-resources.md (updated|unchanged)
+- UI analysis: [N] components, [M] focus areas
+- Scale: 1-2 files | 3-5 files
+- Work plan: path | N/A
+- Adjustment units committed: [count]
+- Quality status: approved
+```

package/.agents/skills/recipe-front-adjust/agents/openai.yaml

@@ -0,0 +1,7 @@
+interface:
+  display_name: "recipe-front-adjust"
+  short_description: "Implemented UI adjustment flow"
+  default_prompt: "Use $recipe-front-adjust to adjust an implemented UI: "
+
+policy:
+  allow_implicit_invocation: false

package/.agents/skills/recipe-front-build/SKILL.md

@@ -29,8 +29,24 @@ Work plan: $ARGUMENTS
 
 ## Pre-execution Prerequisites
 
-### Task File Existence Check
-Check for work plans in docs/plans/ and task files in docs/plans/tasks/.
+### Implementation Readiness Check
+
+Before task processing, locate the work plan to gate against.
+
+Resolution rule:
+1. If `$ARGUMENTS` contains a work plan path, use that exact file and derive `{plan-name}` from its basename. This takes precedence over task-file mtimes.
+2. If `$ARGUMENTS` is empty, list task files in `docs/plans/tasks/` matching `{plan-name}-frontend-task-*.md`.
+3. Exclude `*-task-prep-*.md`, `_overview-*.md`, `*-phase*-completion.md`, `review-fixes-*.md`, and `integration-tests-*-task-*.md`.
+4. If matching task files exist, infer `{plan-name}` from the most recent matching task file and use `docs/plans/{plan-name}.md`.
+5. If no matching task files exist, use the most recent non-template work plan in `docs/plans/`.
+
+Read the work plan header and apply the Implementation Readiness Marker Contract from `subagents-orchestration-guide`.
+
+### Consumed Task Set
+
+Compute the **Consumed Task Set** for this run: task files in `docs/plans/tasks/` matching `{plan-name}-frontend-task-*.md`, excluding `*-task-prep-*.md`, `_overview-*.md`, `*-phase*-completion.md`, `review-fixes-*.md`, and `integration-tests-*-task-*.md`.
+
+Every subsequent reference to task files in this recipe uses this set, not an unrestricted `docs/plans/tasks/*.md` scan.
 
 ### Task Generation Decision Flow
 
@@ -38,8 +54,8 @@ Analyze task file existence state and determine the action required:
 
 | State | Criteria | Next Action |
 |-------|----------|-------------|
-| Tasks exist | .md files in tasks/ directory | User's execution instruction serves as batch approval -> Enter autonomous execution immediately |
-| No tasks + plan exists | Plan exists but no task files | Confirm with user -> spawn task-decomposer |
+| Tasks exist | Consumed Task Set is non-empty | User's execution instruction serves as batch approval -> Enter autonomous execution immediately |
+| No tasks + plan exists | Consumed Task Set is empty but plan exists | Confirm with user -> spawn task-decomposer |
 | Neither exists | No plan or task files | Error: Prerequisites not met |
 
 ## Task Decomposition Phase (Conditional)
@@ -58,7 +74,7 @@ Generate tasks from the work plan? (y/n):
 Spawn task-decomposer agent: "Read work plan at docs/plans/[plan-name].md and decompose into atomic tasks. Output: Individual task files in docs/plans/tasks/. Granularity: 1 task = 1 commit = independently executable"
 
 ### 3. Verify Generation
-Verify generated task files exist in docs/plans/tasks/.
+Recompute the Consumed Task Set and verify it is non-empty.
 
 ## Pre-execution Checklist
 
@@ -131,6 +147,17 @@ After all task cycles finish, collect all `filesModified` from every task-execut
    - Maximum retry count is 1 verification fix cycle; if any failed verifier still fails after re-run, escalate to the user
 5. If both verifiers pass -> Proceed to completion report
 
+## Final Cleanup
+
+Before the completion report, delete only these files for the current `{plan-name}`:
+- Every file in the Consumed Task Set
+- `docs/plans/tasks/{plan-name}-phase*-completion.md`
+- `docs/plans/tasks/_overview-{plan-name}.md`
+
+Preserve the work plan itself.
+
+If cleanup fails, report the failed path but do not invalidate completed implementation work.
+
 **[STOP -- BLOCKING]** Upon detecting ANY requirement changes, halt execution immediately.
 **CANNOT proceed until user explicitly confirms the change scope.**
 

package/.agents/skills/recipe-front-design/SKILL.md

@@ -10,6 +10,7 @@ description: "Execute from requirement analysis to frontend design document crea
 1. [LOAD IF NOT ACTIVE] `documentation-criteria` -- document quality standards
 2. [LOAD IF NOT ACTIVE] `implementation-approach` -- implementation methodology
 3. [LOAD IF NOT ACTIVE] `subagents-orchestration-guide` -- agent coordination and workflow flows
+4. [LOAD IF NOT ACTIVE] `external-resource-context` -- external resource hearing and lookup
 
 **Spawn rule**: every `spawn_agent` call MUST pass `fork_turns="none"` or `fork_context=false` for context isolation.
 
@@ -19,7 +20,7 @@ description: "Execute from requirement analysis to frontend design document crea
 
 **Execution Method**:
 - Requirement analysis -> performed by requirement-analyzer
-- Codebase analysis -> performed by codebase-analyzer
+- Codebase analysis -> performed by codebase-analyzer and ui-analyzer
 - UI Specification creation -> performed by ui-spec-designer
 - Design document creation -> performed by technical-designer-frontend
 - Design verification -> performed by code-verifier
@@ -31,6 +32,8 @@ Orchestrator spawns agents and passes structured data between them.
 
 **Included in this skill**:
 - Requirement analysis with requirement-analyzer
+- External resource hearing with external-resource-context
+- UI fact gathering with ui-analyzer alongside codebase-analyzer
 - UI Specification creation with ui-spec-designer (prototype code inquiry included)
 - ADR creation (if architecture changes, new technology, or data flow changes)
 - Design Doc creation with technical-designer-frontend
@@ -54,26 +57,41 @@ Once requirements are moderately clarified:
 **[STOP -- BLOCKING]** Review requirement analysis results and address question items.
 **CANNOT proceed until user explicitly confirms the requirement analysis.**
 
-### Step 2: UI Specification Phase
-After requirement analysis approval, ask the user about prototype code:
+### Step 2: External Resource Hearing
+After requirement analysis approval, run the frontend domain hearing protocol from `external-resource-context`.
+
+Persist project-level access methods in `docs/project-context/external-resources.md`. When the file already exists, ask whether to keep current axes, refresh all axes, or refresh selected axes.
+
+**[STOP -- BLOCKING]** Complete external resource hearing before UI fact gathering.
+Proceed to UI fact gathering after project-level external resources are written or the update is explicitly skipped.
+
+### Step 3: Prototype Inquiry
+After external resource hearing completes, ask the user about prototype code:
 
 **Ask the user**: "Do you have prototype code for this feature? If so, please provide the path to the code. The prototype will be placed in `docs/ui-spec/assets/` as reference material for the UI Spec."
 
 **[STOP -- BLOCKING]** Wait for user response about prototype code availability.
 **CANNOT proceed until user responds.**
 
-Then create the UI Specification:
-- Spawn ui-spec-designer agent: "Create UI Spec [from PRD at [path] if PRD exists]. [Prototype code is at [user-provided path]. Place prototype in docs/ui-spec/assets/{feature-name}/ | No prototype code available.]"
+### Step 4: UI Fact Gathering Phase
+After prototype inquiry completes, use the prototype path as an input when one was provided.
+
+Spawn codebase-analyzer and ui-analyzer in parallel:
+- Spawn codebase-analyzer agent: "Analyze the existing codebase to provide evidence for frontend Design Doc creation. Focus on existing implementations, state paths, API integrations, and constraints the design should respect. requirement_analysis: [JSON from requirement-analyzer]. requirements: [original user requirements]. layer: frontend. target_paths: [frontend affected files and directories from requirement-analyzer]. focus_areas: component hierarchy, state management, UI interactions, data fetching."
+- Spawn ui-analyzer agent: "Gather UI facts for frontend design. requirement_analysis: [JSON from requirement-analyzer]. requirements: [original user requirements]. target_paths: [frontend affected files and directories from requirement-analyzer]. target_components: [frontend target components when known]. ui_spec_path: [path if an existing UI Spec covers this feature]. prototype_path: [path if provided]. Read docs/project-context/external-resources.md, resolve relevant UI external resources through declared access methods, and analyze component structure, props patterns, CSS layout, state displays, accessibility, generated artifacts, and candidate write set."
+
+### Step 5: UI Specification Phase
+After UI fact gathering completes, create the UI Specification:
+- Spawn ui-spec-designer agent: "Create UI Spec [from PRD at [path] if PRD exists]. UI analysis: [JSON from ui-analyzer]. [Prototype code is at [user-provided path]. Place prototype in docs/ui-spec/assets/{feature-name}/ | Prototype path unavailable; proceed from PRD/requirements and UI analysis.] Fill External Resources Used from docs/project-context/external-resources.md and feature identifiers."
 - Spawn document-reviewer agent: "doc_type: UISpec target: [ui-spec path] Review for consistency and completeness"
 
 **[STOP -- BLOCKING]** Present UI Spec for user approval.
 **CANNOT proceed until user explicitly approves the UI Spec.**
 
-### Step 3: Design Document Creation Phase
+### Step 6: Design Document Creation Phase
 Create appropriate design documents according to scale determination:
 - For ADR: Spawn technical-designer-frontend agent: "Create ADR for [technical decision]"
-- For Design Doc: Spawn codebase-analyzer agent first: "Analyze the existing codebase to provide evidence for frontend Design Doc creation. Focus on existing implementations, state paths, API integrations, and constraints the design should respect. requirement_analysis: [JSON from requirement-analyzer]. requirements: [original user requirements]. layer: frontend. target_paths: [frontend affected files and directories from requirement-analyzer]. focus_areas: component hierarchy, state management, UI interactions, data fetching."
-- For Design Doc: Spawn technical-designer-frontend agent: "Create Design Doc based on requirements. Codebase Analysis: [JSON from codebase-analyzer]. UI Spec is at [ui-spec path]. Inherit component structure and state design from UI Spec."
+- For Design Doc: Spawn technical-designer-frontend agent: "Create Design Doc based on requirements. Codebase Analysis: [JSON from codebase-analyzer]. UI Analysis: [JSON from ui-analyzer]. UI Spec is at [ui-spec path]. Inherit component structure and state design from UI Spec. Fill External Resources Used from docs/project-context/external-resources.md and feature identifiers."
 - Spawn code-verifier agent: "Verify Design Doc against code. doc_type: design-doc. document_path: [document path]. verbose: false."
 - Spawn document-reviewer agent: "Review the Design Doc for consistency and completeness. doc_type: DesignDoc. target: [document path]. mode: composite. code_verification: [JSON from code-verifier]"
 
@@ -85,8 +103,9 @@ ENFORCEMENT: Every stop point MUST be respected. Skipping user approval invalida
 ## Completion Criteria
 
 - [ ] Requirement analysis completed and approved
+- [ ] External resource hearing completed
+- [ ] Codebase analysis and UI analysis completed before document creation
 - [ ] UI Specification created and approved
-- [ ] Codebase analysis completed before frontend Design Doc creation
 - [ ] Design document created and approved
 - [ ] All document reviews passed
 

package/.agents/skills/recipe-front-plan/SKILL.md

@@ -48,7 +48,7 @@ Check for existence of design documents in docs/design/.
 Spawn acceptance-test-generator agent: "Generate test skeletons from Design Doc at [path]. [UI Spec at [ui-spec path] if exists.]"
 
 ### Step 3: Work Plan Creation
-Spawn work-planner agent: "Create work plan from Design Doc at [path]. Integration test file: [path from step 2]. E2E test file: [path from step 2 or null]. E2E absence reason: [value from step 2 when E2E file is null]. Integration tests are created simultaneously with each phase implementation, E2E tests are executed only in final phase when an E2E file exists."
+Spawn work-planner agent: "Create work plan from Design Doc at [path]. Integration test file: [path from step 2]. fixture-e2e test file: [path from step 2 or null]. service-integration-e2e test file: [path from step 2 or null]. E2E absence reasons by lane: [values from step 2 when an E2E lane is null]. Integration tests are created with each phase implementation, fixture-e2e runs alongside UI implementation, service-integration-e2e runs only in the final phase when a service E2E file exists. Include `Implementation Readiness: pending` in the work plan header."
 
 **[STOP -- BLOCKING]** Interact with user to complete plan and obtain approval for plan content. Clarify specific implementation steps and risks.
 **CANNOT proceed until user explicitly approves the work plan.**

package/.agents/skills/recipe-front-review/SKILL.md

@@ -18,7 +18,8 @@ description: "Frontend Design Doc compliance and security validation with option
 - Compliance validation -> performed by code-reviewer
 - Security validation -> performed by security-reviewer
 - Rule analysis -> performed by rule-advisor
-- Fix implementation -> performed by task-executor-frontend
+- Code-side fix path -> performed by task-executor-frontend
+- Design-side update path -> performed by technical-designer-frontend in update mode, then document-reviewer, then design-sync when multiple Design Docs exist
 - Quality checks -> performed by quality-fixer-frontend
 - Re-validation -> performed by code-reviewer / security-reviewer
 
@@ -80,28 +81,45 @@ Security Review: [status from security-reviewer]
   - [policy] [location]: [description] — [rationale]
   Notes: [notes from security-reviewer, if present]
 
-Execute fixes? (y/n):
+Resolve discrepancies by route:
+  c) Code-side fix
+  d) Design-side update
+  s) Skip
+
+Default: accept all recommended routes.
+
+Accepted response formats:
+- empty input -- accept every recommended route
+- `all-recommended` -- accept every recommended route
+- `all:c`, `all:d`, or `all:s` -- apply one route to every finding
+- Per-finding routes, e.g. `F1:c, F2:d, F3:s`
 ```
 
-**[STOP -- BLOCKING]** Wait for user response on whether to execute fixes.
-**CANNOT proceed with auto-fixes without user approval.**
+Before presenting results, recommend a route for each finding:
+- Use `d` when implementation intent matches the requirement but the Design Doc is stale or too narrow.
+- Use `c` when code drifted from a still-correct Design Doc, or when the finding is reliability, security, or maintainability related.
+- Use `s` only when the user explicitly accepts the current state without changes.
 
-If both pass and user selects `n`: Skip fix steps, proceed to Final Report.
+**[STOP -- BLOCKING]** Wait for user response on routes.
+**CANNOT proceed with fixes or document updates without user approval.**
 
-If user selects `y`:
+If all findings are skipped: Skip fix steps, proceed to Final Report.
 
 ## Pre-fix Metacognition
 
 1. **Spawn rule-advisor agent**: "Analyze fixes needed. Code issues: $STEP_2_OUTPUT. Security findings: $STEP_3_OUTPUT. Determine root solutions vs symptomatic treatments."
-2. **Register tasks**: Register work steps. Always include: first "Confirm skill constraints", final "Verify skill fidelity". Create task file -> `docs/plans/tasks/review-fixes-YYYYMMDD.md`. Include both code compliance issues and security requiredFixes.
-3. **Spawn task-executor-frontend agent**: "Execute staged auto-fixes for [task-file-path]. Stop at 5 files."
-4. **Spawn quality-fixer-frontend agent**: "Execute all frontend quality checks and confirm quality gate passage"
-5. **Re-validate code-reviewer**: Spawn code-reviewer agent: "Re-validate compliance for [design-doc-path]. Prior issues: $STEP_2_OUTPUT. Measure improvement."
-6. **Re-validate security-reviewer** (only if security fixes were applied): Spawn security-reviewer agent: "Re-validate security after fixes. Prior findings: $STEP_3_OUTPUT. Design Doc: [path]. Implementation files: [union of $STEP_1_FILES and task-executor-frontend filesModified from step 3, deduplicated]."
+2. **Design-side update**: If any finding is routed to `d`, spawn technical-designer-frontend in update mode, then document-reviewer, then design-sync when multiple Design Docs exist. If both `d` and `c` routes exist, re-evaluate `c` findings against the updated Design Doc and drop any now satisfied.
+3. **Register tasks**: Register work steps. Always include: first "Confirm skill constraints", final "Verify skill fidelity". Create task file -> `docs/plans/tasks/review-fixes-YYYYMMDD.md`. Include only code compliance issues and security requiredFixes routed to `c`.
+4. **Spawn task-executor-frontend agent**: "Execute staged auto-fixes for [task-file-path]. Stop at 5 files."
+5. **Spawn quality-fixer-frontend agent**: "Execute all frontend quality checks and confirm quality gate passage"
+6. **Re-validate code-reviewer**: Spawn code-reviewer agent: "Re-validate compliance for [design-doc-path]. Prior issues: $STEP_2_OUTPUT. Measure improvement."
+7. **Re-validate security-reviewer** (only if security fixes were applied): Spawn security-reviewer agent: "Re-validate security after fixes. Prior findings: $STEP_3_OUTPUT. Design Doc: [path]. Implementation files: [union of $STEP_1_FILES and task-executor-frontend filesModified from step 4, deduplicated]."
 
 ENFORCEMENT: Auto-fixes MUST go through quality-fixer-frontend before re-validation. Skipping quality checks invalidates fixes.
 
 ### Final Report
+Delete the review-fix task file this recipe created, if present. Its work is committed; `docs/plans/` is ephemeral working state.
+
 ```
 Code Compliance:
   Initial: [X]%

package/.agents/skills/recipe-fullstack-build/SKILL.md

@@ -39,8 +39,24 @@ Work plan: $ARGUMENTS
 
 ## Pre-execution Prerequisites
 
-### Task File Existence Check
-Check for work plans in docs/plans/ and task files in docs/plans/tasks/.
+### Implementation Readiness Check
+
+Before task processing, locate the work plan to gate against.
+
+Resolution rule:
+1. If `$ARGUMENTS` contains a work plan path, use that exact file and derive `{plan-name}` from its basename. This takes precedence over task-file mtimes.
+2. If `$ARGUMENTS` is empty, list task files in `docs/plans/tasks/` matching `{plan-name}-backend-task-*.md` or `{plan-name}-frontend-task-*.md`.
+3. Exclude `*-task-prep-*.md`, `_overview-*.md`, `*-phase*-completion.md`, `review-fixes-*.md`, and `integration-tests-*-task-*.md`.
+4. If matching task files exist, infer `{plan-name}` from the most recent matching task file and use `docs/plans/{plan-name}.md`.
+5. If no matching task files exist, use the most recent non-template work plan in `docs/plans/`.
+
+Read the work plan header and apply the Implementation Readiness Marker Contract from `subagents-orchestration-guide`.
+
+### Consumed Task Set
+
+Compute the **Consumed Task Set** for this run: task files in `docs/plans/tasks/` matching `{plan-name}-backend-task-*.md` or `{plan-name}-frontend-task-*.md`, excluding `*-task-prep-*.md`, `_overview-*.md`, `*-phase*-completion.md`, `review-fixes-*.md`, and `integration-tests-*-task-*.md`.
+
+Every subsequent reference to task files in this recipe uses this set, not an unrestricted `docs/plans/tasks/*.md` scan.
 
 ### Task Generation Decision Flow
 
@@ -48,8 +64,8 @@ Analyze task file existence state and determine the action required:
 
 | State | Criteria | Next Action |
 |-------|----------|-------------|
-| Tasks exist | .md files in tasks/ directory | User's execution instruction serves as batch approval -> Enter autonomous execution immediately |
-| No tasks + plan exists | Plan exists but no task files | Confirm with user -> spawn task-decomposer |
+| Tasks exist | Consumed Task Set is non-empty | User's execution instruction serves as batch approval -> Enter autonomous execution immediately |
+| No tasks + plan exists | Consumed Task Set is empty but plan exists | Confirm with user -> spawn task-decomposer |
 | Neither exists | No plan or task files | Error: Prerequisites not met |
 
 ## Task Decomposition Phase (Conditional)
@@ -68,7 +84,7 @@ Generate tasks from the work plan? (y/n):
 Spawn task-decomposer agent: "Read work plan at docs/plans/[plan-name].md and decompose into atomic tasks. Output: Individual task files in docs/plans/tasks/. Granularity: 1 task = 1 commit = independently executable. Use layer-aware naming: {plan}-backend-task-{n}.md, {plan}-frontend-task-{n}.md based on target file paths."
 
 ### 3. Verify Generation
-Verify generated task files exist in docs/plans/tasks/.
+Recompute the Consumed Task Set and verify it is non-empty.
 
 ## Pre-execution Checklist
 
@@ -141,6 +157,17 @@ After all task cycles finish, collect all `filesModified` from every task-execut
    - Maximum retry count is 1 verification fix cycle; if any failed verifier still fails after re-run, escalate to the user
 5. If all verifiers pass -> Proceed to completion report
 
+## Final Cleanup
+
+Before the completion report, delete only these files for the current `{plan-name}`:
+- Every file in the Consumed Task Set
+- `docs/plans/tasks/{plan-name}-phase*-completion.md`
+- `docs/plans/tasks/_overview-{plan-name}.md`
+
+Preserve the work plan itself.
+
+If cleanup fails, report the failed path but do not invalidate completed implementation work.
+
 **[STOP -- BLOCKING]** Upon detecting ANY requirement changes, halt execution immediately.
 **CANNOT proceed until user explicitly confirms the change scope.**
 

package/.agents/skills/recipe-fullstack-implement/SKILL.md

@@ -13,6 +13,7 @@ description: "Orchestrate full-cycle implementation across backend and frontend
 4. [LOAD IF NOT ACTIVE] `documentation-criteria` -- document quality standards
 5. [LOAD IF NOT ACTIVE] `implementation-approach` -- implementation methodology
 6. [LOAD IF NOT ACTIVE] `subagents-orchestration-guide` -- agent coordination and workflow flows
+7. [LOAD IF NOT ACTIVE] `external-resource-context` -- external resource hearing and lookup
 
 **Spawn rule**: every `spawn_agent` call MUST pass `fork_turns="none"` or `fork_context=false` for context isolation.
 
@@ -29,7 +30,7 @@ ENFORCEMENT: Proceeding without reading monorepo-flow.md invalidates the entire
 ## Execution Protocol
 
 1. **Spawn agents for all work** -- your role is to invoke sub-agents, pass data between them, and report results
-2. **Follow monorepo-flow.md** for the design phase (multiple Design Docs, design-sync, vertical slicing)
+2. **Follow monorepo-flow.md** for the design phase (external resource hearing at design entry, multiple Design Docs, design-sync, vertical slicing)
 3. **Follow subagents-orchestration-guide skill** for all other orchestration rules (stop points, structured responses, escalation)
 4. **Enter autonomous mode** only after "batch approval for entire implementation phase"
 
@@ -59,6 +60,7 @@ When continuing existing flow, verify:
 ### 3. Execute monorepo-flow.md
 
 **Follow monorepo-flow.md step-by-step** for the complete flow from UI Spec through Design Docs through Work Plan. The flow includes:
+- External resource hearing at the design phase entry
 - UI Spec creation (with prototype inquiry)
 - Separate Design Docs per layer (technical-designer for backend, technical-designer-frontend for frontend)
 - **Backend Design Doc**: Spawn technical-designer agent
@@ -89,6 +91,7 @@ When user responds to questions:
 **Pre-execution Checklist (MANDATORY)**:
 - [ ] Read monorepo-flow.md reference
 - [ ] Confirmed relevant flow steps
+- [ ] External resource hearing included when entering design flow
 - [ ] Identified current progress position
 - [ ] Clarified next step
 - [ ] Recognized stopping points
@@ -101,6 +104,7 @@ When user responds to questions:
 **Required Flow Compliance**:
 - Run quality-fixer (layer-appropriate) before every commit
 - Obtain user approval before Edit/Write outside autonomous mode
+- Run implementation readiness preflight for the approved work plan before autonomous implementation, or continue without it only after explicit user approval
 
 ENFORCEMENT: Commits without quality-fixer approval are invalid and MUST be reverted.
 
@@ -117,6 +121,10 @@ ENFORCEMENT: Sub-agent prompts missing the constraint suffix MUST be re-issued w
 
 ## Task Execution Quality Cycle (Filename-Pattern-Based)
 
+### Implementation Readiness Gate
+
+Before executing task files, execute the Implementation Readiness Preflight Procedure from `subagents-orchestration-guide` for the approved work plan exact path. This means loading the work plan, evaluating R1-R5, resolving approved prep gaps through exact prep task files when needed, persisting the Readiness Report, and setting `Implementation Readiness: ready` or `escalated`. Then apply the Implementation Readiness Marker Contract before entering autonomous execution.
+
 **Agent routing by task filename** (see monorepo-flow.md reference):
 ```
 *-backend-task-*   -> task-executor + quality-fixer
@@ -152,9 +160,10 @@ After all task cycles finish, collect all `filesModified` from every task-execut
 ### Test Information Communication
 After acceptance-test-generator execution, when calling work-planner, communicate:
 - Generated integration test file path
-- Generated E2E test file path or `null`
-- E2E absence reason when no E2E file is generated
-- Explicit note that integration tests are created simultaneously with implementation, E2E tests are executed after all implementations only when an E2E file exists
+- Generated fixture-e2e test file path or `null`
+- Generated service-integration-e2e test file path or `null`
+- E2E absence reason per lane when no E2E file is generated
+- Explicit note that integration tests are created simultaneously with implementation, fixture-e2e runs alongside UI implementation, and service-integration-e2e executes after all implementations only when a service E2E file exists
 
 **[STOP -- BLOCKING]** Upon detecting ANY requirement changes, halt execution immediately.
 **CANNOT proceed until user explicitly confirms the change scope.**

package/.agents/skills/recipe-implement/SKILL.md

@@ -72,7 +72,10 @@ Follow subagents-orchestration-guide skill Large/Medium/Small scale flow exactly
 **STEP 4**: Spawn acceptance-test-generator agent → spawn work-planner agent.
 **[STOP — BLOCKING]** Present Work Plan for user approval. **CANNOT proceed until user explicitly confirms.**
 
-**STEP 5**: Enter guided autonomous execution (see Autonomous Execution Mode below) using task-executor-frontend + quality-fixer-frontend agents.
+**STEP 5**: Run implementation readiness preflight.
+Execute the Implementation Readiness Preflight Procedure from `subagents-orchestration-guide` for the approved work plan exact path. This means loading the work plan, evaluating R1-R5, resolving approved prep gaps through exact prep task files when needed, persisting the Readiness Report, and setting `Implementation Readiness: ready` or `escalated`. Apply the Implementation Readiness Marker Contract before entering autonomous execution.
+
+**STEP 6**: Enter guided autonomous execution (see Autonomous Execution Mode below) using task-executor-frontend + quality-fixer-frontend agents.
 
 ---
 
@@ -90,6 +93,10 @@ Follow subagents-orchestration-guide `references/monorepo-flow.md` for the compl
 
 After user grants "batch approval for entire implementation phase", enter autonomous execution.
 
+### Implementation Readiness Gate
+
+Before executing task files, read the associated work plan header and apply the Implementation Readiness Marker Contract from `subagents-orchestration-guide`.
+
 ### Task Execution Quality Cycle (4-Step Cycle per Task)
 
 **Agent routing by task filename** (for fullstack projects):
@@ -136,9 +143,10 @@ After all task cycles finish, collect all `filesModified` from every executor re
 ### Test Information Communication
 After acceptance-test-generator execution, when spawning work-planner, communicate:
 - Generated integration test file path
-- Generated E2E test file path or `null`
-- E2E absence reason when no E2E file is generated
-- Note: integration tests are created with implementation; E2E tests run after all implementations when an E2E file exists
+- Generated fixture-e2e test file path or `null`
+- Generated service-integration-e2e test file path or `null`
+- E2E absence reason per lane when no E2E file is generated
+- Note: integration tests are created with implementation; fixture-e2e runs alongside UI implementation; service-integration-e2e runs after all implementations when a service E2E file exists
 
 ## Completion Criteria
 

package/.agents/skills/recipe-plan/SKILL.md

@@ -45,14 +45,14 @@ Follow the planning process below:
 Check for existence of design documents in docs/design/, notify user if none exist.
 Present options if multiple exist (can be specified with $ARGUMENTS).
 
-### Step 2: E2E Test Skeleton Generation Confirmation
-- Confirm with user whether to generate E2E test skeleton first
+### Step 2: Integration/E2E Test Skeleton Generation Confirmation
+- Confirm with user whether to generate integration and E2E test skeletons first
 - If user wants generation: Spawn acceptance-test-generator agent: "Generate test skeletons from Design Doc at [design-doc-path]"
 - Pass generation results to next process according to subagents-orchestration-guide skill coordination specification
-- If no E2E file is generated, carry the explicit `e2eAbsenceReason` forward as a valid planning input
+- If no E2E file is generated for a lane, carry the explicit lane-specific `e2eAbsenceReason` forward as a valid planning input
 
 ### Step 3: Work Plan Creation
-- Spawn work-planner agent: "Create work plan from design document at [design-doc-path]. Include deliverables from previous process according to subagents-orchestration-guide skill coordination specification. If `generatedFiles.e2e` is null, use `e2eAbsenceReason` and accept the null E2E file as a valid planning input."
+- Spawn work-planner agent: "Create work plan from design document at [design-doc-path]. Include deliverables from previous process according to subagents-orchestration-guide skill coordination specification. If `generatedFiles.fixtureE2e` or `generatedFiles.serviceE2e` is null, use the corresponding `e2eAbsenceReason` and accept the null E2E lane as a valid planning input. Include `Implementation Readiness: pending` in the work plan header."
 - Interact with user to complete plan and obtain approval for plan content
 - Clarify specific implementation steps and risks
 
@@ -61,7 +61,7 @@ Present options if multiple exist (can be specified with $ARGUMENTS).
 ## Completion Criteria
 
 - [ ] Design document identified and selected
-- [ ] E2E test skeleton generation confirmed with user (generated if requested)
+- [ ] Integration/E2E test skeleton generation confirmed with user (generated if requested)
 - [ ] Work plan created via work-planner
 - [ ] Plan content approved by user
 - [ ] All stopping points honored with user confirmation