create-claude-webapp 1.0.0 → 1.0.1

package/.claude/commands/diagnose.md

@@ -0,0 +1,202 @@
+---
+description: Investigate problem, verify findings, and derive solutions
+---
+
+**Command Context**: Diagnosis flow to identify root cause and present solutions
+
+Target problem: $ARGUMENTS
+
+**Role**: Orchestrator
+
+**Execution Method**:
+- Investigation → performed by investigator
+- Verification → performed by verifier
+- Solution derivation → performed by solver
+
+Orchestrator invokes sub-agents and passes structured JSON between them.
+
+**TodoWrite Registration**: Register execution steps in TodoWrite and proceed systematically
+
+## Step 0: Problem Structuring (Before investigator invocation)
+
+### 0.1 Problem Type Determination
+
+| Type | Criteria |
+|------|----------|
+| Change Failure | Indicates some change occurred before the problem appeared |
+| New Discovery | No relation to changes is indicated |
+
+If uncertain, ask the user whether any changes were made right before the problem occurred.
+
+### 0.2 Information Supplementation for Change Failures
+
+If the following are unclear, **ask with AskUserQuestion** before proceeding:
+- What was changed (cause change)
+- What broke (affected area)
+- Relationship between both (shared components, etc.)
+
+### 0.3 Problem Essence Understanding
+
+**Invoke rule-advisor via Task tool**:
+```
+subagent_type: rule-advisor
+prompt: Identify the essence and required rules for this problem: [Problem reported by user]
+```
+
+Confirm from rule-advisor output:
+- `taskAnalysis.mainFocus`: Primary focus of the problem
+- `mandatoryChecks.taskEssence`: Root problem beyond surface symptoms
+- `selectedRules`: Applicable rule sections
+- `warningPatterns`: Patterns to avoid
+
+### 0.4 Reflecting in investigator Prompt
+
+**Include the following in investigator prompt**:
+1. Problem essence (taskEssence)
+2. Key applicable rules summary (from selectedRules)
+3. Investigation focus (investigationFocus): Convert warningPatterns to "points prone to confusion or oversight in this investigation"
+4. **For change failures, additionally include**:
+   - Detailed analysis of the change content
+   - Commonalities between cause change and affected area
+   - Determination of whether the change is a "correct fix" or "new bug" with comparison baseline selection
+
+## Diagnosis Flow Overview
+
+```
+Problem → investigator → verifier → solver ─┐
+                 ↑                          │
+                 └── confidence < high ─────┘
+                      (max 2 iterations)
+
+confidence=high reached → Report
+```
+
+**Context Separation**: Pass only structured JSON output to each step. Each step starts fresh with the JSON data only.
+
+## Execution Steps
+
+Register the following in TodoWrite and execute:
+
+### Step 1: Investigation (investigator)
+
+**Task tool invocation**:
+```
+subagent_type: investigator
+prompt: Comprehensively collect information related to the following phenomenon.
+
+Phenomenon: [Problem reported by user]
+```
+
+**Expected output**: Evidence matrix, comparison analysis results, causal tracking results, list of unexplored areas, investigation limitations
+
+### Step 2: Investigation Quality Check
+
+Review investigation output:
+
+**Quality Check** (verify JSON output contains the following):
+- [ ] comparisonAnalysis
+- [ ] causalChain for each hypothesis (reaching stop condition)
+- [ ] causeCategory for each hypothesis
+- [ ] Investigation covering investigationFocus items (when provided)
+
+**If quality insufficient**: Re-run investigator specifying missing items
+
+**design_gap Escalation**:
+
+When investigator output contains `causeCategory: design_gap` or `recurrenceRisk: high`:
+1. **Insert user confirmation before verifier execution**
+2. Use AskUserQuestion:
+   "A design-level issue was detected. How should we proceed?"
+   - A: Attempt fix within current design
+   - B: Include design reconsideration
+3. If user selects B, pass `includeRedesign: true` to solver
+
+Proceed to verifier once quality is satisfied.
+
+### Step 3: Verification (verifier)
+
+**Task tool invocation**:
+```
+subagent_type: verifier
+prompt: Verify the following investigation results.
+
+Investigation results: [Investigation JSON output]
+```
+
+**Expected output**: Alternative hypotheses (at least 3), Devil's Advocate evaluation, final conclusion, confidence
+
+**Confidence Criteria**:
+- **high**: No uncertainty affecting solution selection or implementation
+- **medium**: Uncertainty exists but resolvable with additional investigation
+- **low**: Fundamental information gap exists
+
+### Step 4: Solution Derivation (solver)
+
+**Task tool invocation**:
+```
+subagent_type: solver
+prompt: Derive solutions based on the following verified conclusion.
+
+Causes: [verifier's conclusion.causes]
+Causes relationship: [causesRelationship: independent/dependent/exclusive]
+Confidence: [high/medium/low]
+```
+
+**Expected output**: Multiple solutions (at least 3), tradeoff analysis, recommendation and implementation steps, residual risks
+
+**Completion condition**: confidence=high
+
+**When not reached**:
+1. Return to Step 1 with uncertainties identified by solver as investigation targets
+2. Maximum 2 additional investigation iterations
+3. After 2 iterations without reaching high, present user with options:
+   - Continue additional investigation
+   - Execute solution at current confidence level
+
+### Step 5: Final Report Creation
+
+**Prerequisite**: confidence=high achieved
+
+After diagnosis completion, report to user in the following format:
+
+```
+## Diagnosis Result Summary
+
+### Identified Causes
+[Cause list from verification results]
+- Causes relationship: [independent/dependent/exclusive]
+
+### Verification Process
+- Investigation scope: [Scope confirmed in investigation]
+- Additional investigation iterations: [0/1/2]
+- Alternative hypotheses count: [Number generated in verification]
+
+### Recommended Solution
+[Solution derivation recommendation]
+
+Rationale: [Selection rationale]
+
+### Implementation Steps
+1. [Step 1]
+2. [Step 2]
+...
+
+### Alternatives
+[Alternative description]
+
+### Residual Risks
+[solver's residualRisks]
+
+### Post-Resolution Verification Items
+- [Verification item 1]
+- [Verification item 2]
+```
+
+## Completion Criteria
+
+- [ ] Executed investigator and obtained evidence matrix, comparison analysis, and causal tracking
+- [ ] Performed investigation quality check and re-ran if insufficient
+- [ ] Executed verifier and obtained confidence level
+- [ ] Executed solver
+- [ ] Achieved confidence=high (or obtained user approval after 2 additional iterations)
+- [ ] Presented final report to user

