codex-workflows 0.4.10 → 0.5.0

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

@@ -14,6 +14,8 @@ description: "Orchestrate full-cycle implementation across backend and frontend
 5. [LOAD IF NOT ACTIVE] `implementation-approach` -- implementation methodology
 6. [LOAD IF NOT ACTIVE] `subagents-orchestration-guide` -- agent coordination and workflow flows
 
+**Spawn rule**: every `spawn_agent` call MUST pass `fork_turns="none"` or `fork_context=false` for context isolation.
+
 ## Orchestrator Definition
 
 **Core Identity**: "I am not a worker. I am an orchestrator." (see subagents-orchestration-guide skill)
@@ -99,6 +101,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.
 
@@ -115,6 +118,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
@@ -150,9 +157,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

@@ -8,6 +8,8 @@ description: "Orchestrate the complete implementation lifecycle from requirement
 1. [LOAD IF NOT ACTIVE] `subagents-orchestration-guide` — agent coordination and workflow flows
 2. [LOAD IF NOT ACTIVE] `documentation-criteria` — document creation rules and templates
 
+**Spawn rule**: every `spawn_agent` call MUST pass `fork_turns="none"` or `fork_context=false` for context isolation.
+
 # Full-Cycle Implementation
 
 $ARGUMENTS
@@ -70,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.
 
 ---
 
@@ -88,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):
@@ -134,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

@@ -9,6 +9,8 @@ description: "Create work plan from design document with optional test skeleton
 2. [LOAD IF NOT ACTIVE] `implementation-approach` — implementation strategy
 3. [LOAD IF NOT ACTIVE] `subagents-orchestration-guide` — agent coordination and workflow flows
 
+**Spawn rule**: every `spawn_agent` call MUST pass `fork_turns="none"` or `fork_context=false` for context isolation.
+
 **Context**: Dedicated to the planning phase.
 
 ## Orchestrator Definition
@@ -43,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
 
@@ -59,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

package/.agents/skills/recipe-prepare-implementation/SKILL.md

