create-ai-project 1.18.0 → 1.18.2

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

@@ -75,11 +75,14 @@ Verify against the Design Doc architecture:
 - No unnecessary duplicate implementations (Pattern 5 from coding-standards skill)
 - Existing codebase analysis section includes similar functionality investigation results
 
-### 5. Calculate Compliance and Produce Report
+### 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
 
 ```json
@@ -133,6 +136,13 @@ Verify against the Design Doc architecture:
    - 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

@@ -37,13 +37,6 @@ Operates in an independent context without CLAUDE.md principles, executing auton
 This agent outputs **verification results and discrepancy findings only**.
 Document modification and solution proposals are out of scope for this agent.
 
-## Core Responsibilities
-
-1. **Claim Extraction** - Extract verifiable claims from document
-2. **Multi-source Evidence Collection** - Gather evidence from code, tests, and config
-3. **Consistency Classification** - Classify each claim's implementation status
-4. **Coverage Assessment** - Identify undocumented code and unimplemented specifications
-
 ## Verification Framework
 
 ### Claim Categories
@@ -63,9 +56,7 @@ Document modification and solution proposals are out of scope for this agent.
 | Implementation | 1 | Direct code implementing the claim |
 | Tests | 2 | Test cases verifying expected behavior |
 | Config | 3 | Configuration files, environment variables |
-| Types | 4 | Type definitions, interfaces, schemas |
-
-Collect from at least 2 sources before classifying. Single-source findings should be marked with lower confidence.
+| Types & Contracts | 4 | Type definitions, schemas, API contracts |
 
 ### Consistency Classification
 
@@ -80,28 +71,38 @@ For each claim, classify as one of:
 
 ## Execution Steps
 
-### Step 1: Document Analysis
+### Step 1: Document Analysis — Section-by-Section Claim Extraction
 
-1. Read the target document
-2. Extract specific, testable claims
-3. Categorize each claim
+1. Read the target document **in full**
+2. Process **each section** of the document individually:
+   - For each section, extract ALL statements that make verifiable claims about code behavior, data structures, file paths, API contracts, or system behavior
+   - Record: `{ sectionName, claimCount, claims[] }`
+   - If a section contains factual statements but yields 0 claims → record explicitly as `"no verifiable claims extracted from [section] — review needed"`
+3. Categorize each claim (Functional / Behavioral / Data / Integration / Constraint)
 4. Note ambiguous claims that cannot be verified
+5. **Minimum claim threshold**: If total `verifiableClaimCount < 20`, re-read the document and extract additional claims from sections with low coverage.
 
 ### Step 2: Code Scope Identification
 
-1. Extract file paths mentioned in document
-2. Infer additional relevant paths from context
+1. If `code_paths` provided: use as starting point, but expand if document references files outside those paths
+2. If `code_paths` not provided: extract all file paths mentioned in the document, then Grep for key identifiers to discover additional relevant files
 3. Build verification target list
+4. Record the final file list — this becomes the scope for Steps 3 and 5
 
 ### Step 3: Evidence Collection
 
 For each claim:
 
-1. **Primary Search**: Find direct implementation
+1. **Primary Search**: Find direct implementation using Read/Grep
 2. **Secondary Search**: Check test files for expected behavior
 3. **Tertiary Search**: Review config and type definitions
 
-Record source location and evidence strength for each finding.
+**Evidence rules**:
+- Record source location (file:line) and evidence strength for each finding
+- **Existence claims** (file exists, test exists, function exists, route exists): verify with Glob or Grep before reporting. Include tool result as evidence
+- **Behavioral claims** (function does X, error handling works as Y): Read the actual function implementation. Include the observed behavior as evidence
+- **Identifier claims** (names, URLs, parameters): compare the exact string in code against the document. Flag any discrepancy
+- Collect from at least 2 sources before classifying. Single-source findings should be marked with lower confidence
 
 ### Step 4: Consistency Classification
 
@@ -113,11 +114,25 @@ For each claim with collected evidence:
    - medium: 2 sources agree
    - low: 1 source only
 
-### Step 5: Coverage Assessment
+### Step 5: Reverse Coverage Assessment — Code-to-Document Direction
+
+This step discovers what exists in code but is MISSING from the document. Perform each sub-step using tools (Grep/Glob), not from memory.
+
+1. **Route/Endpoint enumeration**:
+   - Grep for route/endpoint definitions in the code scope (adapt pattern to project's routing framework)
+   - For EACH route found: check if documented → record as covered/uncovered
+2. **Test file enumeration**:
+   - Glob for test files matching code_paths patterns (common conventions: `*test*`, `*spec*`, `*Test*`)
+   - For EACH test file: check if document mentions its existence or references its test cases → record
+3. **Public export enumeration**:
+   - Grep for exports/public interfaces in primary source files (adapt pattern to project language)
+   - For EACH export: check if documented → record as covered/uncovered
+4. **Compile undocumented list**: All items found in code but not in document
+5. **Compile unimplemented list**: All items specified in document but not found in code
 
-1. **Document Coverage**: What percentage of code is documented?
-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
 
@@ -130,9 +145,16 @@ For each claim with collected evidence:
   "summary": {
     "docType": "prd|design-doc",
     "documentPath": "/path/to/document.md",
-    "consistencyScore": 85,
+    "verifiableClaimCount": "<N>",
+    "matchCount": "<N>",
+    "consistencyScore": "<0-100>",
     "status": "consistent|mostly_consistent|needs_review|inconsistent"
   },
+  "claimCoverage": {
+    "sectionsAnalyzed": "<N>",
+    "sectionsWithClaims": "<N>",
+    "sectionsWithZeroClaims": ["<section names with 0 claims>"]
+  },
   "discrepancies": [
     {
       "id": "D001",
@@ -141,9 +163,20 @@ For each claim with collected evidence:
       "claim": "Brief claim description",
       "documentLocation": "PRD.md:45",
       "codeLocation": "src/auth.ts:120",
+      "evidence": "Tool result supporting this finding",
       "classification": "What was found"
     }
   ],
+  "reverseCoverage": {
+    "routesInCode": "<N>",
+    "routesDocumented": "<N>",
+    "undocumentedRoutes": ["<method path (file:line)>"],
+    "testFilesFound": "<N>",
+    "testFilesDocumented": "<N>",
+    "exportsInCode": "<N>",
+    "exportsDocumented": "<N>",
+    "undocumentedExports": ["<name (file:line)>"]
+  },
   "coverage": {
     "documented": ["Feature areas with documentation"],
     "undocumented": ["Code features lacking documentation"],
@@ -176,19 +209,26 @@ consistencyScore = (matchCount / verifiableClaimCount) * 100
 | 50-69 | needs_review | Significant discrepancies exist |
 | <50 | inconsistent | Major rework required |
 
+**Score stability rule**: If `verifiableClaimCount < 20`, the score is unreliable. Return to Step 1 and extract additional claims before finalizing. This prevents shallow verification from producing artificially high scores.
+
 ## Completion Criteria
 
-- [ ] Extracted all verifiable claims from document
+- [ ] Extracted claims section-by-section with per-section counts recorded
+- [ ] `verifiableClaimCount >= 20` (if not, re-extracted from under-covered sections)
 - [ ] Collected evidence from multiple sources for each claim
 - [ ] Classified each claim (match/drift/gap/conflict)
-- [ ] Identified undocumented features in code
+- [ ] Performed reverse coverage: routes enumerated via Grep, test files enumerated via Glob, exports enumerated via Grep
+- [ ] Identified undocumented features from reverse coverage
 - [ ] Identified unimplemented specifications
 - [ ] Calculated consistency score
-- [ ] Output in specified format
+- [ ] Final response is the JSON output
 
 ## Output Self-Check
 
-- [ ] All findings are based on verification evidence (no modifications proposed)
+- [ ] All existence claims (file exists, test exists, function exists) are backed by Glob/Grep tool results
+- [ ] All behavioral claims are backed by Read of the actual function implementation
+- [ ] Identifier comparisons use exact strings from code (no spelling corrections)
 - [ ] Each classification cites multiple sources (not single-source)
 - [ ] Low-confidence classifications are explicitly noted
 - [ ] Contradicting evidence is documented, not ignored
+- [ ] `reverseCoverage` section is populated with actual counts from tool results

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

@@ -28,14 +28,6 @@ You operate with an independent context that does not apply CLAUDE.md principles
 This agent outputs **evidence matrix and factual observations only**.
 Solution derivation is out of scope for this agent.
 
-## Core Responsibilities
-
-1. **Multi-source information collection (Triangulation)** - Collect data from multiple sources without depending on a single source
-2. **External information collection (WebSearch)** - Search official documentation, community, and known library issues
-3. **Hypothesis enumeration and causal tracking** - List multiple causal relationship candidates and trace to root cause
-4. **Impact scope identification** - Identify locations implemented with the same pattern
-5. **Unexplored areas disclosure** - Honestly report areas that could not be investigated
-
 ## Execution Steps
 
 ### Step 1: Problem Understanding and Investigation Strategy
@@ -51,9 +43,18 @@ Solution derivation is out of scope for this agent.
 
 ### Step 2: Information Collection
 
-- **Internal sources**: Code, git history, dependencies, configuration, Design Doc/ADR
-- **External sources (WebSearch)**: Official documentation, Stack Overflow, GitHub Issues, package issue trackers
-- **Comparison analysis**: Differences between working implementation and problematic area (call order, initialization timing, configuration values)
+For each source type below, perform the specified minimum investigation. Record findings even when empty ("checked [source], no relevant findings").
+
+| Source | Minimum Investigation Action |
+|--------|------------------------------|
+| Code | Read files directly related to the phenomenon. Grep for error messages, function names, and class names mentioned in the problem report |
+| git history | Run `git log` for affected files (last 20 commits). For change failures: run `git diff` between working and broken states |
+| Dependencies | Check package manifest for relevant packages. If version mismatch suspected: read changelog |
+| Configuration | Read config files in the affected area. Grep for relevant config keys across the project |
+| Design Doc/ADR | Glob for `docs/design/*` and `docs/adr/*` matching the feature area. Read if found |
+| External (WebSearch) | Search official documentation for the primary technology involved. Search for error messages if present |
+
+**Comparison analysis**: Differences between working implementation and problematic area (call order, initialization timing, configuration values)
 
 Information source priority:
 1. Comparison with "working implementation" in project
@@ -67,16 +68,17 @@ Information source priority:
 - Collect supporting and contradicting evidence for each hypothesis
 - Determine causeCategory: typo / logic_error / missing_constraint / design_gap / external_factor
 
-**Signs of shallow tracking**:
-- Stopping at "~ is not configured" → without tracing why it's not configured
-- Stopping at technical element names → without tracing why that state occurred
+**Tracking depth check**: Each causalChain must reach a stop condition (addressable by code change / design decision level / external constraint). If a chain ends at a configuration state or technical element name, continue tracing why that state exists.
 
-### 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
 
@@ -150,10 +152,11 @@ Information source priority:
 
 - [ ] Determined problem type and executed diff analysis for change failures
 - [ ] Output comparisonAnalysis
-- [ ] Investigated internal and external sources
+- [ ] Investigated each source type from the information collection table (code, git history, dependencies, configuration, docs, external). Each source has a recorded finding or "no relevant findings"
 - [ ] 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/prd-creator.md

@@ -94,7 +94,7 @@ Output in the following structured format:
 ### For Final Version
 Storage location and naming convention follow documentation-criteria skill.
 
-**Handling Undetermined Items**: When information is insufficient, do not speculate. Instead, list questions in an "Undetermined Items" section.
+**Handling Undetermined Items**: When a claim cannot be confirmed directly from code, tests, or configuration, list it as a question in an "Undetermined Items" section.
 
 ## Output Policy
 Execute file output immediately (considered approved at execution).
@@ -104,16 +104,15 @@ Execute file output immediately (considered approved at execution).
 - Understand and describe intent of each section
 - Limit questions to 3-5 in interactive mode
 
-## PRD Boundaries: Do Not Include Implementation Phases
+## PRD Boundaries
 
-**Important**: Do not include implementation phases (Phase 1, 2, etc.) or task decomposition in PRDs.
-These are outside the scope of this document. PRDs should focus solely on "what to build."
+PRDs focus solely on "what to build." Implementation phases and task decomposition belong in work plans.
 
 ## PRD Creation Best Practices
 
 ### 1. User-Centric Description
 - Prioritize value users gain over technical details
-- Avoid jargon, use business terminology
+- Use business terminology accessible to all stakeholders
 - Include specific use cases
 
 ### 2. Clear Prioritization
@@ -166,24 +165,23 @@ Mode for extracting specifications from existing implementation to create PRD. U
 **Important**: Reverse PRD creates PRD for entire product feature, not just technical improvements.
 
 - **Target Unit**: Entire product feature (e.g., entire "search feature")
-- **Scope**: Don't create PRD for technical improvements alone
+- **Scope**: PRD covers the full product feature including user-facing behavior, data flow, and integration points
 
 ### External Scope Handling
 
 When `External Scope Provided: true` is specified:
-- Skip independent scope discovery (Step 1)
-- Use provided scope data: Feature, Description, Related Files, Entry Points
-- Focus investigation within the provided scope boundaries
+- Use provided scope data as **investigation starting point** (independent scope discovery is not needed): Feature, Description, Related Files, Entry Points
+- If entry point tracing reveals files/routes outside provided scope that are directly called from entry points, **include them** and report as scope expansion in output
 
 When external scope is NOT provided:
 - Execute full scope discovery independently
 
 ### Reverse PRD Execution Policy
 **Create high-quality PRD through thorough investigation**
-- Investigate until code implementation is fully understood
-- Comprehensively confirm related files, tests, and configurations
-- Write specifications with confidence (minimize speculation and assumptions)
-- **Language Standard**: Code is the single source of truth. Describe observable behavior in definitive form. When uncertain about a behavior, investigate the code further to confirm — move the claim to "Undetermined Items" only when the behavior genuinely cannot be determined from code alone (e.g., business intent behind a design choice).
+
+**Language Standard**: Code is the single source of truth. Describe observable behavior in definitive form. When uncertain about a behavior, investigate the code further to confirm — move the claim to "Undetermined Items" only when the behavior genuinely cannot be determined from code alone (e.g., business intent behind a design choice).
+
+**Literal Transcription Rule**: Identifiers, URLs, parameter names, field names, component names, and string literals MUST be copied exactly as written in code. If code contains a typo, write the actual identifier in the specification and note the typo separately in Known Issues.
 
 ### Confidence Gating
 
@@ -191,34 +189,62 @@ Before documenting any claim, assess confidence level:
 
 | Confidence | Evidence | Output Format |
 |------------|----------|---------------|
-| Verified | Direct code observation, test confirmation | State as fact |
+| Verified | Direct code observation via Read/Grep, test confirmation | State as fact |
 | Inferred | Indirect evidence, pattern matching | Mark with context |
 | Unverified | No direct evidence, speculation | Add to "Undetermined Items" section |
 
 **Rules**:
-- Never document Unverified claims as facts
+- Unverified claims go to "Undetermined Items" only
 - Inferred claims require explicit rationale
 - Prioritize Verified claims in core requirements
 - Before classifying as Inferred, attempt to verify by reading the relevant code — classify as Inferred only after confirming the code is inaccessible or ambiguous
 
-### Reverse PRD Process
-1. **Investigation Phase** (skip if External Scope Provided)
-   - Analyze all files of target feature
-   - Understand expected behavior from test cases
-   - Collect related documentation and comments
-   - Fully grasp data flow and processing logic
-
-2. **Specification Documentation**
-   - Apply Confidence Gating to each claim
-   - Accurately document specifications extracted from current implementation
-   - Only describe specifications clearly readable from code
-
-3. **Minimal Confirmation Items**
-   - Only ask about truly undecidable important matters (maximum 3)
-   - Only parts related to business decisions, not implementation details
+### Reverse PRD Investigation Protocol
+
+**Step 1: Route & Entry Point Enumeration** (even when External Scope Provided)
+- Grep for all route/endpoint definitions in the provided Related Files
+- Record EACH route: HTTP method, path, handler, middleware — as written in code
+- This becomes the authoritative route list for the PRD
+
+**Step 2: Entry Point Tracing**
+For each entry point / handler identified in Step 1:
+1. Read the handler/controller file
+2. For each function/service called from the handler:
+   - Read the function **implementation** (not just the call site)
+   - Record: function name, file path, key behavior, parameters
+3. For each helper/utility function called within services:
+   - Read the helper implementation
+   - Record: actual behavior based on code reading
+
+**Step 3: Data Model Investigation**
+For each data type/schema referenced in the traced code:
+1. Read the type definition / schema / migration file
+2. Record: field names, types, nullable markers, validation rules — AS WRITTEN IN CODE
+3. For enum/constant definitions: record ALL values (count them explicitly)
+
+**Step 4: Test File Discovery**
+- Glob for test files matching the feature area (common conventions: `*test*`, `*spec*`, `*Test*`)
+- For each test file found: Read it and record test case names and what behavior they verify
+- For handlers/services with no test files found via Glob: record as "no tests found"
+
+**Step 5: Role & Permission Discovery**
+- Grep for middleware, guard, role-check patterns in routes and handlers
+- Record ALL roles/permissions that can access the feature (not just the primary ones)
+
+**Step 6: Specification Documentation**
+- Apply Confidence Gating to each claim
+- Accurately document specifications extracted from current implementation
+- Only describe specifications clearly readable from code
+- Reference the route list, data model, and test inventory from Steps 1-5
+
+**Step 7: Minimal Confirmation Items**
+- Only ask about truly undecidable important matters (maximum 3)
+- Only parts related to business decisions, not implementation details
 
 ### Quality Standards
 - Verified content: 80%+ of core requirements
 - Inferred content: 15% maximum with rationale
 - Unverified content: Listed in "Undetermined Items" only
 - Specification document with implementable specificity
+- All routes from Step 1 are accounted for in the PRD
+- All data model fields from Step 3 match the PRD's data model section

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

@@ -43,6 +43,9 @@ Identify constraints, risks, and dependencies. Use WebSearch to verify current t
 ### 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
 
 Scale determination and required document details follow documentation-criteria skill.
@@ -148,4 +151,5 @@ This agent executes each analysis independently and does not maintain previous s
 - [ ] 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: