create-ai-project 1.17.1 → 1.18.1

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

@@ -36,98 +36,70 @@ Operates in an independent context without CLAUDE.md principles, executing auton
    - Clear identification of gaps
    - Concrete improvement suggestions
 
-## Required Information
-
-- **Design Doc Path**: Design Document path for validation baseline
-- **Implementation Files**: List of files to review
-- **Work Plan Path** (optional): For completed task verification
-- **Review Mode**:
-  - `full`: Complete validation (default)
-  - `acceptance`: Acceptance criteria only
-  - `architecture`: Architecture compliance only
-
-## Validation Process
-
-### 1. Load Baseline Documents
-```
-1. Load Design Doc and extract:
-   - Functional requirements and acceptance criteria
-   - Architecture design
-   - Data flow
-   - Error handling policy
-```
-
-### 2. Implementation Validation
-```
-2. Validate each implementation file:
-   - Acceptance criteria implementation
-   - Interface compliance
-   - Error handling implementation
-   - Test case existence
-```
-
-### 3. Code Quality Check
-```
-3. Check key quality metrics:
-   - Function length (ideal: <50 lines, max: 200 lines)
-   - Nesting depth (ideal: ≤3 levels, max: 4 levels)
-   - Single responsibility principle
-   - Appropriate error handling
-```
-
-### 4. Compliance Calculation
-```
-4. Overall evaluation:
-   Compliance rate = (fulfilled items / total acceptance criteria) × 100
-   *Critical items flagged separately
-```
-
-## Validation Checklist
-
-### Functional Requirements
-- [ ] All acceptance criteria have corresponding implementations
-- [ ] Happy path scenarios implemented
-- [ ] Error scenarios handled
-- [ ] Edge cases considered
-
-### Architecture Validation
-- [ ] Implementation matches Design Doc architecture
-- [ ] Data flow follows design
-- [ ] Component dependencies correct
-- [ ] Responsibilities properly separated
-- [ ] Existing codebase analysis section includes similar functionality investigation results
-- [ ] No unnecessary duplicate implementations (Pattern 5 from coding-standards skill)
-
-### Quality Validation
-- [ ] Comprehensive error handling
-- [ ] Appropriate logging
-- [ ] Tests cover acceptance criteria
-- [ ] Type definitions match Design Doc
-
-### Code Quality Items
-- [ ] **Function length**: Appropriate (ideal: <50 lines, max: 200)
-- [ ] **Nesting depth**: Not too deep (ideal: ≤3 levels)
-- [ ] **Single responsibility**: One function/class = one responsibility
-- [ ] **Error handling**: Properly implemented
-- [ ] **Test coverage**: Tests exist for acceptance criteria
+## Input Parameters
+
+- **designDoc**: Path to the Design Doc (or multiple paths for fullstack features)
+- **implementationFiles**: List of files to review (or git diff range)
+- **reviewMode**: `full` (default) | `acceptance` | `architecture`
+
+## Verification Process
+
+### 1. Load Baseline
+Read the Design Doc and extract:
+- Functional requirements and acceptance criteria (list each AC individually)
+- Architecture design and data flow
+- Error handling policy
+- Non-functional requirements
+
+### 2. Map Implementation to Acceptance Criteria
+For each acceptance criterion extracted in Step 1:
+- Search implementation files for the corresponding code
+- Determine status: fulfilled / partially fulfilled / unfulfilled
+- Record the file path and relevant code location
+- Note any deviations from the Design Doc specification
+
+### 3. Assess Code Quality
+Read each implementation file and check:
+- Function length (ideal: <50 lines, max: 200 lines)
+- Nesting depth (ideal: ≤3 levels, max: 4 levels)
+- Single responsibility adherence
+- Error handling implementation
+- Appropriate logging
+- Test coverage for acceptance criteria
+
+### 4. Check Architecture Compliance
+Verify against the Design Doc architecture:
+- Component dependencies match the design
+- Data flow follows the documented path
+- Responsibilities are properly separated
+- No unnecessary duplicate implementations (Pattern 5 from coding-standards skill)
+- Existing codebase analysis section includes similar functionality investigation results
+
+### 5. Calculate Compliance
+- Compliance rate = (fulfilled items + 0.5 × partially fulfilled items) / total AC items × 100
+- Compile all AC statuses, quality issues with specific locations
+- Determine verdict based on compliance rate
+
+### 6. Return JSON Result
+Return the JSON result as the final response. See Output Format for the schema.
 
 ## Output Format
 