@@ -0,0 +1,162 @@
+---
+name: recipe-prepare-implementation
+description: "Verify that an approved work plan is implementable before build execution, resolving readiness gaps through Phase 0 prep tasks when needed."
+---
+
+## Required Skills [LOAD BEFORE EXECUTION]
+
+1. [LOAD IF NOT ACTIVE] `coding-rules` -- coding standards
+2. [LOAD IF NOT ACTIVE] `testing` -- test strategy and quality gates
+3. [LOAD IF NOT ACTIVE] `ai-development-guide` -- AI development patterns
+4. [LOAD IF NOT ACTIVE] `documentation-criteria` -- document templates
+5. [LOAD IF NOT ACTIVE] `subagents-orchestration-guide` -- agent coordination
+
+**Spawn rule**: every `spawn_agent` call MUST pass `fork_turns="none"` or `fork_context=false` for context isolation.
+
+## Purpose
+
+Run this recipe after work-plan approval and before any build or implementation execution. It verifies that the plan can be executed from Phase 1 onward without missing verification references, test prerequisites, UI render surfaces, or local execution instructions.
+
+The recipe is safe to invoke unconditionally. If all readiness criteria pass, it only updates the work plan readiness marker and report.
+
+Work plan: $ARGUMENTS
+
+## Readiness Marker Contract
+
+Use the Implementation Readiness Marker Contract defined in `subagents-orchestration-guide`. If the line is absent, treat the work plan as `pending` and insert it after `Related Issue/PR:` when persisting the report.
+
+## Readiness Criteria
+
+Each criterion produces `pass`, `fail`, or `not_applicable`, with file:line evidence where possible.
+
+| ID | Criterion | Pass Evidence |
+|----|-----------|---------------|
+| R1 | Verification Strategy references resolve | Every command, file path, function, endpoint, fixture, seed, and test reference in the work plan's Verification Strategies either exists now or is the deliverable of a task in the plan |
+| R2 | E2E prerequisites are addressed | For each fixture-e2e or service-integration-e2e skeleton, every noted precondition is present in the codebase or covered by a Phase 0 task |
+| R3 | Phase 1 observability exists | The first implementation phase includes at least one operation verification method executable at task completion using existing files, prior Phase 0 deliverables, or the task's own output |
+| R4 | UI rendering surface exists | When the plan implements UI components, a fixture entry, dev route, Storybook story, preview harness, or equivalent render surface exists or is covered by a Phase 0 task |
+| R5 | Local lane procedure exists | The work plan or referenced docs record commands needed to run the relevant local service stack or browser harness, including startup commands, ports, seed steps, and required environment variables |
+
+R4 applies only to UI work. R5 applies when the plan uses a local service stack or browser harness.
+
+## Execution Flow
+
+### Step 1: Load Inputs
+
+Read the work plan passed in `$ARGUMENTS`; if absent, select the most recent non-template `docs/plans/*.md`. Extract:
+- Verification Strategies
+- Quality Assurance Mechanisms
+- Design-to-Plan Traceability
+- UI Spec Component -> Task Mapping
+- Connection Map
+- test skeleton references and E2E absence reasons
+- phase structure and task IDs
+- referenced Design Docs and UI Specs
+
+If no work plan exists, stop and report the missing prerequisite.
+
+### Step 2: Readiness Scan
+
+Evaluate R1-R5 using repository search and the work plan content. Build a `## Implementation Readiness Report` regardless of outcome.
+
+For each `fail`, identify the smallest concrete prep task that closes the gap. Examples:
+- Add fixture data for a UI state
+- Add an API mock handler for fixture-e2e
+- Add a seed script for service-integration-e2e
+- Add a Storybook story, dev route, or equivalent render surface
+- Document local startup commands and required environment variables
+- Add a missing verification helper or script referenced by the plan
+
+### Step 3: No-Op Success
+
+When all applicable criteria are `pass`:
+1. Persist `## Implementation Readiness Report` in the work plan immediately after the header block.
+2. Set `Implementation Readiness: ready`.
+3. Do not create task files.
+4. Report `outcome: ready`.
+
+### Step 4: Create Resolution Tasks
+
+When one or more criteria fail:
+1. Present the proposed prep tasks to the user and continue only after explicit approval.
+2. Create task files in `docs/plans/tasks/` using the task template:
+   - Backend prep: `{plan-name}-backend-task-prep-{NN}.md`
+   - Frontend prep: `{plan-name}-frontend-task-prep-{NN}.md`
+   - Single-layer prep: `{plan-name}-task-prep-{NN}.md`
+3. Insert the tasks into the work plan's existing Phase 0 when one exists. If no Phase 0 exists, create `Phase 0: Implementation Readiness Prep` before Phase 1. Keep existing Phase 0 task IDs stable; assign prep task IDs after existing Phase 0 tasks or use a clearly labeled `P0-PREP-N` identifier when the plan's numbering would otherwise require renumbering.
+4. Each prep task must include Investigation Targets, concrete implementation steps, and Operation Verification Methods.
+
+Layer selection:
+- Use frontend prep when every target is UI, browser harness, component, page, or frontend fixture work.
+- Use backend prep when every target is API, server, service, repository, database, seed, or backend fixture work.
+- Use single-layer prep for non-layered repositories.
+- Escalate if the gap crosses layers and cannot be split into separate prep tasks.
+
+### Step 5: Execute Prep Tasks
+
+Run each prep task through the standard 4-step cycle:
+1. Spawn the layer-appropriate task executor with the exact prep task path in the prompt: "Execute implementation-readiness prep task. Task file: [exact prep task path]."
+2. Check for `blocked` or `escalation_needed`.
+3. Spawn the layer-appropriate quality fixer with the task file as `task_file`.
+4. Commit only when the quality fixer returns `approved`.
+
+Append this scope boundary to every subagent prompt:
+
+```
+[SYSTEM CONSTRAINT]
+This agent operates within implementation-readiness prep scope. Use the task file as the primary instruction source. Do not implement feature behavior beyond the readiness gap described by the task.
+```
+
+### Step 6: Re-Scan and Persist
+
+After prep tasks are complete:
+1. Re-run the readiness scan.
+2. Persist or replace `## Implementation Readiness Report` in the work plan.
+3. Set the header to `Implementation Readiness: ready` when all applicable criteria pass, otherwise `Implementation Readiness: escalated`.
+4. Collapse completed prep tasks out of active plan execution: remove the Phase 0 readiness prep task entries from the work plan and record their committed evidence under `Resolution Tasks Executed` in the Readiness Report. If Phase 0 becomes empty and was created only by this recipe, remove that Phase 0 section. Preserve any pre-existing Phase 0 content.
+5. Delete only these files for the current `{plan-name}`:
+   - `docs/plans/tasks/{plan-name}-task-prep-*.md`
+   - `docs/plans/tasks/{plan-name}-backend-task-prep-*.md`
+   - `docs/plans/tasks/{plan-name}-frontend-task-prep-*.md`
+   - `docs/plans/tasks/{plan-name}-phase0-completion.md`
+6. Report remaining gaps if any.
+
+## Readiness Report Format
+
+```markdown
+## Implementation Readiness Report
+
+Work plan: [path]
+Outcome: ready | escalated
+Gaps resolved: [N]
+phase0_created_by_recipe: true | false
+
+### Readiness Criteria
+
+| ID | Result | Evidence |
+|----|--------|----------|
+| R1 | pass / fail / not_applicable | [file:line or missing reference] |
+| R2 | ... | ... |
+| R3 | ... | ... |
+| R4 | ... | ... |
+| R5 | ... | ... |
+
+### Resolution Tasks Executed
+- [task file path] - [one-line summary] - committed
+
+### Remaining Gaps
+- [criterion ID]: [unresolved reference] - Next action: [recommendation]
+```
+
+## Completion Criteria
+
+- [ ] Work plan loaded and relevant sections extracted
+- [ ] Readiness scan completed with evidence per criterion
+- [ ] No-op success handled when all criteria pass
+- [ ] Failing criteria converted to approved prep tasks when needed
+- [ ] Prep tasks executed through executor -> quality-fixer -> commit
+- [ ] Re-scan completed after prep tasks
+- [ ] Work plan readiness marker updated to `ready` or `escalated`
+- [ ] Readiness Report persisted in the work plan
+- [ ] Completed prep task references collapsed into the Readiness Report
+- [ ] Prep task files created by this recipe removed from `docs/plans/tasks/`