package/.claude/commands/front-build.md

@@ -0,0 +1,116 @@
+---
+description: Execute frontend implementation in autonomous execution mode
+---
+
+## Orchestrator Definition
+
+**Core Identity**: "I am not a worker. I am an orchestrator." (see subagents-orchestration-guide skill)
+
+**Execution Method**:
+- Task decomposition → performed by task-decomposer
+- Frontend implementation → performed by task-executor-frontend
+- Quality checks and fixes → performed by quality-fixer-frontend
+- Commits → performed by orchestrator (Bash tool)
+
+Orchestrator invokes sub-agents and passes structured JSON between them.
+
+**CRITICAL**: Run quality-fixer-frontend before every commit. Obtain batch approval before autonomous mode.
+
+Work plan: $ARGUMENTS
+
+## Pre-execution Prerequisites
+
+### Task File Existence Check
+```bash
+# Check work plans
+! ls -la docs/plans/*.md | grep -v template | tail -5
+
+# Check task files
+! ls docs/plans/tasks/*.md 2>/dev/null || echo "⚠️ No task files found"
+```
+
+### Task Generation Decision Flow
+
+**Think deeply**: Analyze task file existence state and determine the appropriate action:
+
+| State | Criteria | Next Action |
+|-------|----------|-------------|
+| Tasks exist | .md files in tasks/ directory | Proceed to autonomous execution |
+| No tasks + plan exists | Plan exists but no task files | Confirm with user → run task-decomposer |
+| Neither exists | No plan or task files | Error: Prerequisites not met |
+
+## Task Decomposition Phase (Conditional)
+
+When task files don't exist:
+
+### 1. User Confirmation
+```
+No task files found.
+Work plan: docs/plans/[plan-name].md
+
+Generate tasks from the work plan? (y/n):
+```
+
+### 2. Task Decomposition (if approved)
+```
+@task-decomposer Read work plan and decompose into atomic tasks:
+- Input: docs/plans/[plan-name].md
+- Output: Individual task files in docs/plans/tasks/
+- Granularity: 1 task = 1 commit = independently executable
+```
+
+### 3. Verify Generation
+```bash
+# Verify generated task files
+! ls -la docs/plans/tasks/*.md | head -10
+```
+
+✅ **Flow**: Task generation → Autonomous execution (in this order)
+
+## Task Execution Cycle (4-Step Cycle) - Frontend Specialized
+
+**MANDATORY EXECUTION CYCLE**: `task-executor-frontend → escalation check → quality-fixer-frontend → commit`
+
+### Sub-agent Invocation Method
+Use Task tool to invoke sub-agents:
+- `subagent_type`: Agent name
+- `description`: Brief task description (3-5 words)
+- `prompt`: Specific instructions
+
+### Structured Response Specification
+Each sub-agent responds in JSON format:
+- **task-executor-frontend**: status, filesModified, testsAdded, readyForQualityCheck
+- **quality-fixer-frontend**: status, checksPerformed, fixesApplied, approved
+
+### Execution Flow for Each Task
+
+For EACH task, YOU MUST:
+
+1. **UPDATE TodoWrite**: Register work steps. Always include: first "Confirm skill constraints", final "Verify skill fidelity"
+2. **USE task-executor-frontend**: Execute frontend implementation
+   - Invocation example: `subagent_type: "task-executor-frontend"`, `description: "Task execution"`, `prompt: "Task file: docs/plans/tasks/[filename].md Execute implementation"`
+3. **CHECK ESCALATION**: Check task-executor-frontend status → If `status: "escalation_needed"` → STOP and escalate to user
+4. **PROCESS structured responses**: When `readyForQualityCheck: true` is detected → EXECUTE quality-fixer-frontend IMMEDIATELY
+5. **USE quality-fixer-frontend**: Execute all quality checks (Biome, TypeScript build, tests)
+   - Invocation example: `subagent_type: "quality-fixer-frontend"`, `description: "Quality check"`, `prompt: "Execute all frontend quality checks and fixes"`
+6. **EXECUTE commit**: After `approved: true` confirmation, execute git commit IMMEDIATELY
+
+### Quality Assurance During Autonomous Execution (Details)
+- task-executor-frontend execution → escalation check → quality-fixer-frontend execution → **orchestrator executes commit** (using Bash tool)
+- After quality-fixer-frontend's `approved: true` confirmation, execute git commit IMMEDIATELY
+- Use `changeSummary` for commit message
+
+**CRITICAL**: Monitor ALL structured responses WITHOUT EXCEPTION and ENSURE every quality gate is passed.
+
+! ls -la docs/plans/*.md | head -10
+
+Verify approval status before proceeding. Once confirmed, initiate autonomous execution mode. Stop immediately upon detecting any requirement changes.
+
+## Output Example
+Frontend implementation phase completed.
+- Task decomposition: Generated under docs/plans/tasks/
+- Implemented tasks: [number] tasks
+- Quality checks: All passed (Biome, TypeScript build, tests)
+- Commits: [number] commits created
+
+**Important**: This command manages the entire autonomous execution flow for frontend implementation from task decomposition to completion. Automatically uses frontend-specialized agents (task-executor-frontend, quality-fixer-frontend).

package/.claude/commands/front-design.md

@@ -0,0 +1,61 @@
+---
+description: Execute from requirement analysis to frontend design document creation
+---
+
+**Command Context**: This command is dedicated to the frontend design phase.
+
+## Orchestrator Definition
+
+**Role**: Orchestrator
+
+**Execution Method**:
+- Requirement analysis → performed by requirement-analyzer
+- Design document creation → performed by technical-designer-frontend
+- Document review → performed by document-reviewer
+
+Orchestrator invokes sub-agents and passes structured JSON between them.
+
+## Scope Boundaries
+
+**Included in this command**:
+- Requirement analysis with requirement-analyzer
+- ADR creation (if architecture changes, new technology, or data flow changes)
+- Design Doc creation with technical-designer-frontend
+- Document review with document-reviewer
+
+**Responsibility Boundary**: This command completes with design document approval.
+
+Requirements: $ARGUMENTS
+
+## Execution Flow
+
+### 1. Requirement Analysis Phase
+**Think harder**: Considering the deep impact on design, first engage in dialogue to understand the background and purpose of requirements:
+- What problems do you want to solve?
+- Expected outcomes and success criteria
+- Relationship with existing systems
+
+Once requirements are moderately clarified:
+- Invoke **requirement-analyzer** using Task tool
+  - `subagent_type: "requirement-analyzer"`
+  - `description: "Requirement analysis"`
+  - `prompt: "Requirements: [user requirements] Execute requirement analysis and scale determination"`
+- **[STOP]**: Review requirement analysis results and address question items
+
+### 2. Design Document Creation Phase
+Create appropriate design documents according to scale determination:
+- Invoke **technical-designer-frontend** using Task tool
+  - For ADR: `subagent_type: "technical-designer-frontend"`, `description: "ADR creation"`, `prompt: "Create ADR for [technical decision]"`
+  - For Design Doc: `subagent_type: "technical-designer-frontend"`, `description: "Design Doc creation"`, `prompt: "Create Design Doc based on requirements"`
+- Invoke **document-reviewer** to verify consistency
+  - `subagent_type: "document-reviewer"`, `description: "Document review"`, `prompt: "Review [document path] for consistency and completeness"`
+- **[STOP]**: Present design alternatives and trade-offs, obtain user approval
+
+**Scope**: Up to frontend design document (ADR/Design Doc) approval. Work planning and beyond are outside the scope of this command.
+
+## Output Example
+Frontend design phase completed.
+- Design document: docs/design/[document-name].md or docs/adr/[document-name].md
+- Approval status: User approved
+
+**Important**: This command ends with design approval. Does not propose transition to next phase.

package/.claude/commands/front-plan.md

@@ -0,0 +1,53 @@
+---
+description: Create frontend work plan from design document and obtain plan approval
+---
+
+**Command Context**: This command is dedicated to the frontend planning phase.
+
+## Orchestrator Definition
+
+**Role**: Orchestrator
+
+**Execution Method**:
+- Work plan creation → performed by work-planner
+
+Orchestrator invokes sub-agents and passes structured JSON between them.
+
+## Scope Boundaries
+
+**Included in this command**:
+- Design document selection
+- Work plan creation with work-planner
+- Plan approval obtainment
+
+**Responsibility Boundary**: This command completes with work plan approval.
+
+Create frontend work plan with the following process:
+
+## Execution Process
+
+### 1. Design Document Selection
+! ls -la docs/design/*.md | head -10
+- Check for existence of design documents, notify user if none exist
+- Present options if multiple exist (can be specified with $ARGUMENTS)
+
+### 2. Work Plan Creation
+Invoke **work-planner** using Task tool:
+- `subagent_type: "work-planner"`
+- `description: "Work plan creation"`
+- `prompt: "Create work plan from Design Doc at [path]"`
+- Interact with user to complete plan and obtain approval for plan content
+
+**Think deeply** Create a work plan from the selected design document, clarifying specific implementation steps and risks.
+
+**Scope**: Up to work plan creation and obtaining approval for plan content.
+
+## Response at Completion
+✅ **Recommended**: End with the following standard response after plan content approval
+```
+Frontend planning phase completed.
+- Work plan: docs/plans/[plan-name].md
+- Status: Approved
+
+Please provide separate instructions for implementation.
+```

package/.claude/commands/front-reverse-design.md

@@ -0,0 +1,183 @@
+---
+name: front-reverse-design
+description: Generate frontend Design Docs from existing codebase using existing PRD
+---
+
+**Command Context**: Reverse engineering workflow to create frontend Design Docs from existing code
+
+**Prerequisites**: PRD must exist (created via reverse-engineer or manually)
+
+Target PRD: $ARGUMENTS
+
+**TodoWrite**: Register phases first, then steps within each phase as you enter it.
+
+## Step 0: Initial Configuration
+
+### 0.1 Scope Confirmation
+
+Use AskUserQuestion to confirm:
+1. **PRD path**: Which PRD to use as basis
+2. **Target path**: Which frontend directory/module to document
+3. **Human review**: Yes (recommended) / No (fully autonomous)
+
+### 0.2 Output Configuration
+
+- Design Doc output: `docs/design/` or existing design directory
+- Verify directories exist, create if needed
+
+## Workflow Overview
+
+```
+Step 1: Scope Discovery (all frontend components per PRD)
+Step 2-5: Per-component loop (Generation -> Verification -> Review -> Revision)
+```
+
+**Context Passing**: Pass structured JSON output between steps. Use `$STEP_N_OUTPUT` placeholder notation.
+
+## Step 1: Design Doc Scope Discovery
+
+**Task invocation**:
+```
+subagent_type: scope-discoverer
+prompt: |
+  Discover frontend Design Doc targets within PRD scope.
+
+  scope_type: design-doc
+  existing_prd: $USER_PRD_PATH
+  target_path: $USER_TARGET_PATH
+  focus: frontend (React/TypeScript components, hooks, state management)
+```
+
+**Store output as**: `$STEP_1_OUTPUT`
+
+**Quality Gate**:
+- At least one component discovered -> proceed
+- No components -> ask user for hints
+
+**Human Review Point** (if enabled): Present discovered components for confirmation.
+
+## Step 2-5: Per-Component Processing
+
+**Complete Steps 2->3->4->5 for each component before proceeding to the next component.**
+
+### Step 2: Design Doc Generation
+
+**Task invocation**:
+```
+subagent_type: technical-designer-frontend
+prompt: |
+  Create Design Doc for the following frontend component based on existing code.
+
+  Operation Mode: create
+
+  Component: $COMPONENT_NAME (from $STEP_1_OUTPUT)
+  Responsibility: $COMPONENT_RESPONSIBILITY
+  Primary Files: $COMPONENT_PRIMARY_FILES
+  Public Interfaces: $COMPONENT_PUBLIC_INTERFACES
+  Dependencies: $COMPONENT_DEPENDENCIES
+
+  Parent PRD: $USER_PRD_PATH
+
+  Document current architecture. Do not propose changes.
+```
+
+**Store output as**: `$STEP_2_OUTPUT`
+
+### Step 3: Code Verification
+
+**Task invocation**:
+```
+subagent_type: code-verifier
+prompt: |
+  Verify consistency between Design Doc and code implementation.
+
+  doc_type: design-doc
+  document_path: $STEP_2_OUTPUT
+  code_paths: $COMPONENT_PRIMARY_FILES
+  verbose: false
+```
+
+**Store output as**: `$STEP_3_OUTPUT`
+
+**Quality Gate**:
+- consistencyScore >= 70 -> proceed to review
+- consistencyScore < 70 -> flag for detailed review
+
+### Step 4: Review
+
+**Required Input**: $STEP_3_OUTPUT (verification JSON from Step 3)
+
+**Task invocation**:
+```
+subagent_type: document-reviewer
+prompt: |
+  Review the following Design Doc considering code verification findings.
+
+  doc_type: DesignDoc
+  target: $STEP_2_OUTPUT
+  mode: composite
+
+  ## Code Verification Results
+  $STEP_3_OUTPUT
+
+  ## Parent PRD
+  $USER_PRD_PATH
+
+  ## Additional Review Focus
+  - Technical accuracy of documented interfaces
+  - Consistency with parent PRD scope
+  - Completeness of component boundary definitions
+```
+
+**Store output as**: `$STEP_4_OUTPUT`
+
+### Step 5: Revision (conditional)
+
+**Trigger Conditions** (any one of the following):
+- Review status is "Needs Revision" or "Rejected"
+- Critical discrepancies exist in `$STEP_3_OUTPUT`
+- consistencyScore < 70
+
+**Task invocation**:
+```
+subagent_type: technical-designer-frontend
+prompt: |
+  Update Design Doc based on review feedback.
+
+  Operation Mode: update
+  Existing Design Doc: $STEP_2_OUTPUT
+
+  ## Review Feedback
+  $STEP_4_OUTPUT
+
+  ## Discrepancies to Address
+  (Extract critical and major discrepancies from $STEP_3_OUTPUT)
+
+  Apply corrections and improvements.
+```
+
+**Loop Control**: Maximum 2 revision cycles. After 2 cycles, flag for human review regardless of status.
+
+### Component Completion
+
+- [ ] Review status is "Approved" or "Approved with Conditions"
+- [ ] Human review passed (if enabled in Step 0)
+
+**Next**: Proceed to next component. After all components -> Final Report.
+
+## Final Report
+
+Output summary including:
+- Generated documents table (Component, Design Doc Path, Consistency Score, Review Status)
+- Action items (critical discrepancies, undocumented features, flagged items)
+- Next steps checklist
+
+## Error Handling
+
+| Error | Action |
+|-------|--------|
+| PRD not found | Ask user for correct PRD path |
+| Discovery finds nothing | Ask user for project structure hints |
+| Generation fails | Log failure, continue with other components, report in summary |
+| consistencyScore < 50 | Flag for mandatory human review, do not auto-approve |
+| Review rejects after 2 revisions | Stop loop, flag for human intervention |

package/.claude/commands/front-review.md

@@ -0,0 +1,89 @@
+---
+name: front-review
+description: Design Doc compliance validation with optional auto-fixes
+---
+
+**Command Context**: Post-implementation quality assurance command for React/TypeScript frontend
+
+## Execution Method
+
+- Compliance validation -> performed by code-reviewer
+- Rule analysis -> performed by rule-advisor
+- Fix implementation -> performed by task-executor-frontend
+- Quality checks -> performed by quality-fixer-frontend
+- Re-validation -> performed by code-reviewer
+
+Orchestrator invokes sub-agents and passes structured JSON between them.
+
+Design Doc (uses most recent if omitted): $ARGUMENTS
+
+**Think deeply** Understand the essence of compliance validation and execute:
+
+## Execution Flow
+
+### 1. Prerequisite Check
+```bash
+# Identify Design Doc
+ls docs/design/*.md | grep -v template | tail -1
+
+# Check implementation files
+git diff --name-only main...HEAD
+```
+
+### 2. Execute code-reviewer
+Validate Design Doc compliance:
+- Acceptance criteria fulfillment
+- Code quality check
+- Implementation completeness assessment
+
+### 3. Verdict and Response
+
+**Criteria (considering project stage)**:
+- Prototype: Pass at 70%+
+- Production: 90%+ recommended
+- Critical items (security, etc.): Required regardless of rate
+
+**Compliance-based response**:
+
+For low compliance (production <90%):
+```
+Validation Result: [X]% compliance
+Unfulfilled items:
+- [item list]
+
+Execute fixes? (y/n):
+```
+
+If user selects `y`:
+
+## Pre-fix Metacognition
+**Required**: `rule-advisor -> TodoWrite -> task-executor-frontend -> quality-fixer-frontend`
+
+1. **Execute rule-advisor**: Understand fix essence (symptomatic treatment vs root solution)
+2. **Update TodoWrite**: Register work steps. Always include: first "Confirm skill constraints", final "Verify skill fidelity". Create task file following task template (see documentation-criteria skill) -> `docs/plans/tasks/review-fixes-YYYYMMDD.md`
+3. **Execute task-executor-frontend**: Staged auto-fixes (stops at 5 files)
+4. **Execute quality-fixer-frontend**: Confirm quality gate passage
+5. **Re-validate**: Measure improvement with code-reviewer
+
+### 4. Final Report
+```
+Initial compliance: [X]%
+Final compliance: [Y]% (if fixes executed)
+Improvement: [Y-X]%
+
+Remaining issues:
+- [items requiring manual intervention]
+```
+
+## Auto-fixable Items
+- Simple unimplemented acceptance criteria
+- Error handling additions
+- Contract definition fixes
+- Function splitting (length/complexity improvements)
+
+## Non-fixable Items
+- Fundamental business logic changes
+- Architecture-level modifications
+- Design Doc deficiencies
+
+**Scope**: Design Doc compliance validation and auto-fixes.