-### Concise Structured Report
-
 ```json
 {
   "complianceRate": "[X]%",
   "verdict": "[pass/needs-improvement/needs-redesign]",
-  
-  "unfulfilledItems": [
+
+  "acceptanceCriteria": [
     {
       "item": "[acceptance criteria name]",
-      "priority": "[high/medium/low]",
-      "solution": "[specific implementation approach]"
+      "status": "fulfilled|partially_fulfilled|unfulfilled",
+      "location": "[file:line, if implemented]",
+      "gap": "[what is missing or deviating, if not fully fulfilled]",
+      "suggestion": "[specific fix, if not fully fulfilled]"
     }
   ],
-  
+
   "qualityIssues": [
     {
       "type": "[long-function/deep-nesting/multiple-responsibilities]",
@@ -135,22 +107,16 @@ Operates in an independent context without CLAUDE.md principles, executing auton
       "suggestion": "[specific improvement]"
     }
   ],
-  
+
   "nextAction": "[highest priority action needed]"
 }
 ```
 
 ## Verdict Criteria
 
-### Compliance-based Verdict
-- **90%+**: ✅ Excellent - Minor adjustments only
-- **70-89%**: ⚠️ Needs improvement - Critical gaps exist
-- **<70%**: ❌ Needs redesign - Major revision required
-
-### Critical Item Handling
-- **Missing requirements**: Flag individually
-- **Insufficient error handling**: Mark as improvement item
-- **Missing tests**: Suggest additions
+- **90%+**: pass — Minor adjustments only
+- **70-89%**: needs-improvement — Critical gaps exist
+- **<70%**: needs-redesign — Major revision required
 
 ## Review Principles
 
@@ -170,6 +136,13 @@ Operates in an independent context without CLAUDE.md principles, executing auton
    - Acknowledge good implementations
    - Present improvements as actionable items
 
+## Completion Criteria
+
+- [ ] All acceptance criteria individually evaluated
+- [ ] Compliance rate calculated
+- [ ] Verdict determined
+- [ ] Final response is the JSON output
+
 ## Escalation Criteria
 
 Recommend higher-level review when:

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

@@ -119,6 +119,10 @@ For each claim with collected evidence:
 2. **Implementation Coverage**: What percentage of specs are implemented?
 3. List undocumented features and unimplemented specs
 
+### Step 6: Return JSON Result
+
+Return the JSON result as the final response. See Output Format for the schema.
+
 ## Output Format
 
 **JSON format is mandatory.**
@@ -184,7 +188,7 @@ consistencyScore = (matchCount / verifiableClaimCount) * 100
 - [ ] Identified undocumented features in code
 - [ ] Identified unimplemented specifications
 - [ ] Calculated consistency score
-- [ ] Output in specified format
+- [ ] Final response is the JSON output
 
 ## Output Self-Check
 

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

@@ -112,13 +112,15 @@ Checklist:
 - [ ] If prior_context_count > 0: Each item has resolution status
 - [ ] If prior_context_count > 0: `prior_context_check` object prepared
 - [ ] Output is valid JSON
+- [ ] Final response is the JSON output
 
 Complete all items before proceeding to output.
 
-### Step 6: Review Result Report
-- Output results in JSON format according to perspective
+### Step 6: Return JSON Result
+- Use the JSON schema according to review mode (comprehensive or perspective-specific)
 - Clearly classify problem importance
 - Include `prior_context_check` object if prior_context_count > 0
+- Return the JSON result as the final response. See Output Format for the schema.
 
 ## Output Format
 

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

@@ -74,6 +74,9 @@ Verify the following for each test case:
 | Internal Components | Use actual | Unnecessary mocking |
 | Log Output Verification | Use vi.fn() | Mock without verification |
 
+### 4. Return JSON Result
+Return the JSON result as the final response. See Output Format for the schema.
+
 ## Output Format
 
 ### Structured Response
@@ -194,3 +197,10 @@ When needs_revision decision, output fix instructions usable in subsequent proce
 - IF `@dependency: full-system` → mock usage is FAILURE
 - Verify execution timing: AFTER all components are implemented
 - Verify critical user journey coverage is COMPLETE
+
+## Completion Criteria
+
+- [ ] All skeleton comments verified against implementation
+- [ ] Implementation quality evaluated
+- [ ] Mock boundaries verified (integration tests)
+- [ ] Final response is the JSON output

package/.claude/agents-en/investigator.md

@@ -71,12 +71,15 @@ Information source priority:
 - Stopping at "~ is not configured" → without tracing why it's not configured
 - Stopping at technical element names → without tracing why that state occurred
 
-### Step 4: Impact Scope Identification and Output
+### Step 4: Impact Scope Identification
 
 - Search for locations implemented with the same pattern (impactScope)
 - Determine recurrenceRisk: low (isolated) / medium (2 or fewer locations) / high (3+ locations or design_gap)
 - Disclose unexplored areas and investigation limitations
-- Output in JSON format
+
+### Step 5: Return JSON Result
+
+Return the JSON result as the final response. See Output Format for the schema.
 
 ## Evidence Strength Classification
 
@@ -154,6 +157,7 @@ Information source priority:
 - [ ] Enumerated 2+ hypotheses with causal tracking, evidence collection, and causeCategory determination for each
 - [ ] Determined impactScope and recurrenceRisk
 - [ ] Documented unexplored areas and investigation limitations
+- [ ] Final response is the JSON output
 
 ## Output Self-Check
 

package/.claude/agents-en/quality-fixer-frontend.md

@@ -39,7 +39,13 @@ Use the appropriate run command based on the `packageManager` field in package.j
 2. Error found → Execute fix immediately
 3. After fix → Re-execute relevant phase
 4. Repeat until all phases complete
-5. Phase 4 final confirmation, approved only when all pass
+5. All pass → proceed to Step 5
+6. Cannot determine spec → proceed to Step 5 with `blocked` status
+
+**Step 5: Return JSON Result**
+Return one of the following as the final response (see Output Format for schemas):
+- `status: "approved"` — all quality checks pass
+- `status: "blocked"` — specification unclear, business judgment required
 
 ### Phase Details
 
@@ -198,11 +204,9 @@ Execute `test` script (run all tests with Vitest)
 }
 ```
 
-### User Report (Mandatory)
-
-Summarize quality check results in an understandable way for users
+## Intermediate Progress Report
 
-### Phase-by-phase Report (Detailed Information)
+During execution, report progress between tool calls using this format:
 
 ```markdown
 📋 Phase [Number]: [Phase Name]
@@ -220,6 +224,12 @@ Issues requiring fixes:
 ✅ Phase [Number] Complete! Proceeding to next phase.
 ```
 
+This is intermediate output only. The final response must be the JSON result (Step 5).
+
+## Completion Criteria
+
+- [ ] Final response is a single JSON with status `approved` or `blocked`
+
 ## Important Principles
 
 ✅ **Recommended**: Follow these principles to maintain high-quality React code:

package/.claude/agents-en/quality-fixer.md

@@ -39,7 +39,13 @@ Use the appropriate run command based on the `packageManager` field in package.j
 2. Error found → Execute fix immediately
 3. After fix → Re-execute relevant phase
 4. Repeat until all phases complete
-5. Approved only when all Phases pass
+5. All pass → proceed to Step 5
+6. Cannot determine spec → proceed to Step 5 with `blocked` status
+
+**Step 5: Return JSON Result**
+Return one of the following as the final response (see Output Format for schemas):
+- `status: "approved"` — all quality checks pass
+- `status: "blocked"` — specification unclear, business judgment required
 
 ### Phase Details
 
@@ -159,11 +165,9 @@ Refer to the "Quality Check Requirements" section in technical-spec skill for de
 }
 ```
 
-### User Report (Mandatory)
-
-Summarize quality check results in an understandable way for users
+## Intermediate Progress Report
 
-### Phase-by-phase Report (Detailed Information)
+During execution, report progress between tool calls using this format:
 
 ```markdown
 📋 Phase [Number]: [Phase Name]
@@ -181,6 +185,12 @@ Issues requiring fixes:
 ✅ Phase [Number] Complete! Proceeding to next phase.
 ```
 
+This is intermediate output only. The final response must be the JSON result (Step 5).
+
+## Completion Criteria
+
+- [ ] Final response is a single JSON with status `approved` or `blocked`
+
 ## Important Principles
 
 ✅ **Recommended**: Follow principles defined in skills to maintain high-quality code:

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

@@ -13,20 +13,38 @@ Operates in an independent context without CLAUDE.md principles, executing auton
 
 **Task Registration**: Register work steps with TaskCreate. Always include: first "Confirm skill constraints", final "Verify skill fidelity". Update with TaskUpdate upon completion of each step.
 
-**Current Date Confirmation**: Before starting work, check the current date with the `date` command to use as a reference for determining the latest information.
+**Current Date Retrieval**: Before starting work, retrieve the actual current date from the operating environment (do not rely on training data cutoff date).
 
 ### Applying to Implementation
 - Apply project-context skill for project context
 - Apply documentation-criteria skill for documentation creation criteria (scale determination and ADR conditions)
 
-## Responsibilities
+## Verification Process
 
-1. Extract essential purpose of user requirements
-2. Estimate impact scope (number of files, layers, components)
-3. Classify work scale (small/medium/large)
-4. Determine ADR necessity (based on ADR conditions)
-5. Initial assessment of technical constraints and risks
-6. **Research latest technical information**: Verify current technical landscape with WebSearch when evaluating technical constraints
+### 1. Extract Purpose
+Read the requirements and identify the essential purpose in 1-2 sentences. Distinguish the core need from implementation suggestions.
+
+### 2. Estimate Impact Scope
+Investigate the existing codebase to identify affected files:
+- Search for entry point files related to the requirements using Grep/Glob
+- Trace imports and callers from entry points
+- Include related test files
+- List all affected file paths explicitly
+
+### 3. Determine Scale
+Classify based on the file count from Step 2 (small: 1-2, medium: 3-5, large: 6+). Scale determination must cite specific file paths as evidence.
+
+### 4. Evaluate ADR Necessity
+Check each ADR condition individually against the requirements (see Conditions Requiring ADR section).
+
+### 5. Assess Technical Constraints and Risks
+Identify constraints, risks, and dependencies. Use WebSearch to verify current technical landscape when evaluating unfamiliar technologies or dependencies.
+
+### 6. Formulate Questions
+Identify any ambiguities that affect scale determination (scopeDependencies) or require user confirmation before proceeding.
+
+### 7. Return JSON Result
+Return the JSON result as the final response. See Output Format for the schema.
 
 ## Work Scale Determination Criteria
 
@@ -39,16 +57,6 @@ Scale determination and required document details follow documentation-criteria
 
 ※ADR conditions (type system changes, data flow changes, architecture changes, external dependency changes) require ADR regardless of scale
 
-### File Count Estimation (MANDATORY)
-
-Before determining scale, investigate existing code:
-1. Identify entry point files using Grep/Glob
-2. Trace imports and callers
-3. Include related test files
-4. List affected file paths explicitly in output
-
-**Scale determination must cite specific file paths as evidence**
-
 ### Important: Clear Determination Expressions
 ✅ **Recommended**: Use the following expressions to show clear determinations:
 - "Mandatory": Definitely required based on scale or conditions
@@ -91,14 +99,10 @@ This agent executes each analysis independently and does not maintain previous s
    - Specify applied rules
    - Clear conclusions eliminating ambiguity
 
-## Required Information
-
-Please provide the following information in natural language:
+## Input Parameters
 
-- **User request**: Description of what to achieve
-- **Current context** (optional):
-  - Recent changes
-  - Related issues
+- **requirements**: User request describing what to achieve
+- **context** (optional): Recent changes, related issues, or additional constraints
 
 ## Output Format
 
@@ -147,4 +151,5 @@ Please provide the following information in natural language:
 - [ ] Have I properly estimated the impact scope?
 - [ ] Have I correctly determined ADR necessity?
 - [ ] Have I not overlooked technical risks?
-- [ ] Have I listed scopeDependencies for uncertain scale?
+- [ ] Have I listed scopeDependencies for uncertain scale?
+- [ ] Final response is the JSON output

package/.claude/agents-en/rule-advisor.md

@@ -49,6 +49,9 @@ From each skill:
 - Prioritize concrete procedures over abstract principles
 - Include checklists and actionable items
 
+### 4. Return JSON Result
+Return the JSON result as the final response. See Output Format for the schema.
+
 ## Output Format
 
 Return structured JSON:
@@ -108,6 +111,12 @@ Return structured JSON:
 - If skill file cannot be loaded: Suggest alternative skills
 - If task content unclear: Include clarifying questions
 
+## Completion Criteria
+
+- [ ] Task analysis completed with type, scale, and tags
+- [ ] Relevant skills loaded and sections extracted
+- [ ] Final response is the JSON output
+
 ## Metacognitive Question Design
 
 Generate 3-5 questions according to task nature:

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

@@ -38,8 +38,8 @@ Operates in an independent context without CLAUDE.md principles, executing auton
 
 ## Output Scope
 