package/.agents/skills/recipe-prepare-implementation/agents/openai.yaml

@@ -0,0 +1,7 @@
+interface:
+  display_name: "recipe-prepare-implementation"
+  short_description: "Preflight work plan readiness before implementation"
+  default_prompt: "Use $recipe-prepare-implementation to verify: "
+
+policy:
+  allow_implicit_invocation: false

package/.agents/skills/recipe-reverse-engineer/SKILL.md

@@ -9,6 +9,8 @@ description: "Generate PRD and Design Docs from existing codebase through discov
 2. [LOAD IF NOT ACTIVE] `ai-development-guide` — AI development patterns
 3. [LOAD IF NOT ACTIVE] `subagents-orchestration-guide` — agent coordination and workflow flows
 
+**Spawn rule**: every `spawn_agent` call MUST pass `fork_turns="none"` or `fork_context=false` for context isolation.
+
 **Context**: Reverse engineering workflow to create documentation from existing code
 
 Target: $ARGUMENTS

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

@@ -9,6 +9,8 @@ description: "Design Doc compliance and security validation with optional auto-f
 2. [LOAD IF NOT ACTIVE] `testing` — test strategy and quality gates
 3. [LOAD IF NOT ACTIVE] `ai-development-guide` — AI development patterns
 
+**Spawn rule**: every `spawn_agent` call MUST pass `fork_turns="none"` or `fork_context=false` for context isolation.
+
 **Context**: Post-implementation quality assurance
 
 ## Orchestrator Definition
@@ -21,7 +23,8 @@ description: "Design Doc compliance and security validation with optional auto-f
 
 - Compliance validation -> Spawn code-reviewer agent
 - Security validation -> Spawn security-reviewer agent
-- Fix implementation -> Spawn task-executor agent
+- Code-side fix path -> Spawn task-executor agent
+- Design-side update path -> Spawn technical-designer in update mode, then document-reviewer, then design-sync when multiple Design Docs exist
 - Quality checks -> Spawn quality-fixer agent
 - Re-validation -> Spawn code-reviewer / security-reviewer agents
 
