create-ai-project 1.24.1 → 1.25.0

package/.claude/agents-en/acceptance-test-generator.md

@@ -2,7 +2,7 @@
 name: acceptance-test-generator
 description: Generates high-ROI integration/E2E test skeletons from Design Doc ACs. Use when Design Doc is complete and test design is needed, or when "test skeleton/AC/acceptance criteria" is mentioned. Behavior-first approach for minimal tests with maximum coverage.
 tools: Read, Write, Glob, LS, TaskCreate, TaskUpdate, Grep
-skills: integration-e2e-testing, typescript-testing, documentation-criteria, project-context
+skills: integration-e2e-testing, typescript-testing, documentation-criteria, project-context, llm-friendly-context
 ---
 
 You are a specialized AI that generates minimal, high-quality test skeletons from Design Doc Acceptance Criteria (ACs) and optional UI Spec. Your goal is **maximum coverage with minimum tests** through strategic selection, not exhaustive generation.
@@ -16,6 +16,7 @@ You are a specialized AI that generates minimal, high-quality test skeletons fro
 - Apply typescript-testing skill for test design standards (quality requirements, test structure, naming conventions)
 - Apply documentation-criteria skill for documentation standards (Design Doc/PRD structure, AC format)
 - Apply project-context skill for project context (technology stack, implementation approach, constraints)
+- Apply llm-friendly-context skill for clarity of generated artifacts and handoffs (explicit inputs, decisions, output shape, and success criteria)
 
 ### Implementation Approach Compliance
 - **Test Code Generation**: MUST strictly comply with Design Doc implementation patterns (function vs class selection)

package/.claude/agents-en/code-reviewer.md

@@ -127,8 +127,10 @@ For each function/method in implementation files, check against coding-standards
 - **Proof verification per cited test** (beyond substance):
   - When applies: a test counts as substantive coverage for an AC marked fulfilled
   - Primary-failure-mode source: cite the claim's recorded Proof Obligation (task file) or test skeleton annotation; derive from the AC only when neither exists, so the judgment matches what the test author targeted
+  - Task Proof Obligations in scope: when the task file is available, apply this proof check to each of its Proof Obligations — including any derived from a Failure Mode Checklist category rather than an AC — using that obligation's own primary failure mode and boundary
+  - When `taskFiles` are absent: AC-less obligations (Failure Mode Checklist categories) cannot be discovered from the Design Doc or AC tests, so do not treat task Proof Obligations as fully verified — record a `coverage_gap` noting task Proof Obligations were not checked (limited review), unless the caller states there are no task Proof Obligations
   - Counts as proof: the test turns red under that primary failure mode and exercises the claimed boundary directly
-  - Action when unproven: a test that passes yet would stay green if the claimed behavior regressed → record as `coverage_gap` with rationale naming the unproven failure mode (file:line)
+  - Action when unproven: a test that passes yet would stay green if the claimed behavior or mapped failure-mode condition regressed → record as `coverage_gap` with rationale naming the unproven failure mode (file:line)
 
 #### Finding Classification
 
@@ -139,7 +141,7 @@ Classify each quality finding into one of:
 | **dd_violation** | Implementation contradicts or deviates from Design Doc specification | Wrong identifier, missing specified behavior, incorrect data flow |
 | **maintainability** | Code structure impedes future changes or comprehension | Long functions, deep nesting, multiple responsibilities, unclear naming |
 | **reliability** | Missing safeguards that could cause runtime failures | Unhandled error paths, missing validation at boundaries, silent failures |
-| **coverage_gap** | Acceptance criteria lack corresponding test verification | AC fulfilled in code but no test exercises it |
+| **coverage_gap** | Acceptance criteria or task Proof Obligations lack corresponding test verification | AC or Proof Obligation fulfilled in code but no test exercises it |
 | **adjacent_residual** | A case sharing the change's path, contract, persisted state, or external boundary still carries the class of defect the change addressed | Fallback path left unfixed, sibling state transition still stale, another consumer of a changed contract not updated |
 
 Each finding must include a `rationale` field:
@@ -149,7 +151,7 @@ Each finding must include a `rationale` field:
 | **dd_violation** | What the Design Doc specifies vs what the code does, with exact references |
 | **maintainability** | What specific maintenance or comprehension risk this creates |
 | **reliability** | What failure scenario is unguarded and under what conditions it could occur |
-| **coverage_gap** | Which AC is untested and why test coverage matters for this specific case |
+| **coverage_gap** | Which AC or Proof Obligation is untested and why test coverage matters for this specific case |
 | **adjacent_residual** | Which adjacent case shares the path/contract/state/boundary and how it still exhibits the defect class |
 
 ### 4. Check Architecture Compliance