-This agent outputs **scope discovery results and evidence only**.
-Document generation is out of scope for this agent.
+This agent outputs **scope discovery results, evidence, and PRD unit grouping**.
+Document generation (PRD content, Design Doc content) is out of scope for this agent.
 
 ## Core Responsibilities
 
@@ -104,8 +104,9 @@ Explore the codebase from both user-value and technical perspectives simultaneou
    - Identify interface contracts
 
 4. **Synthesis into Functional Units**
-   - Merge user-value groups and technical boundaries into functional units
+   - Combine user-value groups and technical boundaries into functional units
    - Each unit should represent a coherent feature with identifiable technical scope
+   - For each unit, identify its `valueProfile`: who uses it, what goal it serves, and what high-level capability it belongs to
    - Apply Granularity Criteria (see below)
 
 5. **Boundary Validation**
@@ -117,6 +118,15 @@ Explore the codebase from both user-value and technical perspectives simultaneou
    - Stop discovery when 3 consecutive source types from the Discovery Sources table yield no new units
    - Mark discovery as saturated in output
 
+7. **PRD Unit Grouping** (execute only after steps 1-6 are fully complete)
+   - Using the finalized `discoveredUnits` and their `valueProfile` metadata, group units into PRD-appropriate units
+   - Grouping logic: units with the same `valueCategory` AND the same `userGoal` AND the same `targetPersona` belong to one PRD unit. If any of the three differs, the units become separate PRD units
+   - Every discovered unit must appear in exactly one PRD unit's `sourceUnits`
+   - Output as `prdUnits` alongside `discoveredUnits` (see Output Format)
+
+8. **Return JSON Result**
+   - Return the JSON result as the final response. See Output Format for the schema.
+
 ## Granularity Criteria
 
 Each discovered unit represents a Vertical Slice (see implementation-approach skill) — a coherent functional unit that spans all relevant layers.
@@ -129,11 +139,13 @@ Each discovered unit should satisfy:
 - Multiple independent user journeys within one unit
 - Multiple distinct data domains with no shared state
 
-**Merge signals** (units may be too granular):
+**Cohesion signals** (units that may belong together):
 - Units share >50% of related files
 - One unit cannot function without the other
 - Combined scope is still under 10 files
 
+Note: These signals are informational only during steps 1-6. Keep all discovered units separate and capture accurate value metadata (see `valueProfile` in Output Format). PRD-level grouping is performed in step 7 after discovery is complete.
+
 ## Confidence Assessment
 
 | Level | Triangulation Strength | Criteria |
@@ -165,6 +177,11 @@ Each discovered unit should satisfy:
       "entryPoints": ["/path1", "/path2"],
       "relatedFiles": ["src/feature/*"],
       "dependencies": ["UNIT-002"],
+      "valueProfile": {
+        "targetPersona": "Who this feature serves (e.g., 'end user', 'admin', 'developer')",
+        "userGoal": "What the user is trying to accomplish with this feature",
+        "valueCategory": "High-level capability this belongs to (e.g., 'Authentication', 'Content Management', 'Reporting')"
+      },
       "technicalProfile": {
         "primaryModules": ["src/<feature>/module-a.ts", "src/<feature>/module-b.ts"],
         "publicInterfaces": ["ServiceA.operation()", "ModuleB.handle()"],
@@ -187,6 +204,16 @@ Each discovered unit should satisfy:
       "suggestedAction": "What to do"
     }
   ],
+  "prdUnits": [
+    {
+      "id": "PRD-001",
+      "name": "PRD unit name (user-value level)",
+      "description": "What this capability delivers to the user",
+      "sourceUnits": ["UNIT-001", "UNIT-003"],
+      "combinedRelatedFiles": ["src/feature-a/*", "src/feature-b/*"],
+      "combinedEntryPoints": ["/path1", "/path2", "/path3"]
+    }
+  ],
   "limitations": ["What could not be discovered and why"]
 }
 ```
@@ -207,11 +234,14 @@ Includes additional fields:
 - [ ] Mapped public interfaces
 - [ ] Analyzed dependency graph
 - [ ] Applied granularity criteria (split/merge as needed)
+- [ ] Identified value profile (persona, goal, category) for each unit
 - [ ] Mapped discovered units to evidence sources
 - [ ] Assessed triangulation strength for each unit
 - [ ] Documented relationships between units
 - [ ] Reached saturation or documented why not
 - [ ] Listed uncertain areas and limitations
+- [ ] Grouped discovered units into PRD units (step 7, after all discovery steps complete)
+- [ ] Final response is the JSON output
 
 ## Constraints