@@ -80,22 +83,47 @@ 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]** Present results to user for confirmation.
-**CANNOT proceed until user explicitly confirms.**
+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.
+
+**[STOP — BLOCKING]** Present results and recommended routes to user for confirmation.
+**CANNOT proceed until user explicitly confirms routes.**
 
-If both pass and user selects `n`: Skip Steps 5-10, proceed to Step 11.
+If all findings are skipped: Skip Steps 5-10, proceed to Step 11.
 
 ### Step 5: Prepare Fix Context
 
 Reference documentation-criteria skill for task file template.
 
+### Step 5d: Design-Side Update
+
+Run this step only when the user routes at least one finding to `d`.
+
+1. Spawn technical-designer agent in update mode: "Update Design Doc at [path]. The implementation is being accepted as correct for these findings: [d-routed findings with code locations and current Design Doc values]. Update the relevant sections and add change history."
+2. Spawn document-reviewer agent: "Review updated Design Doc at [path] for consistency and completeness."
+3. If multiple Design Docs exist in `docs/design/`, spawn design-sync agent: "Check cross-Design Doc consistency after updating [path]."
+4. If the user selected both `d` and `c` routes, re-evaluate the `c` findings against the updated Design Doc and drop any that are now satisfied.
+
 ### Step 6: Create Task File
 
 Create task file at `docs/plans/tasks/review-fixes-YYYYMMDD.md`
-Include both code compliance issues and security requiredFixes.
+Include only code-side compliance issues and security requiredFixes routed to `c`.
 
 ### Step 7: Execute Fixes
 
@@ -115,6 +143,8 @@ Spawn security-reviewer agent: "Re-validate security after fixes. Prior findings
 
 ### Step 11: 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-task/SKILL.md

@@ -7,6 +7,8 @@ description: "Execute tasks with metacognitive analysis and appropriate rule sel
 
 1. [LOAD IF NOT ACTIVE] `task-analyzer` — task analysis and skill selection (rule-advisor handles remaining skill selection)
 
+**Spawn rule**: every `spawn_agent` call MUST pass `fork_turns="none"` or `fork_context=false` for context isolation.
+
 # Task Execution with Metacognitive Analysis
 
 Task: $ARGUMENTS

package/.agents/skills/recipe-update-doc/SKILL.md

@@ -8,6 +8,8 @@ description: "Update existing design documents (Design Doc / PRD / ADR) with rev
 1. [LOAD IF NOT ACTIVE] `documentation-criteria` — document creation rules and templates
 2. [LOAD IF NOT ACTIVE] `subagents-orchestration-guide` — agent coordination and workflow flows
 
+**Spawn rule**: every `spawn_agent` call MUST pass `fork_turns="none"` or `fork_context=false` for context isolation.
+
 **Context**: Dedicated to updating existing design documents.
 
 ## Orchestrator Definition

package/.agents/skills/subagents-orchestration-guide/SKILL.md

@@ -5,6 +5,8 @@ description: "Guides subagent coordination through implementation workflows. Use
 
 # Subagents Orchestration Guide
 
+**Spawn rule**: every `spawn_agent` call MUST pass `fork_turns="none"` or `fork_context=false` for context isolation.
+
 ## Role: The Orchestrator
 
 The orchestrator coordinates subagents. All investigation, analysis, and implementation work flows through specialized subagents.
@@ -119,27 +121,12 @@ Close a running subagent only when the user redirects the workflow, the orchestr
 
 ## How to Spawn Agents
 
-Spawn agents using natural language prompts. Provide clear context about what the agent should accomplish.
-
-### Spawn Examples
-
-**requirement-analyzer**:
-> "Analyze the following requirements and determine the work scale: [user requirements]. Perform requirement analysis and scale determination."
-
-**codebase-analyzer**:
-> "Analyze the existing codebase to provide evidence for Design Doc creation. Focus on existing implementations, data model elements, and constraints the design should respect. requirement_analysis: [JSON]. prd_path: [path if available]. requirements: [original user requirements]. layer: [target layer if applicable]. target_paths: [paths if narrowed]. Return codebase facts and focus areas."
+Spawn agents using natural language prompts. Provide clear context about what the agent should accomplish. Every `spawn_agent` call MUST include `fork_turns="none"` or `fork_context=false` (see Spawn rule at top of this skill).
 