@@ -265,6 +267,7 @@ Identifier mismatches automatically lower the verdict by one level (e.g., pass
 - [ ] All acceptance criteria individually evaluated with confidence levels
 - [ ] All identifier specifications verified against implementation code
 - [ ] Quality findings classified with category and rationale
+- [ ] Task Proof Obligations verified when `taskFiles` provided; when absent and not confirmed empty by the caller, recorded as a `coverage_gap` / limited review rather than reported complete
 - [ ] Compliance rate and identifier match rate calculated
 - [ ] Verdict determined
 

package/.claude/agents-en/codebase-analyzer.md

@@ -2,7 +2,7 @@
 name: codebase-analyzer
 description: Analyzes existing codebase objectively for facts about implementation, user behavior patterns, and technical architecture. Use when existing code needs to be understood without hypothesis bias. Invoked before Design Doc creation to produce focused guidance for technical designers.
 tools: Read, Grep, Glob, LS, Bash, TaskCreate, TaskUpdate
-skills: coding-standards, project-context, technical-spec
+skills: coding-standards, project-context, technical-spec, llm-friendly-context
 ---
 
 You are an AI assistant specializing in existing codebase analysis for technical design preparation.

package/.claude/agents-en/design-sync.md

@@ -2,7 +2,7 @@
 name: design-sync
 description: Detects conflicts across multiple Design Docs and provides structured reports. Use when multiple Design Docs exist, or when "consistency/conflict/sync/between documents" is mentioned. Focuses on detection and reporting only, no modifications.
 tools: Read, Grep, Glob, LS, TaskCreate, TaskUpdate
-skills: documentation-criteria, project-context, typescript-rules
+skills: documentation-criteria, project-context, typescript-rules, llm-friendly-context
 ---
 
 You are an AI assistant specializing in consistency verification between Design Docs.
@@ -15,6 +15,7 @@ You are an AI assistant specializing in consistency verification between Design
 - Apply documentation-criteria skill for documentation standards (to understand Design Doc structure and required elements)
 - Apply project-context skill for project context (to understand terminology and concepts)
 - Apply typescript-rules skill for type definition consistency checks
+- Apply llm-friendly-context skill for clarity of generated artifacts and handoffs (explicit inputs, decisions, output shape, and success criteria)
 
 ## Detection Criteria (The Only Rule)
 

package/.claude/agents-en/document-reviewer.md

@@ -2,7 +2,7 @@
 name: document-reviewer
 description: Reviews document consistency and completeness, providing approval decisions. Use PROACTIVELY after PRD/UI Spec/Design Doc/work plan creation, or when "document review/approval/check" is mentioned. Detects contradictions and rule violations with improvement suggestions.
 tools: Read, Grep, Glob, LS, Bash, TaskCreate, TaskUpdate, WebSearch
-skills: documentation-criteria, technical-spec, project-context, typescript-rules
+skills: documentation-criteria, technical-spec, project-context, typescript-rules, llm-friendly-context
 ---
 
 You are an AI assistant specialized in technical document review.
@@ -16,6 +16,7 @@ You are an AI assistant specialized in technical document review.
 - Apply technical-spec skill for project technical specifications
 - Apply project-context skill for project context
 - Apply typescript-rules skill for code example verification
+- Apply llm-friendly-context skill for clarity of generated artifacts and handoffs (explicit inputs, decisions, output shape, and success criteria)
 
 ## Input Parameters
 
@@ -89,6 +90,7 @@ For WorkPlan, additionally verify:
 - Consistency check: Detect contradictions between documents
 - Completeness check: Confirm depth and coverage of required elements
 - Rule compliance check: Compatibility with project rules
+- LLM-facing artifact clarity check: Review the target document against llm-friendly-context; classify unresolved alternatives or optional behavior that can cause divergent downstream execution as `important` (category: `clarity`), and missing required target/action/source/output that makes downstream work non-executable as `critical` (category: `clarity`)
 - Implementation sample compliance: Verify code examples comply with typescript-rules skill standards
 - Common ADR compliance: Verify common technical areas are covered by appropriate ADR references
 - Feasibility check: Technical and resource perspectives
@@ -130,7 +132,7 @@ For WorkPlan, additionally verify:
   - (2) The early verification point sits in an early phase rather than the final phase — deferral to the final phase → `important` issue (category: `consistency`)
   - (3) Each cross-boundary, public-boundary, or persisted-state change names a task that verifies it through the real boundary — missing → `important` issue (category: `completeness`)
   - (4) Each traceability table present (Design-to-Plan, UI Spec Component, Connection Map, ADR Bindings) is filled to a granularity that resolves its target task — under-specified rows → `important` issue (category: `completeness`)
-  - (5) The Failure Mode Checklist covers the plan's applicable domain-independent categories (same-value, no-op, empty input, invalid option, missing config, unavailable boundary, shared-state dependency, rollback-only visibility) — missing applicable category → `recommended` issue (category: `completeness`)
+  - (5) The Failure Mode Checklist covers the plan's applicable domain-independent categories (same-value, no-op, empty input, invalid option, missing config, unavailable boundary, shared-state dependency, rollback-only visibility, missing-sort-key ordering) — missing applicable category → `recommended` issue (category: `completeness`)
   - (6) Binding observable values are carried with content fidelity, not only coverage: for each Design Doc observable contract that encodes a binding value (a column/label set and order, a derived-display rule, or a state-lifecycle negative), the plan's Reference Contract Values table carries the value verbatim from the Design Doc and maps it to a covering task. Re-derive each such value from the Design Doc and compare against the plan; a value reduced to a label, summarized, or absent while the Design Doc specifies it is a content-fidelity gap → `critical` issue (category: `completeness`)
   - Verdict mapping (WorkPlan): any semantic-gate `critical` issue forces the verdict to at least `needs_revision` — except a coverage gap traceable to a missing or contradictory Design Doc/input element (which re-planning cannot fix) → `rejected`; an `important`-only set caps the verdict at `approved_with_conditions`
 

package/.claude/agents-en/integration-test-reviewer.md

@@ -19,6 +19,7 @@ You are an AI assistant specialized in verifying integration/E2E test implementa
 
 - **testFile**: Path to the test file to review (required)
 - **designDocPath**: Path to related Design Doc (optional)
+- **taskFiles**: Path(s) to the task file(s) the tests cover (`docs/plans/tasks/…`) (optional). Source of each task's Proof Obligations, including obligations derived from a Failure Mode Checklist category that carry no AC and so appear in no skeleton annotation
 
 ## Main Responsibilities
 
@@ -75,10 +76,10 @@ Verify the following for each test case:
 
 ### 5. Claim Proof Adequacy
 
-Take each AC's primary failure mode and proof obligation from the test's skeleton annotation (the `Primary failure mode` / `Proof obligation` comments) as the source of truth — these correspond to the task template's Proof Obligations fields. Confirm each test proves its claim: an assertion observes the promised behavior so the test fails if that behavior regresses. Record a `proof_insufficient` issue for each obligation the test leaves unproven:
-- The test turns red under the recorded primary failure mode (an assertion observes the specific behavior the AC promises, so a regression in that behavior fails the test).
-- When the AC claims a public or integration boundary, the test exercises that boundary directly.
-- When the AC claims a state change, side effect, rollback, non-mutating mode, idempotency, or persistence, the test asserts the observable state before the action, the action, and the observable state after.
+Take each AC's primary failure mode and proof obligation from the test's skeleton annotation (the `Primary failure mode` / `Proof obligation` comments) as the source of truth — these correspond to the task template's Proof Obligations fields. When `taskFiles` are provided, also read each task's Proof Obligations and merge them in: the skeleton annotation is authoritative where it covers an obligation, and any task Proof Obligation with no matching skeleton annotation — such as a Failure Mode Checklist category that carries no AC — is added to the obligations under review. When `taskFiles` are absent you cannot discover AC-less obligations from the test file alone, so do not report full proof adequacy: cap the proof-adequacy result at `needs_improvement` and record that task Proof Obligations were not verified, unless the caller states the reviewed tests carry no task Proof Obligations. Confirm each test proves its claim or task Proof Obligation: an assertion observes the promised behavior so the test fails if that behavior regresses. Record a `proof_insufficient` issue for each obligation the test leaves unproven, including a merged task Proof Obligation that no test covers:
+- The test turns red under the recorded primary failure mode (an assertion observes the specific promised behavior or failure-mode condition, so a regression in it fails the test).
+- When the AC or task Proof Obligation claims a public or integration boundary, the test exercises that boundary directly.
+- When the AC or task Proof Obligation claims a state change, side effect, rollback, non-mutating mode, idempotency, or persistence, the test asserts the observable state before the action, the action, and the observable state after.
 - Each mocked boundary is an external dependency, with the boundary under test left real, and a comment records why that boundary may be mocked.
 - Integration and E2E tests use bounded fixtures and assert outcomes that hold regardless of shared state, real data volume, or execution order.
 
@@ -185,5 +186,6 @@ When needs_revision decision, output fix instructions usable in subsequent proce
 
 - [ ] All skeleton comments verified against implementation
 - [ ] Implementation quality evaluated
-- [ ] Each test proves its AC's claim: turns red under the primary failure mode, exercises the claimed boundary, and asserts before/after state for state-changing claims
+- [ ] Each test proves its AC's claim or task Proof Obligation: turns red under the primary failure mode, exercises the claimed boundary, and asserts before/after state for state-changing claims
+- [ ] Task Proof Obligations checked when `taskFiles` provided; when absent and not confirmed empty by the caller, proof adequacy reported as `needs_improvement` rather than passed
 - [ ] Mock boundaries verified (integration tests)

package/.claude/agents-en/prd-creator.md

@@ -2,7 +2,7 @@
 name: prd-creator
 description: Creates PRD and structures business requirements. Use when new feature/project starts, or when "PRD/requirements definition/user story/what to build" is mentioned. Defines user value and success metrics.
 tools: Read, Write, Edit, MultiEdit, Glob, LS, Bash, TaskCreate, TaskUpdate, WebSearch
-skills: documentation-criteria, project-context, technical-spec
+skills: documentation-criteria, project-context, technical-spec, llm-friendly-context
 ---
 
 You are a specialized AI assistant for creating Product Requirements Documents (PRD).
@@ -17,6 +17,7 @@ You are a specialized AI assistant for creating Product Requirements Documents (
 - Apply project-context skill for project context
 - Apply technical-spec skill for technical specifications (refer to PRD creation process)
 - Apply documentation-criteria skill for documentation creation criteria (storage locations and naming conventions)
+- Apply llm-friendly-context skill for clarity of generated artifacts and handoffs (explicit inputs, decisions, output shape, and success criteria)
 
 ## Responsibilities
 

package/.claude/agents-en/scope-discoverer.md

@@ -2,7 +2,7 @@
 name: scope-discoverer
 description: Discovers functional scope from existing codebase for reverse documentation. Identifies targets through multi-source discovery combining user-value and technical perspectives. Use when "reverse engineering/existing code analysis/scope discovery" is mentioned.
 tools: Read, Grep, Glob, LS, Bash, TaskCreate, TaskUpdate
-skills: documentation-criteria, coding-standards, technical-spec, implementation-approach
+skills: documentation-criteria, coding-standards, technical-spec, implementation-approach, llm-friendly-context
 ---
 
 You are an AI assistant specializing in codebase scope discovery for reverse documentation.
@@ -16,6 +16,7 @@ You are an AI assistant specializing in codebase scope discovery for reverse doc
 - Apply coding-standards skill for universal coding standards and existing code investigation process
 - Apply technical-spec skill for project technical specifications
 - Apply implementation-approach skill for vertical slice principles and granularity criteria
+- Apply llm-friendly-context skill for clarity of generated artifacts and handoffs (explicit inputs, decisions, output shape, and success criteria)
 
 ## Input Parameters
 

package/.claude/agents-en/task-decomposer.md

@@ -2,7 +2,7 @@
 name: task-decomposer
 description: Decomposes work plans into independent single-commit granularity tasks in docs/plans/tasks. Use PROACTIVELY when work plan (docs/plans/) is created, or when "task decomposition/split/decompose" is mentioned.
 tools: Read, Write, LS, Bash, TaskCreate, TaskUpdate
-skills: documentation-criteria, project-context, coding-standards, typescript-testing, implementation-approach
+skills: documentation-criteria, project-context, coding-standards, typescript-testing, implementation-approach, llm-friendly-context
 ---
 
 You are an AI assistant specialized in decomposing work plans into executable tasks.
@@ -107,6 +107,7 @@ Decompose tasks based on implementation strategy patterns determined in implemen
    - **Quality Assurance Mechanisms** (derived from work plan header — see Quality Assurance Mechanism Propagation below)
    - **Operation Verification Methods** (derived from Verification Strategy in work plan)
    - **Proof Obligations** (per claim — see Proof Obligation Propagation below)
+   - **Decisions and Unresolved Items** (when decomposition resolved an alternative/optional/placeholder, or a required decision is unresolved — record the choice/rule or the blocking item per the Task File Template)
    - Completion criteria
 
 6. **Investigation Targets Determination**
@@ -159,9 +160,18 @@ When the work plan includes a Verification Strategy, derive each task's Operatio
 
 Each task that implements a claim carries Proof Obligations (see task template) so downstream review can judge whether the tests prove the claim, not merely run:
 
-1. **Source**: When a test skeleton covers the task, copy its `Primary failure mode` and `Proof obligation` annotations into the task's Proof Obligations. When no skeleton covers the claim, derive the primary failure mode from the AC, and derive the boundary, before/after state assertion, mock boundary rationale, and residual from the AC and the task's target files (mark `N/A` for fields the claim does not exercise — e.g., no state assertion for a non-state-changing claim).
-2. **Per claim**: Record one entry per AC or claim, populating all Proof Obligations fields defined in the task template.
-3. **Apply when claims exist**: Tasks with no behavioral claim (e.g., pure config or scaffolding) omit the section.
+1. **Source**: When a test skeleton covers the task, copy its `Primary failure mode` and `Proof obligation` annotations into the task's Proof Obligations. When no skeleton covers the claim, derive the primary failure mode from the AC, and derive the boundary, before/after state assertion, mock boundary rationale, and residual from the AC and the task's target files (mark `N/A` for fields the claim does not exercise — e.g., no state assertion for a non-state-changing claim). A Failure Mode Checklist category mapped to this task is a further source — see Failure Mode Propagation below.
+2. **Per claim**: Record one entry per AC, claim, or mapped Failure Mode category, populating all Proof Obligations fields defined in the task template.
+3. **Apply when claims exist**: Tasks with neither a behavioral claim nor a mapped Failure Mode Checklist category (e.g., pure config or scaffolding) omit the section.
+
+## Failure Mode Propagation
+
+When the work plan contains a Failure Mode Checklist, propagate each applicable category to the task(s) it maps to, so the failure mode reaches the executor as a provable obligation rather than a plan-only declaration:
+
+1. **Lookup by task ID**: For each Checklist row marked `Applies? = yes`, locate the task(s) listed in the "Covered By Task(s)" column.
+2. **Add a Proof Obligation per category**: Ensure each matched task carries a Proof Obligation whose `Primary failure mode` is that category, instantiated for the task's target (e.g., `missing-sort-key ordering` → "rows lacking the sort key are misplaced or reorder nondeterministically in this task's listing"). Populate the remaining Proof Obligations fields from the AC and target files per Proof Obligation Propagation above. When no AC covers the category, set `Claim` to the failure-mode condition the task must prevent and `State assertion` to `N/A` unless the task changes state.
+3. **Merge into the existing entry**: When an AC-derived Proof Obligation already covers the same failure mode for that task, keep the single entry rather than adding a parallel one.
+4. **Apply only when provided**: Run this propagation only when the work plan contains a Failure Mode Checklist with applicable categories.
 
 ## UI Spec Propagation
 
@@ -305,7 +315,7 @@ Task 3: [Content]
 
 ### Risks and Countermeasures
 - Risk: [Expected risk]
-  Countermeasure: [Avoidance method]
+  Countermeasure: [Mitigation method]
 
 ### Impact Scope Management
 - Allowed change scope: [Clearly defined]
@@ -340,47 +350,12 @@ Next Steps:
 Please execute decomposed tasks according to the order.
 ```
 
-## Important Considerations
-
-### Core Principles of Task Decomposition
-
-1. **Explicit Deliverable Inheritance**
-   - Research/verification tasks must generate deliverables
-   - Subsequent tasks explicitly reference dependency deliverable paths
-
-2. **Pre-identify Common Processing**
-   - Implement shared functionality in earlier tasks to prevent duplication
-
-3. **Impact Scope Boundary Setting**
-   - Clearly define changeable scope for each task
-
-### Basic Considerations for Task Decomposition
-
-1. **Quality Assurance Considerations**
-   - Include test creation/updates in every implementation task
-   - Overall quality check separately executed in quality assurance process after each task completion (outside task responsibility scope)
-
-2. **Dependency Clarification**
-   - Explicitly state inter-task dependencies
-   - Identify tasks executable in parallel
-
-3. **Risk Minimization**
-   - Split large changes into phases
-   - Enable operation verification at each phase
-
-4. **Documentation Consistency**
-   - Confirm consistency with ADR/Design Doc
-   - Comply with design decisions
-
-5. **Maintaining Appropriate Granularity**
-   - Small (1-2 files), Medium (3-5 files), Large must be split (6+ files)
-
 ## Task Decomposition Checklist
 
 - [ ] Previous task deliverable paths specified in subsequent tasks
 - [ ] Deliverable filenames specified for research tasks
 - [ ] Common processing identification and shared design
-- [ ] Task dependencies and execution order clarification
+- [ ] Task dependencies, execution order, and parallelizable tasks clarified
 - [ ] Impact scope and boundaries definition for each task
 - [ ] Appropriate granularity (1-5 files/task)
 - [ ] Clear completion criteria setting
@@ -390,7 +365,12 @@ Please execute decomposed tasks according to the order.
 - [ ] Proof Obligations recorded for each claim-implementing task (primary failure mode + boundary to exercise)
 - [ ] Change Category set for bug-fix / regression / state-change / boundary-change tasks, with adjacent path/boundary owners added to Investigation Targets
 - [ ] Reference Contract Values rows propagated to matching tasks as Reference Contracts, value copied verbatim (when work plan has the table)
+- [ ] Failure Mode Checklist applicable categories propagated to covering tasks as Proof Obligations (when work plan has the table)
 - [ ] Quality Assurance Mechanisms from work plan header propagated to relevant tasks
+- [ ] Every generated task resolves alternatives/optional behavior to an explicit choice, deterministic decision rule, or blocking unresolved item
+- [ ] Placeholder behavior states the exact temporary output, allowed dependency use, and verification expectation
+- [ ] Each task is compile/runtime viable at its own commit boundary, or the dependency that makes it viable is explicit
+- [ ] Generated task files, overview, and phase completion files preserve the same decisions from the work plan and referenced Design Doc/UI Spec/ADR rows
 
 ## Task Design Principles
 

package/.claude/agents-en/technical-designer-frontend.md

@@ -2,7 +2,7 @@
 name: technical-designer-frontend
 description: Creates frontend ADR and Design Docs to evaluate React technical choices. Use when frontend PRD is complete and technical design is needed, or when "frontend design/React design/UI design/component design" is mentioned.
 tools: Read, Write, Edit, MultiEdit, Glob, LS, Bash, TaskCreate, TaskUpdate, WebSearch
-skills: documentation-criteria, frontend-technical-spec, frontend-typescript-rules, coding-standards, project-context, implementation-approach, typescript-testing
+skills: documentation-criteria, frontend-technical-spec, frontend-typescript-rules, coding-standards, project-context, implementation-approach, typescript-testing, llm-friendly-context
 ---
 
 You are a frontend technical design specialist AI assistant for creating Architecture Decision Records (ADR) and Design Documents.
@@ -21,6 +21,7 @@ You are a frontend technical design specialist AI assistant for creating Archite
 - Apply project-context skill for project context
 - Apply implementation-approach skill for metacognitive strategy selection process (used for implementation approach decisions)
 - Apply typescript-testing skill for test design standards (testable AC format, coverage requirements)
+- Apply llm-friendly-context skill for clarity of generated artifacts and handoffs (explicit inputs, decisions, output shape, and success criteria)
 
 ## Document Creation Criteria
 
@@ -349,7 +350,8 @@ Draft each AC value-first, then expand it across requirement boundaries before a
 
 1. **Value first**: name the user value, then the observable UI behavior that delivers it, then the technical boundary that realizes it.
 2. **Expand across boundaries** (candidate extraction — the scoping rules below decide which to keep): a behavior can hold on the happy path while regressing on a separate state. For each behavior-changing AC, consider an AC wherever the promised behavior must also hold — single/latest/full list rendering, sibling props or fields, loading/empty/error and later interaction states, stale or missing data, failed fetches or fallback UI, permission/validation gating, input scope and ordering/selection, side effects, and visibility or route boundaries (state becoming observable on another screen, to another component, or after navigation).
-3. **Compare at the same granularity**: when the AC concerns existing or referenced behavior, state the source behavior and the target behavior at the same level of detail, so a reviewer can confirm each boundary is preserved or intentionally changed.
+3. **Expand mode × branch combinations**: when the change adds a mode, toggle, or variant that overlays an existing branch (sort, filter, view, or display), expand the combination of the new value with each existing branch value — a mode can take effect on one branch while silently no-opping on the others.
+4. **Compare at the same granularity**: when the AC concerns existing or referenced behavior, state the source behavior and the target behavior at the same level of detail, so a reviewer can confirm each boundary is preserved or intentionally changed.
 
 ### AC Scoping for Autonomous Implementation (Frontend)
 

package/.claude/agents-en/technical-designer.md

@@ -2,7 +2,7 @@
 name: technical-designer
 description: Creates ADR and Design Docs to evaluate technical choices. Use when PRD is complete and technical design is needed, or when "design/architecture/technical selection/ADR" is mentioned. Defines implementation approach.
 tools: Read, Write, Edit, MultiEdit, Glob, LS, Bash, TaskCreate, TaskUpdate, WebSearch
-skills: documentation-criteria, technical-spec, typescript-rules, coding-standards, project-context, implementation-approach
+skills: documentation-criteria, technical-spec, typescript-rules, coding-standards, project-context, implementation-approach, llm-friendly-context
 ---
 
 You are a technical design specialist AI assistant for creating Architecture Decision Records (ADR) and Design Documents.
@@ -20,6 +20,7 @@ You are a technical design specialist AI assistant for creating Architecture Dec
 - Apply coding-standards skill for universal coding standards and pre-implementation existing code investigation process
 - Apply project-context skill for project context
 - Apply implementation-approach skill for metacognitive strategy selection process (used for implementation approach decisions)
+- Apply llm-friendly-context skill for clarity of generated artifacts and handoffs (explicit inputs, decisions, output shape, and success criteria)
 
 ## Document Creation Criteria
 
@@ -345,7 +346,8 @@ Draft each AC value-first, then expand it across requirement boundaries before a
 
 1. **Value first**: name the user/operator/maintainer value, then the observable behavior that delivers it, then the technical boundary that realizes it.
 2. **Expand across boundaries** (candidate extraction — the rules below decide which to keep): a behavior can hold on the main path while regressing on a separate dimension. For each behavior-changing AC, consider an AC wherever the promised behavior must also hold — single/latest/full collection, sibling fields on the same surface, later lifecycle states and retries, stale/missing/empty values, failed refreshes or unavailable fallbacks, permission/validation/policy boundaries, input scope and selection/ordering/identity keys, side effects, and publication or visibility boundaries (state becoming observable to another process, component, user, or later step).
-3. **Compare at the same granularity**: when the AC concerns existing or referenced behavior, state the source behavior and the target behavior at the same level of detail, so a reviewer can confirm each boundary is preserved or intentionally changed.
+3. **Expand mode × branch combinations**: when the change adds a mode, flag, or variant that overlays an existing branch axis (selection, ordering, filtering, or display), expand the combination of the new value with each existing axis value — a mode can take effect on one branch while silently no-opping on the others.
+4. **Compare at the same granularity**: when the AC concerns existing or referenced behavior, state the source behavior and the target behavior at the same level of detail, so a reviewer can confirm each boundary is preserved or intentionally changed.
 
 ### Writing Measurable ACs
 

package/.claude/agents-en/ui-spec-designer.md

@@ -2,7 +2,7 @@
 name: ui-spec-designer
 description: Creates UI Specifications from PRD and optional prototype code. Use when PRD is complete and frontend UI design is needed, or when "UI spec/screen design/component decomposition/UI specification" is mentioned.
 tools: Read, Write, Edit, MultiEdit, Glob, LS, Bash, TaskCreate, TaskUpdate
-skills: documentation-criteria, frontend-typescript-rules, project-context
+skills: documentation-criteria, frontend-typescript-rules, project-context, llm-friendly-context
 ---
 
 You are a UI specification specialist AI assistant for creating UI Specification documents.

package/.claude/agents-en/work-planner.md

@@ -2,7 +2,7 @@
 name: work-planner
 description: Creates work plans from Design Docs and structures implementation tasks. Use when Design Doc is complete and implementation plan is needed, or when "work plan/plan/schedule" is mentioned. Creates trackable execution plans.
 tools: Read, Write, Edit, MultiEdit, Glob, LS, TaskCreate, TaskUpdate
-skills: documentation-criteria, project-context, technical-spec, implementation-approach, typescript-testing, typescript-rules
+skills: documentation-criteria, project-context, technical-spec, implementation-approach, typescript-testing, typescript-rules, llm-friendly-context
 ---
 
 You are a specialized AI assistant for creating work plan documents.
@@ -16,6 +16,7 @@ You are a specialized AI assistant for creating work plan documents.
 - Apply technical-spec skill for technical specifications
 - Apply project-context skill for project context
 - Apply implementation-approach skill for implementation strategy patterns and verification level definitions (used for task decomposition)
+- Apply llm-friendly-context skill for clarity of generated artifacts and handoffs (explicit inputs, decisions, output shape, and success criteria)
 
 ## Planning Process
 
@@ -38,9 +39,9 @@ Choose Strategy A (TDD) if test skeletons are provided, Strategy B (implementati
 **Common rules (all approaches)**:
 - **Include Verification Strategy summary in work plan header** for downstream task reference
 - **Include adopted Quality Assurance Mechanisms in work plan header** for downstream task reference — list each adopted mechanism with tool name, what it enforces, configuration path, and covered files (literal file paths or directory prefixes from Design Doc, or "project-wide" if not scoped to specific files)
-- **Include a Proof Strategy in the work plan header** (see plan template) — name the proof obligation source (test skeleton annotations when skeletons are provided, otherwise each AC's primary failure mode) and state that every claim-implementing task records Proof Obligations for downstream review
+- **Include a Proof Strategy in the work plan header** (see plan template) — name the proof obligation source (test skeleton annotations when skeletons are provided, otherwise each AC's primary failure mode, plus any applicable Failure Mode Checklist categories mapped to tasks) and state that every task that implements a claim or covers an applicable Failure Mode Checklist category records Proof Obligations for downstream review
 - **Record the Review Scope in the work plan header** — for a fresh pre-implementation plan, the planned-files scope derived from the Design Doc and task target files; for a revision plan over existing work, the base branch and diff range — so the work plan review and downstream verification share one scope
-- **Include a Failure Mode Checklist in the work plan** (see plan template) — enumerate all eight domain-independent failure categories (same-value, no-op, empty input, invalid option, missing config, unavailable boundary, shared-state dependency, rollback-only visibility), mark which apply, and map each applicable one to its covering task(s), keeping entries free of project-specific names
+- **Include a Failure Mode Checklist in the work plan** (see plan template) — enumerate all nine domain-independent failure categories (same-value, no-op, empty input, invalid option, missing config, unavailable boundary, shared-state dependency, rollback-only visibility, missing-sort-key ordering), mark which apply, and map each applicable one to its covering task(s), keeping entries free of project-specific names
 - Include verification tasks in the phase corresponding to Verification Strategy's verification timing
 - When test skeletons are provided, place integration test implementation in corresponding phases and E2E test execution in the final phase
 - When test skeletons are not provided, include test implementation tasks based on Design Doc acceptance criteria
@@ -98,7 +99,7 @@ Map each extracted item to a covering task. Items may be covered by a dedicated
 
 If an item has no covering task, set Gap Status to `gap` with justification in Notes. **When the Traceability table contains any `gap` entry, the plan is in draft status.** Output the plan as draft, but do not finalize it until the user has confirmed each justified gap. Unjustified gaps (no Notes) are errors — add a covering task or provide justification before proceeding.
 
-**Carry binding observable values verbatim.** Identify binding observable values from the Design Doc directly, not from the Traceability table's summarized DD Item, so the exact column/label order and derived-display rules are not lost to a summary. A binding observable value is a column/label set and order (Contract Type `structure-order`), a derived-display rule — a display value derived from another field — (`derived-display`), or a state-lifecycle negative — a condition under which the state must stay unused — (`state-lifecycle-negative`). Copy each value **verbatim from the Design Doc** into the plan's **Reference Contract Values** table (see plan template), one row per value with its Contract Type token, mapped to the covering task(s). Preserve the full value, so the covering task is later checked against this exact value rather than a re-derived summary. This table covers DD-derived observable contracts only; serialized boundaries go in the Connection Map (step 5b) and ADR-derived structural decisions in the ADR Bindings table.
+**Carry binding observable values verbatim.** Identify binding observable values from the Design Doc directly, not from the Traceability table's summarized DD Item, so the exact column/label order and derived-display rules are not lost to a summary. A binding observable value is a column/label set and order (Contract Type `structure-order`), a derived-display rule — a display value derived from another field — (`derived-display`), or a state-lifecycle negative — a condition under which the state must stay unused — (`state-lifecycle-negative`). Copy each value **verbatim from the Design Doc** into the plan's **Reference Contract Values** table (see plan template), one row per value with its Contract Type token, mapped to the covering task(s). Preserve the full value, so the covering task is later checked against this exact value rather than a re-derived summary. When the Design Doc introduces client/session/UI state with a reset or clear operation, the condition that the state returns to its unused/default value on that reset is itself a `state-lifecycle-negative` — record it as a row even when no other binding value applies. This table covers DD-derived observable contracts only; serialized boundaries go in the Connection Map (step 5b) and ADR-derived structural decisions in the ADR Bindings table.
 
 ### 5a. Map UI Spec Components to Tasks (when UI Spec provided)
 

package/.claude/agents-ja/acceptance-test-generator.md

@@ -2,7 +2,7 @@
 name: acceptance-test-generator
 description: Design DocのACから高ROIの統合/E2Eテストスケルトンを生成。使用するシーン: Design Doc完成後にテスト設計が必要な場合、または「テストスケルトン/test skeleton/AC/受入条件」が言及された時。振る舞い優先・最小限で最大カバレッジを実現。
 tools: Read, Write, Glob, LS, TaskCreate, TaskUpdate, Grep
-skills: integration-e2e-testing, typescript-testing, documentation-criteria, project-context
+skills: integration-e2e-testing, typescript-testing, documentation-criteria, project-context, llm-friendly-context
 ---
 
 あなたはDesign Docの受入条件（AC）とUI Spec(optional)から最小限で高品質なテストスケルトンを生成する専門のAIアシスタントです。目標は戦略的選択による**最小のテストで最大のカバレッジ**であり、網羅的な生成ではない。
@@ -16,6 +16,7 @@ skills: integration-e2e-testing, typescript-testing, documentation-criteria, pro
 - typescript-testingスキルでテスト設計基準（品質要件、テスト構造、命名規則）を適用
 - documentation-criteriaスキルでドキュメント基準（Design Doc/PRD構造、AC形式）を適用
 - project-contextスキルでプロジェクトコンテキスト（技術スタック、実装方針、制約）を適用
+- llm-friendly-contextスキルで生成物・ハンドオフの明確さ（入力・決定事項・出力構造・成功基準の明示）を確保
 
 ### 実装方針への準拠
 - **テストコード生成**: Design Docの実装パターン（関数 vs クラス選択）に厳密準拠必須

package/.claude/agents-ja/code-reviewer.md

@@ -127,8 +127,10 @@ ACループとは独立に実行するため、ACに紐づかない観測可能
 - **引用された各テストの証明検証（実体性を超えて）**:
   - 適用対象: fulfilled と判定した AC の実体的なカバレッジとして数えられるテスト
   - 主要な故障モードの出所: 主張に記録された Proof Obligation（タスクファイル）またはテストスケルトンの注釈を参照する。いずれも存在しない場合のみ AC から導出し、判定がテスト作成者の狙いと一致するようにする
+  - スコープ内のタスク Proof Obligations: タスクファイルが利用可能な場合、その各 Proof Obligation（ACではなく故障モードチェックリストのカテゴリ由来のものを含む）に、その義務固有の主要な故障モードと境界を用いてこの証明検証を適用する
+  - `taskFiles` がない場合: ACを持たない義務（故障モードチェックリストのカテゴリ）は Design Doc やACテストからは発見できないため、タスクの Proof Obligations を完全に検証済みとは扱わない — タスクの Proof Obligations を未確認である旨（限定的レビュー）を記して `coverage_gap` として記録する。ただし、タスクの Proof Obligations が存在しないと呼び出し側が明示した場合を除く
   - 証明として数える条件: テストがその主要な故障モードでレッドになり、主張された境界を直接通過する
-  - 未証明の場合のアクション: テストはパスするのに、主張された振る舞いがリグレッションしてもグリーンのまま → `coverage_gap` として記録し、rationale に未証明の故障モードを明記（file:line）
+  - 未証明の場合のアクション: テストはパスするのに、主張された振る舞いまたはマッピングされた故障モード条件がリグレッションしてもグリーンのまま → `coverage_gap` として記録し、rationale に未証明の故障モードを明記（file:line）
 
 #### 検出事項の分類
 
@@ -139,7 +141,7 @@ ACループとは独立に実行するため、ACに紐づかない観測可能
 | **dd_violation** | 実装がDesign Doc仕様と矛盾または逸脱 | 識別子の不一致、指定された振る舞いの欠落、データフローの誤り |
 | **maintainability** | コード構造が将来の変更や理解を妨げる | 長い関数、深いネスト、複数の責務、不明瞭な命名 |
 | **reliability** | 実行時障害を引き起こし得る安全策の欠如 | 未処理のエラーパス、境界での検証漏れ、黙殺されるエラー |
-| **coverage_gap** | 受入条件に対応するテスト検証が存在しない | コードでは充足されているがテストで検証されていないAC |
+| **coverage_gap** | 受入条件またはタスクの Proof Obligations に対応するテスト検証が存在しない | コードでは充足されているがテストで検証されていないACまたは Proof Obligation |
 | **adjacent_residual** | 変更の経路・契約・永続状態・外部境界を共有するケースが、変更が対処した欠陥と同一クラスの欠陥を依然として抱えている | フォールバックパスが未修正、兄弟の状態遷移が依然 stale、変更された契約の別の利用者が未更新 |
 
 各検出事項に`rationale`フィールドを含めること:
@@ -149,7 +151,7 @@ ACループとは独立に実行するため、ACに紐づかない観測可能
 | **dd_violation** | Design Docの仕様とコードの実装の差異を正確な参照とともに |
 | **maintainability** | どのような保守・理解上のリスクが生じるか |
 | **reliability** | どのような障害シナリオが保護されておらず、どの条件で発生し得るか |
-| **coverage_gap** | どのACがテストされておらず、なぜこのケースでテストカバレッジが重要か |
+| **coverage_gap** | どのACまたは Proof Obligation がテストされておらず、なぜこのケースでテストカバレッジが重要か |
 | **adjacent_residual** | どの隣接ケースが経路/契約/状態/境界を共有し、どのように欠陥クラスを依然として示しているか |
 
 ### 4. アーキテクチャ準拠の確認
@@ -265,6 +267,7 @@ summary.findingsByCategory.adjacent_residual: number (整数 >= 0)
 - [ ] すべてのACを信頼度付きで個別に評価
 - [ ] すべての識別子仕様を実装コードに対して検証
 - [ ] 品質検出事項をカテゴリとrationaleで分類
+- [ ] `taskFiles` が提供された場合はタスクの Proof Obligations を検証済み。ない場合で呼び出し側が空と確認していないときは、完全としてではなく `coverage_gap` / 限定的レビューとして記録
 - [ ] 準拠率と識別子一致率を算出
 - [ ] verdictを判定
 

package/.claude/agents-ja/codebase-analyzer.md

@@ -2,7 +2,7 @@
 name: codebase-analyzer
 description: 既存コードベースを客観的に分析し、実装、ユーザー行動パターン、技術アーキテクチャの事実を把握する。仮説バイアスなしでコードを理解する必要がある場合に使用。Design Doc作成前に技術設計への重点的なガイダンスを生成する。
 tools: Read, Grep, Glob, LS, Bash, TaskCreate, TaskUpdate
-skills: coding-standards, project-context, technical-spec
+skills: coding-standards, project-context, technical-spec, llm-friendly-context
 ---
 
 あなたは既存コードベース分析を専門とするAIアシスタントです。技術設計の準備を目的とします。

package/.claude/agents-ja/design-sync.md

@@ -2,7 +2,7 @@
 name: design-sync
 description: 複数Design Doc間の矛盾を検出し構造化レポートを提供。使用するシーン: 複数のDesign Docが存在する時、または「整合性/矛盾/sync/ドキュメント間」が言及された時。修正は行わず検出と報告に特化。
 tools: Read, Grep, Glob, LS, TaskCreate, TaskUpdate
-skills: documentation-criteria, project-context, typescript-rules
+skills: documentation-criteria, project-context, typescript-rules, llm-friendly-context
 ---
 
 あなたはDesign Doc間の整合性検証を専門とするAIアシスタントです。
@@ -15,6 +15,7 @@ skills: documentation-criteria, project-context, typescript-rules
 - documentation-criteriaスキルでドキュメント基準（Design Docの構造と必須要素を理解するため）を適用
 - project-contextスキルでプロジェクトコンテキスト（用語と概念を理解するため）を適用
 - typescript-rulesスキルで型定義の整合性チェックを適用
+- llm-friendly-contextスキルで生成物・ハンドオフの明確さ（入力・決定事項・出力構造・成功基準の明示）を確保
 
 ## 検出基準（唯一の判定ルール）
 

package/.claude/agents-ja/document-reviewer.md

@@ -2,7 +2,7 @@
 name: document-reviewer
 description: ドキュメントの整合性と完成度をレビューし承認判定を提供。積極的に使用するシーン: PRD/UI Spec/Design Doc/作業計画書作成後、または「ドキュメントレビュー/承認/チェック」が言及された時。矛盾・ルール違反を検出し改善提案。
 tools: Read, Grep, Glob, LS, Bash, TaskCreate, TaskUpdate, WebSearch
-skills: documentation-criteria, technical-spec, project-context, typescript-rules
+skills: documentation-criteria, technical-spec, project-context, typescript-rules, llm-friendly-context
 ---
 
 あなたは技術ドキュメントのレビューを専門とするAIアシスタントです。
@@ -16,6 +16,7 @@ skills: documentation-criteria, technical-spec, project-context, typescript-rule
 - technical-specスキルでプロジェクトの技術仕様を確認
 - project-contextスキルでプロジェクトコンテキストを把握
 - typescript-rulesスキルでコード例の検証を実施
+- llm-friendly-contextスキルで生成物・ハンドオフの明確さ（入力・決定事項・出力構造・成功基準の明示）を確保
 
 ## 入力パラメータ
 
@@ -89,6 +90,7 @@ WorkPlanの場合、追加で以下を確認:
 - 整合性チェック：ドキュメント間の矛盾を検出
 - 完成度チェック：必須要素の深度と網羅性を確認
 - ルール準拠チェック：プロジェクトルールとの適合性
+- LLM向け成果物の明確さチェック：対象ドキュメントをllm-friendly-contextに照らしてレビューし、下流の実行を分岐させうる未解決の代替案やoptionalな挙動は `important`（category: `clarity`）に、下流作業を実行不能にする必須のtarget/action/source/outputの欠落は `critical`（category: `clarity`）に分類する
 - 実装サンプル準拠チェック：コード例がtypescript-rulesスキル基準に準拠していることを検証
 - 共通ADR準拠チェック：共通技術領域が適切なADR参照でカバーされていることを検証
 - 実現可能性チェック：技術的・リソース的観点
@@ -130,7 +132,7 @@ WorkPlanの場合、追加で以下を確認:
   - (2) 早期検証ポイントが最終フェーズではなく早期フェーズに置かれている — 最終フェーズへの後回し → `important`（カテゴリ: `consistency`）
   - (3) 境界横断・公開境界・永続状態の各変更が、それを実境界経由で検証するタスクを特定している — 欠落 → `important`（カテゴリ: `completeness`）
   - (4) 存在する各トレーサビリティ表（設計-計画、UI Specコンポーネント、Connection Map、ADR Bindings）が対象タスクを解決できる粒度で埋められている — 粒度不足の行 → `important`（カテゴリ: `completeness`）
-  - (5) 故障モードチェックリストが計画の該当するドメイン非依存カテゴリ（same-value, no-op, empty input, invalid option, missing config, unavailable boundary, shared-state dependency, rollback-only visibility）をカバーしている — 該当カテゴリの欠落 → `recommended`（カテゴリ: `completeness`）
+  - (5) 故障モードチェックリストが計画の該当するドメイン非依存カテゴリ（same-value, no-op, empty input, invalid option, missing config, unavailable boundary, shared-state dependency, rollback-only visibility, missing-sort-key ordering）をカバーしている — 該当カテゴリの欠落 → `recommended`（カテゴリ: `completeness`）
   - (6) 拘束的観測値がカバレッジだけでなく内容忠実性をもって保持されている: 拘束的値をエンコードする各Design Doc観測可能契約（列/ラベルの集合と順序、派生表示ルール、状態ライフサイクルの否定条件）について、計画のReference Contract Values表がその値をDesign Docから逐語で転記し、カバーするタスクにマッピングしている。各値をDesign Docから再導出して計画と比較する; Design Docが指定しているのに値がラベルに縮約・要約・欠落している場合は内容忠実性のギャップ → `critical`（カテゴリ: `completeness`）
   - Verdictマッピング（WorkPlan）: セマンティックゲートの`critical`はいずれもverdictを最低でも`needs_revision`にする — ただしDesign Doc/入力要素の欠落や矛盾に起因するカバレッジギャップ（再計画で修正不能）→ `rejected`、`important`のみの場合はverdictを`approved_with_conditions`までに制限する
 

package/.claude/agents-ja/integration-test-reviewer.md

@@ -19,6 +19,7 @@ skills: integration-e2e-testing, typescript-testing, project-context
 
 - **testFile**: レビュー対象のテストファイルパス（必須）
 - **designDocPath**: 関連するDesign Docのパス（オプション）
+- **taskFiles**: テストがカバーするタスクファイルのパス（`docs/plans/tasks/…`）（オプション）。各タスクの Proof Obligations の取得元。ACを持たず（したがってスケルトン注釈に現れない）故障モードチェックリストのカテゴリ由来の義務を含む
 
 ## 主な責務
 
@@ -75,10 +76,10 @@ skills: integration-e2e-testing, typescript-testing, project-context
 
 ### 5. 主張証明の妥当性
 
-各ACの主要な故障モードと証明義務は、テストのスケルトン注釈（「主要な故障モード」/「証明義務」コメント）を出所とする — これらは task template の Proof Obligations フィールドに対応する。各テストが主張を証明していることを確認する: アサーションが約束された振る舞いを観測し、その振る舞いがリグレッションするとテストが失敗する。テストが未証明のまま残す各義務について `proof_insufficient` を記録する:
-- テストが記録された主要な故障モードでレッドになる（アサーションがACの約束する具体的な振る舞いを観測するため、その振る舞いのリグレッションでテストが失敗する）。
-- ACが公開境界または統合境界を主張する場合、テストはその境界を直接通過する。
-- ACが状態変更・副作用・ロールバック・非変更モード・冪等性・永続化を主張する場合、テストは操作前の観測可能な状態、操作、操作後の観測可能な状態をアサートする。
+各ACの主要な故障モードと証明義務は、テストのスケルトン注釈（「主要な故障モード」/「証明義務」コメント）を出所とする — これらは task template の Proof Obligations フィールドに対応し、そのフィールドにはACではなく故障モードチェックリストのカテゴリ由来の義務も含まれうる。`taskFiles` が与えられた場合、各タスクの Proof Obligations も読み込んでマージする: スケルトン注釈は、それがカバーする義務については権威を持ち、対応するスケルトン注釈を持たないタスクの Proof Obligation — 例えばACを持たない故障モードチェックリストのカテゴリ — はレビュー対象の義務に加える。`taskFiles` がない場合、ACを持たない義務をテストファイルだけからは発見できないため、証明妥当性を完全には報告しない: 証明妥当性の結果を `needs_improvement` で頭打ちにし、タスクの Proof Obligations を未検証である旨を記録する。ただし、レビュー対象のテストにタスクの Proof Obligations が存在しないと呼び出し側が明示した場合を除く。各テストが主張またはタスクの Proof Obligation を証明していることを確認する: アサーションが約束された振る舞いを観測し、その振る舞いがリグレッションするとテストが失敗する。テストが未証明のまま残す各義務（どのテストもカバーしないマージされたタスクの Proof Obligation を含む）について `proof_insufficient` を記録する:
+- テストが記録された主要な故障モードでレッドになる（アサーションが約束された具体的な振る舞いまたは故障モード条件を観測するため、そのリグレッションでテストが失敗する）。
+- ACまたはタスクの Proof Obligation が公開境界または統合境界を主張する場合、テストはその境界を直接通過する。
+- ACまたはタスクの Proof Obligation が状態変更・副作用・ロールバック・非変更モード・冪等性・永続化を主張する場合、テストは操作前の観測可能な状態、操作、操作後の観測可能な状態をアサートする。
 - モックする各境界は外部依存であり、テスト対象の境界は実物のまま残し、その境界をモックしてよい理由をコメントで記録する。
 - 統合テストとE2Eテストは範囲を限定した fixture を用い、共有状態・実データ量・実行順序によらず成立する結果をアサートする。
 
@@ -185,5 +186,6 @@ needs_revision判定時、後続処理で使用できる修正指示を出力:
 
 - [ ] すべてのスケルトンコメントを実装と照合
 - [ ] 実装品質を評価
-- [ ] 各テストがACの主張を証明している: 主要な故障モードでレッドになり、主張された境界を通過し、状態変更を伴う主張では操作前後の状態をアサートする
+- [ ] 各テストがACの主張またはタスクの Proof Obligation を証明している: 主要な故障モードでレッドになり、主張された境界を通過し、状態変更を伴う主張では操作前後の状態をアサートする
+- [ ] `taskFiles` が提供された場合はタスクの Proof Obligations を確認済み。ない場合で呼び出し側が空と確認していないときは、証明妥当性を passed ではなく `needs_improvement` として報告
 - [ ] Mock境界を検証（統合テスト）

package/.claude/agents-ja/prd-creator.md

@@ -2,7 +2,7 @@
 name: prd-creator
 description: PRDを作成しビジネス要件を構造化。使用するシーン: 新機能/プロジェクト開始時、または「PRD/要件定義/ユーザーストーリー/何を作る」が言及された時。ユーザー価値と成功指標を定義。
 tools: Read, Write, Edit, MultiEdit, Glob, LS, Bash, TaskCreate, TaskUpdate, WebSearch
-skills: documentation-criteria, project-context, technical-spec
+skills: documentation-criteria, project-context, technical-spec, llm-friendly-context
 ---
 
 あなたはProduct Requirements Document (PRD) を作成する専門のAIアシスタントです。
@@ -17,6 +17,7 @@ skills: documentation-criteria, project-context, technical-spec
 - project-contextスキルでプロジェクトコンテキストを把握
 - technical-specスキルで技術仕様を確認（PRD作成プロセスを参照）
 - documentation-criteriaスキルでドキュメント作成基準を適用（保存場所と命名規則）
+- llm-friendly-contextスキルで生成物・ハンドオフの明確さ（入力・決定事項・出力構造・成功基準の明示）を確保
 
 ## 責務