-**task-executor**:
-> "Execute the implementation task defined in docs/plans/tasks/[filename].md. Complete the implementation following TDD Red-Green-Refactor."
+### Spawn Prompt Requirements
 
-**quality-fixer**:
-> "Run quality checks on the codebase: static analysis, style check, all test execution. Fix any issues found and report when all checks pass."
-
-**document-reviewer**:
-> "Review the document at [path] for quality and rule compliance. Check against documentation-criteria standards."
-
-**design-sync**:
-> "Verify consistency between Design Docs in docs/design/. Use [path] as the source document for comparison."
+- Set `fork_context=false` or `fork_turns="none"` on every spawn for context isolation.
+- Each spawn prompt must name the target deliverable, input paths, and expected result. When invoking `task-executor*`, include the exact task file path, for example: `Execute the implementation task. Task file: docs/plans/tasks/[filename].md.`
 
 ## Explicit Stop Points [MANDATORY]
 
@@ -203,7 +190,34 @@ Subagents respond in JSON format. The final response from each JSON-returning su
 | `design-sync` | `sync_status` |
 | `integration-test-reviewer` | `status`, `requiredFixes` |
 | `security-reviewer` | `status`, `findings`, `notes`, `requiredFixes` |
-| `acceptance-test-generator` | `status`, `generatedFiles`, `e2eAbsenceReason` |
+| `acceptance-test-generator` | `status`, `generatedFiles.integration`, `generatedFiles.fixtureE2e`, `generatedFiles.serviceE2e`, `e2eAbsenceReason.fixtureE2e`, `e2eAbsenceReason.serviceE2e` |
+
+## Implementation Readiness Marker Contract
+
+Work plans use the header line `Implementation Readiness: <status>`.
+
+| Status | Meaning | Consumer Action |
+|--------|---------|-----------------|
+| `pending` | Initial state from work-planner; readiness has not been checked | Present the unchecked state, recommend running implementation readiness preflight, and continue only on explicit user approval |
+| `ready` | Readiness scan completed and no applicable failures remain | Proceed with task execution |
+| `escalated` | Readiness scan completed, but one or more failures remain | Read the work plan's Implementation Readiness Report, present remaining gaps, and continue only on explicit user approval |
+| absent | Older work plan without the marker | Treat as `pending` |
+
+## Implementation Readiness Preflight Procedure
+
+Use this procedure after work-plan approval and before autonomous task execution when the flow needs to verify implementation readiness.
+
+1. Load the approved work plan exact path and extract Verification Strategies, Quality Assurance Mechanisms, Design-to-Plan Traceability, UI Spec Component -> Task Mapping, Connection Map, test skeleton references, E2E absence reasons, phase structure, referenced Design Docs, and UI Specs.
+2. Evaluate these criteria with evidence:
+   - R1 Verification Strategy references resolve
+   - R2 E2E prerequisites are addressed
+   - R3 Phase 1 observability exists
+   - R4 UI rendering surface exists when UI work is present
+   - R5 Local service stack or browser harness procedure exists when applicable
+3. If every applicable criterion passes, persist `## Implementation Readiness Report` in the work plan and set `Implementation Readiness: ready`.
+4. If any criterion fails, create the smallest approved prep tasks that close the gaps, execute each exact prep task file through the standard executor -> quality-fixer -> commit cycle, then re-run the scan.
+5. After re-scan, set `Implementation Readiness: ready` when all applicable criteria pass, otherwise `Implementation Readiness: escalated`, and persist remaining gaps in the Readiness Report.
+6. Collapse completed prep task references into the Readiness Report and delete only the prep task files created for the current work plan.
 
 ## Handling Requirement Changes
 
@@ -212,17 +226,7 @@ requirement-analyzer follows the "completely self-contained" principle and proce
 
 #### How to Integrate Requirements
 
-**Important**: To maximize accuracy, integrate requirements as complete sentences, including all contextual information communicated by the user.
-
-```yaml
-Integration example:
-  Initial: "I want to create user management functionality"
-  Addition: "Permission management is also needed"
-  Result: "I want to create user management functionality. Permission management is also needed.
-
-          Initial requirement: I want to create user management functionality
-          Additional requirement: Permission management is also needed"
-```
+Integrate initial requirements and later additions as complete sentences, preserving all contextual information communicated by the user. The updated input must remain self-contained without relying on prior conversation turns.
 
 ### Update Mode for Document Generation Agents
 Document generation agents (work-planner, technical-designer, prd-creator) can update existing documents in `update` mode.
@@ -346,11 +350,11 @@ Maximum retry count is 1 verification fix cycle. If any failed verifier still fa
 | `codebase-analyzer` | `technical-designer*` | `Codebase Analysis`, including `focusAreas`, `dataModel`, `qualityAssurance`, `dataTransformationPipelines`, `limitations` |
 | `technical-designer*` | `code-verifier` | Design Doc path |
 | `code-verifier` | `document-reviewer` | `code_verification` JSON |
-| `acceptance-test-generator` | `work-planner` | integration test path, E2E path or `null`, `e2eAbsenceReason` when E2E is absent |
+| `acceptance-test-generator` | `work-planner` | `generatedFiles.integration`, `generatedFiles.fixtureE2e`, `generatedFiles.serviceE2e`, `e2eAbsenceReason: { fixtureE2e, serviceE2e }` |
 | Design Doc | `work-planner` | Verification Strategy summary, Output Comparison details, implementation-relevant technical requirements, protected no-change boundaries |
 
 Handoff rules:
-- Verify generated integration and E2E file paths exist before passing them onward
+- Verify generated integration, fixture-e2e, and service-integration-e2e file paths exist before passing them onward
 - Escalate only when required outputs are missing without a valid absence reason
 - Require work-planner to map every carried-forward technical requirement to a covering task or a justified `gap`
 

package/.agents/skills/subagents-orchestration-guide/references/monorepo-flow.md

@@ -100,7 +100,7 @@ Spawn acceptance-test-generator with all Design Docs and UI Spec:
 
 Spawn work-planner with all Design Docs:
 
-> "Create a work plan from the following documents: PRD: [path] (Large Scale only), Design Doc (backend): [path], Design Doc (frontend): [path]. Compose phases as vertical feature slices where possible -- each phase should contain both backend and frontend work for the same feature area, enabling early integration verification per phase."
+> "Create a work plan from the following documents: PRD: [path] (Large Scale only), Design Doc (backend): [path], Design Doc (frontend): [path], UI Spec: [path] (if exists). Test skeletons from acceptance-test-generator: integration: [path or null], fixtureE2e: [path or null], serviceE2e: [path or null], e2eAbsenceReason: { fixtureE2e: [value or null], serviceE2e: [value or null] }. Compose phases as vertical feature slices where possible -- each phase should contain both backend and frontend work for the same feature area, enabling early integration verification per phase. Include `Implementation Readiness: pending` in the work plan header."
 
 work-planner's existing Integration Complete criteria naturally covers cross-layer verification when given multiple Design Docs.
 

package/.agents/skills/task-analyzer/references/skills-index.yaml

@@ -4,7 +4,7 @@
 skills:
   coding-rules:
     skill: "coding-rules"
-    tags: [implementation, code-quality, refactoring, clean-code, maintainability, function-design, error-handling, parameterized-dependencies, performance, security]
+    tags: [implementation, code-quality, refactoring, clean-code, maintainability, function-design, error-handling, parameterized-dependencies, reference-representativeness, performance, security]
     typical-use: "Language-agnostic code creation, modification, and refactoring principles applicable to all programming languages"
     size: medium
     key-references:
@@ -14,23 +14,25 @@ skills:
       - "Refactoring - Martin Fowler"
       - "Single Responsibility Principle - SOLID"
     sections:
+      - "Language-Specific References"
       - "Core Philosophy [MANDATORY]"
       - "Code Quality [MANDATORY]"
       - "Function Design [MANDATORY]"
       - "Error Handling [MANDATORY]"
       - "Dependency Management"
+      - "Reference Representativeness"
       - "Performance"
       - "Code Organization"
       - "Commenting Principles"
       - "Refactoring [SAFE CHANGE PROTOCOL]"
-      - "Security (Secure Defaults, Input and Output Boundaries, Access Control, Knowledge Cutoff Supplement)"
+      - "Security"
       - "Version Control [MANDATORY]"
     references:
       - "references/typescript.md"
 
   testing:
     skill: "testing"
-    tags: [testing, tdd, quality, unit-testing, integration-testing, e2e-testing, test-design, coverage, mocking, test-independence, ci-cd, test-quality-criteria]
+    tags: [testing, tdd, quality, unit-testing, integration-testing, e2e-testing, data-layer-testing, test-design, coverage, mocking, test-independence, ci-cd, test-quality-criteria]
     typical-use: "Universal testing principles, TDD practice, test quality criteria, test creation and quality assurance for all programming languages"
     size: large
     key-references:
@@ -39,6 +41,7 @@ skills:
       - "AAA Pattern - Arrange-Act-Assert"
       - "Test Pyramid - Mike Cohn"
     sections:
+      - "Language-Specific References"
       - "Core Testing Philosophy"
       - "TDD Process [MANDATORY for all code changes]"
       - "Quality Requirements [MANDATORY]"
@@ -46,6 +49,7 @@ skills:
       - "Test Design Principles"
       - "Test Independence"
       - "Mocking and Test Doubles"
+      - "Data Layer Testing"
       - "Test Quality Practices [MANDATORY]"
       - "What to Test"
       - "Test Quality Criteria [MANDATORY]"
@@ -68,11 +72,13 @@ skills:
       - "DRY Principle - The Pragmatic Programmer"
       - "YAGNI Principle - Extreme Programming"
     sections:
+      - "Language-Specific References"
       - "Technical Anti-patterns (Red Flag Patterns) [MANDATORY]"
       - "Fail-Fast Fallback Design Principles"
       - "Rule of Three - Criteria for Code Duplication"
       - "Common Failure Patterns and Avoidance Methods"
       - "Debugging Techniques"
+      - "Quality Assurance Mechanism Awareness"
       - "Quality Check Workflow [MANDATORY]"
       - "Situations Requiring Technical Decisions"
       - "Implementation Completeness Assurance"
@@ -117,7 +123,7 @@ skills:
 
   integration-e2e-testing:
     skill: "integration-e2e-testing"
-    tags: [testing, integration-testing, e2e-testing, test-design, behavior-first, roi, test-skeleton, ears-format]
+    tags: [testing, integration-testing, e2e-testing, fixture-e2e, service-integration-e2e, e2e-absence-reason, test-design, behavior-first, roi, test-skeleton, ears-format]
     typical-use: "Integration and E2E test design principles, value-based test selection, behavior-first approach, test skeleton specification"
     size: medium
     key-references:
@@ -136,7 +142,7 @@ skills:
 
   subagents-orchestration-guide:
     skill: "subagents-orchestration-guide"
-    tags: [orchestration, workflow, subagents, autonomous-execution, planning, design-flow, implementation-flow]
+    tags: [orchestration, workflow, subagents, context-isolation, autonomous-execution, planning, design-flow, implementation-flow, implementation-readiness, readiness-gate]
     typical-use: "Orchestrating subagents through implementation workflows, scale determination, stop points, autonomous execution mode"
     size: large
     key-references:
@@ -152,6 +158,8 @@ skills:
       - "Explicit Stop Points [MANDATORY]"
       - "Scale Determination and Document Requirements"
       - "Structured Response Specification"
+      - "Implementation Readiness Marker Contract"
+      - "Implementation Readiness Preflight Procedure"
       - "Handling Requirement Changes"
       - "Basic Flow for Work Planning"
       - "Autonomous Execution Mode"

package/.agents/skills/testing/references/typescript.md

@@ -13,9 +13,8 @@ import userEvent from '@testing-library/user-event'
 ### Coverage Requirements
 
 - **Overall minimum**: 60%
-- **Atoms (Button, Text)**: 70%+
-- **Molecules (FormField)**: 65%+
-- **Organisms (Header, Footer)**: 60%+
+- **Atomic Design projects**: Atoms 70%+, Molecules 65%+, Organisms 60%+
+- **Other component architectures**: Keep 60% as the baseline and raise foundational or highly reused components to 70%+
 - **Custom Hooks**: 65%+
 - **Utils**: 70%+