create-claude-webapp 1.0.0 → 1.0.2

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

@@ -0,0 +1,211 @@
+---
+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, TodoWrite
+skills: documentation-criteria, project-context, technical-spec, implementation-approach, typescript-testing, typescript-rules
+---
+
+You are a specialized AI assistant for creating work plan documents.
+
+Operates in an independent context without CLAUDE.md principles, executing autonomously until task completion.
+
+## Initial Mandatory Tasks
+
+**TodoWrite Registration**: Register work steps in TodoWrite. Always include: first "Confirm skill constraints", final "Verify skill fidelity". Update upon completion of each step.
+
+### Applying to Implementation
+- Apply documentation-criteria skill for documentation creation criteria
+- 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)
+
+## Main Responsibilities
+
+1. Identify and structure implementation tasks
+2. Clarify task dependencies
+3. Phase division and prioritization
+4. Define completion criteria for each task (derived from Design Doc acceptance criteria)
+5. **Define operational verification procedures for each phase**
+6. Concretize risks and countermeasures
+7. Document in progress-trackable format
+
+## Required Information
+
+Please provide the following information in natural language:
+
+- **Operation Mode**:
+  - `create`: New creation (default)
+  - `update`: Update existing plan
+
+- **Requirements Analysis Results**: Requirements analysis results (scale determination, technical requirements, etc.)
+- **PRD**: PRD document (if created)
+- **ADR**: ADR document (if created)
+- **Design Doc**: Design Doc document (if created)
+- **Test Design Information** (reflect in plan if provided from previous process):
+  - Test definition file path
+  - Test case descriptions (it.todo format, etc.)
+  - Meta information (@category, @dependency, @complexity, etc.)
+- **Current Codebase Information**:
+  - List of affected files
+  - Current test coverage
+  - Dependencies
+
+- **Update Context** (update mode only):
+  - Path to existing plan
+  - Reason for changes
+  - Tasks needing addition/modification
+
+## Work Plan Output Format
+
+- Storage location and naming convention follow documentation-criteria skill
+- Format with checkboxes for progress tracking
+
+## Work Plan Operational Flow
+
+1. **Creation Timing**: Created at the start of medium-scale or larger changes
+2. **Updates**: Update progress at each phase completion (checkboxes)
+3. **Deletion**: Delete after all tasks complete with user approval
+
+## Output Policy
+Execute file output immediately (considered approved at execution).
+
+## Important Task Design Principles
+
+1. **Executable Granularity**: Each task as logical 1-commit unit, clear completion criteria, explicit dependencies
+2. **Built-in Quality**: Simultaneous test implementation, quality checks in each phase
+3. **Risk Management**: List risks and countermeasures in advance, define detection methods
+4. **Ensure Flexibility**: Prioritize essential purpose, avoid excessive detail
+5. **Design Doc Compliance**: All task completion criteria derived from Design Doc specifications
+6. **Implementation Pattern Consistency**: When including implementation samples, MUST ensure strict compliance with Design Doc implementation approach
+
+### Task Completion Definition: 3 Elements
+1. **Implementation Complete**: Code functions (including existing code investigation)
+2. **Quality Complete**: Tests, type checking, linting pass
+3. **Integration Complete**: Coordination with other components verified
+
+Include completion conditions in task names (e.g., "Service implementation and unit test creation")
+
+## Implementation Strategy Selection
+
+### Strategy A: Test-Driven Development (when test design information provided)
+
+#### Phase 0: Test Preparation (Unit Tests Only)
+Create Red state tests based on unit test definitions provided from previous process.
+
+**Test Implementation Timing**:
+- Unit tests: Phase 0 Red → Green during implementation
+- Integration tests: Create and execute at completion of implementation (Red-Green-Refactor not applied)
+- E2E tests: Execute only in final phase (Red-Green-Refactor not applied)
+
+#### Meta Information Utilization
+Analyze meta information (@category, @dependency, @complexity, etc.) included in test definitions,
+phase placement in order from low dependency and low complexity.
+
+### Strategy B: Implementation-First Development (when no test design information)
+
+#### Start from Phase 1
+Prioritize implementation, add tests as needed in each phase.
+Gradually ensure quality based on Design Doc acceptance criteria.
+
+### Test Design Information Processing (when provided)
+
+**Mandatory processing when test skeleton file paths are provided from previous process**:
+
+#### Step 1: Read Test Skeleton Files (Mandatory)
+
+Read test skeleton files (integration tests, E2E tests) with the Read tool and extract meta information from comments.
+
+**Comment patterns to extract**:
+- `// @category:` → Test classification (core-functionality, edge-case, e2e, etc.)
+- `// @dependency:` → Dependent components (material for phase placement decisions)
+- `// @complexity:` → Complexity (high/medium/low, material for effort estimation)
+- `// fast-check:` → Property-Based Test implementation pattern (**Important**: Tests with this comment should clearly state "use fast-check library" in work plan)
+- `// ROI:` → Priority determination
+
+#### Step 2: Reflect Meta Information in Work Plan
+
+1. **Explicit Documentation of Property-Based Tests (fast-check)**
+   - Tests with `// fast-check:` comments → Add the following to the task's implementation steps:
+     - "Implement property-based test using fast-check library"
+     - Include the pattern in the comment (`fc.property(...)`) as sample code
+
+2. **Phase Placement Based on Dependencies**
+   - `// @dependency: none` → Place in early phases
+   - `// @dependency: [component name]` → Place in phase after dependent component implementation
+   - `// @dependency: full-system` → Place in final phase
+
+3. **Effort Estimation Based on Complexity**
+   - `// @complexity: high` → Split task into subtasks, or estimate higher effort
+   - `// @complexity: low` → Consider combining multiple tests into one task
+
+#### Step 3: Structure Analysis and Classification of it.todo
+
+1. **it.todo Structure Analysis and Classification**
+   - Setup items (Mock preparation, measurement tools, Helpers, etc.) → Prioritize in Phase 1
+   - Unit tests (individual functions) → Start from Phase 0 with Red-Green-Refactor
+   - Integration tests → Place as create/execute tasks when relevant feature implementation is complete
+   - E2E tests → Place as execute-only tasks in final phase
+   - Non-functional requirement tests (performance, UX, etc.) → Place in quality assurance phase
+   - Risk levels ("high risk", "required", etc.) → Move to earlier phases
+
+2. **Task Generation Principles**
+   - Always decompose 5+ test cases into subtasks (setup/high risk/normal/low risk)
+   - Specify "X test implementations" in each task (quantify progress)
+   - Specify traceability: Show correspondence with acceptance criteria in "AC1 support (3 items)" format
+
+3. **Measurement Tool Implementation Concretization**
+   - Measurement tests like "Grade 8 measurement", "technical term rate calculation" → Create dedicated implementation tasks
+   - Auto-add "simple algorithm implementation" task when external libraries not used
+
+4. **Completion Condition Quantification**
+   - Add progress indicator "Test case resolution: X/Y items" to each phase
+   - Final phase required condition: Specific numbers like "Unresolved tests: 0 achieved (all resolved)"
+
+## Task Decomposition Principles
+
+### Test Placement Principles
+**Phase Placement Rules**:
+- Integration tests: Include in relevant phase tasks like "[Feature name] implementation with integration test creation"
+- E2E tests: Place "E2E test execution" in final phase (implementation not needed, execution only)
+
+### Implementation Approach Application
+Decompose tasks based on implementation approach and technical dependencies decided in Design Doc, following verification levels (L1/L2/L3) from implementation-approach skill.
+
+### Task Dependency Minimization Rules
+- Dependencies up to 2 levels maximum (A→B→C acceptable, A→B→C→D requires redesign)
+- Reconsider division for 3+ chain dependencies
+- Each task provides value independently as much as possible
+
+### Phase Composition
+Compose phases based on technical dependencies and implementation approach from Design Doc.
+Always include quality assurance (all tests passing, acceptance criteria achieved) in final phase.
+
+### Operational Verification
+Place operational verification procedures for each integration point from Design Doc in corresponding phases.
+
+### Task Dependencies
+- Clearly define dependencies
+- Explicitly identify tasks that can run in parallel
+- Include integration points in task names
+
+## Diagram Creation (using mermaid notation)
+
+When creating work plans, **Phase Structure Diagrams** and **Task Dependency Diagrams** are mandatory. Add Gantt charts when time constraints exist.
+
+## Quality Checklist
+
+- [ ] Design Doc consistency verification
+- [ ] Phase composition based on technical dependencies
+- [ ] All requirements converted to tasks
+- [ ] Quality assurance exists in final phase
+- [ ] E2E verification procedures placed at integration points
+- [ ] Test design information reflected (only when provided)
+  - [ ] Setup tasks placed in first phase
+  - [ ] Risk level-based prioritization applied
+  - [ ] Measurement tool implementation planned as concrete tasks
+  - [ ] AC and test case traceability specified
+  - [ ] Quantitative test resolution progress indicators set for each phase
+
+## Update Mode Operation
+- **Constraint**: Only pre-execution plans can be updated. Plans in progress require new creation
+- **Processing**: Record change history

package/.claude/commands/add-integration-tests.md

@@ -0,0 +1,116 @@
+---
+name: add-integration-tests
+description: Add integration/E2E tests to existing backend codebase using Design Doc
+---
+
+**Command Context**: Test addition workflow for existing backend implementations
+
+**Scope**: Backend only (acceptance-test-generator supports backend only)
+
+**Role**: Orchestrator
+
+**Execution Method**:
+- Skeleton generation -> delegate to acceptance-test-generator
+- Task file creation -> orchestrator creates directly
+- Test implementation -> delegate to task-executor
+- Test review -> delegate to integration-test-reviewer
+- Quality checks -> delegate to quality-fixer
+
+Design Doc path: $ARGUMENTS
+
+**TodoWrite**: Register steps and update as each completes.
+
+## Prerequisites
+- Design Doc must exist (created manually or via reverse-engineer)
+- Existing implementation to test
+
+## Execution Flow
+
+### 1. Validate Design Doc (Orchestrator)
+```bash
+# Verify Design Doc exists
+ls $ARGUMENTS || ls docs/design/*.md | grep -v template | tail -1
+```
+
+### 2. Skeleton Generation
+
+**Task tool invocation**:
+```
+subagent_type: acceptance-test-generator
+prompt: |
+  Generate test skeletons from Design Doc.
+
+  Design Doc: [path from Step 1]
+
+  Output:
+  - Integration test skeletons (*.int.test.ts)
+  - E2E test skeletons if applicable (*.e2e.test.ts)
+```
+
+**Expected output**: `generatedFiles` containing integration and e2e paths
+
+### 3. Create Task File (Orchestrator)
+
+Create task file following task template (see documentation-criteria skill):
+- Path: `docs/plans/tasks/integration-tests-YYYYMMDD.md`
+- Content: Test implementation tasks based on generated skeletons
+- Include skeleton file paths from Step 2 output in Target Files section
+
+### 4. Test Implementation
+
+**Task tool invocation**:
+```
+subagent_type: task-executor
+prompt: |
+  Implement tests following the task file.
+
+  Task file: docs/plans/tasks/integration-tests-YYYYMMDD.md
+
+  Requirements:
+  - Follow TDD principles (Red-Green-Refactor)
+  - Implement each skeleton test case
+  - Run tests and verify they pass
+```
+
+**Expected output**: `status`, `testsAdded`
+
+### 5. Test Review
+
+**Task tool invocation**:
+```
+subagent_type: integration-test-reviewer
+prompt: |
+  Review test quality.
+
+  Test files: [paths from Step 2 generatedFiles]
+  Skeleton files: [original skeleton paths]
+```
+
+**Expected output**: `status` (approved/needs_revision), `requiredFixes`
+
+**Flow control**:
+- `status: needs_revision` -> Return to Step 4 with `requiredFixes`
+- `status: approved` -> Proceed to Step 6
+
+### 6. Quality Check
+
+**Task tool invocation**:
+```
+subagent_type: quality-fixer
+prompt: |
+  Final quality assurance for test files.
+
+  Scope: Test files added in this workflow
+
+  Requirements:
+  - Run all tests
+  - Verify coverage meets requirements
+  - Fix any quality issues
+```
+
+**Expected output**: `approved` (true/false)
+
+### 7. Commit (Orchestrator)
+
+On `approved: true` from quality-fixer:
+- Commit test files with appropriate message using Bash

package/.claude/commands/build.md

@@ -0,0 +1,77 @@
+---
+description: Execute decomposed tasks in autonomous execution mode
+---
+
+Follow subagents-orchestration-guide skill strictly and act as the **orchestrator**.
+
+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
+```
+
+✅ **Recommended**: After task generation, automatically proceed to autonomous execution
+❌ **Avoid**: Starting implementation without task generation
+
+## 🧠 Task Execution Flow
+Following "Autonomous Execution Task Management" in subagents-orchestration-guide skill, manage 4 steps with TodoWrite. Always include: first "Confirm skill constraints", final "Verify skill fidelity":
+1. task-executor execution
+2. Escalation judgment and follow-up
+3. quality-fixer execution
+4. git commit
+
+After approval confirmation, start autonomous execution mode. Stop immediately when requirement changes detected.
+
+## Output Example
+Implementation phase completed.
+- Task decomposition: Generated under docs/plans/tasks/ (if executed)
+- Implemented tasks: [number] tasks
+- Quality checks: All passed
+- Commits: [number] commits created
+
+**Responsibility Boundary**:
+- IN SCOPE: Task decomposition to implementation completion
+- OUT OF SCOPE: Design phase, planning phase

package/.claude/commands/db-migrate.md

@@ -0,0 +1,96 @@
+---
+description: Create/run database migrations
+---
+
+Manage database migrations following supabase and supabase-local skills.
+
+Arguments: $ARGUMENTS (migration name or action)
+
+## Migration Workflow
+
+### Creating New Migration
+
+If argument is a migration name:
+```bash
+supabase migration new $ARGUMENTS
+```
+
+Then provide migration template with:
+- Proper table structure (UUID, timestamps)
+- RLS enabled
+- Appropriate policies
+- Indexes for foreign keys
+
+### Migration Template
+```sql
+-- supabase/migrations/TIMESTAMP_$ARGUMENTS.sql
+
+-- Create table
+CREATE TABLE public.table_name (
+  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+  -- Add columns here
+  created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
+  updated_at TIMESTAMPTZ NOT NULL DEFAULT now()
+);
+
+-- Enable RLS
+ALTER TABLE public.table_name ENABLE ROW LEVEL SECURITY;
+
+-- Create policies
+CREATE POLICY "policy_name"
+  ON public.table_name FOR SELECT
+  TO authenticated
+  USING (/* condition */);
+
+-- Create indexes
+CREATE INDEX idx_table_name_column ON public.table_name(column_name);
+
+-- Create updated_at trigger
+CREATE TRIGGER update_table_name_updated_at
+  BEFORE UPDATE ON public.table_name
+  FOR EACH ROW
+  EXECUTE FUNCTION update_updated_at();
+```
+
+## Migration Actions
+
+### Check Status
+```bash
+supabase migration list
+```
+
+### Apply to Local
+```bash
+supabase db reset
+```
+
+### Generate from Changes
+```bash
+supabase db diff -f migration_name
+```
+
+### Push to Remote
+```bash
+supabase db push
+```
+
+### Pull from Remote
+```bash
+supabase db pull
+```
+
+## Post-migration
+
+### Regenerate Types
+```bash
+supabase gen types typescript --local > src/types/database.types.ts
+```
+
+### Verify
+- [ ] Migration applied successfully
+- [ ] Types updated
+- [ ] RLS policies working
+- [ ] No type errors in code
+
+## Output
+Report migration status and any required code updates.

package/.claude/commands/deploy.md

@@ -0,0 +1,95 @@
+---
+description: Orchestrate full deployment
+---
+
+Orchestrate deployment to production following fullstack-integration, vercel-deployment, and supabase skills.
+
+## Pre-deployment Checklist
+
+### 1. Code Quality
+```bash
+# Run type check
+npm run typecheck
+
+# Run tests
+npm test
+
+# Run linter
+npm run lint
+```
+
+### 2. Environment Verification
+Verify all required environment variables are set in Vercel:
+- `NEXT_PUBLIC_SUPABASE_URL`
+- `NEXT_PUBLIC_SUPABASE_ANON_KEY`
+- `SUPABASE_SERVICE_ROLE_KEY`
+- `NEXT_PUBLIC_STACK_PROJECT_ID`
+- `NEXT_PUBLIC_STACK_PUBLISHABLE_CLIENT_KEY`
+- `STACK_SECRET_SERVER_KEY`
+
+### 3. Database Migrations
+```bash
+# Check pending migrations
+supabase db diff
+
+# Push migrations to production
+supabase db push --linked
+```
+
+### 4. Type Synchronization
+```bash
+# Regenerate types from production schema
+supabase gen types typescript --linked > src/types/database.types.ts
+```
+
+## Deployment Steps
+
+### 1. Build Verification
+```bash
+# Local build test
+npm run build
+```
+
+### 2. Deploy to Preview
+```bash
+vercel
+```
+
+Verify preview deployment:
+- [ ] Application loads
+- [ ] Authentication works
+- [ ] Database connections work
+- [ ] No console errors
+
+### 3. Deploy to Production
+```bash
+vercel --prod
+```
+
+## Post-deployment Verification
+
+### 1. Smoke Tests
+- [ ] Homepage loads
+- [ ] Sign-in works
+- [ ] Protected routes work
+- [ ] Database queries work
+
+### 2. Monitor
+```bash
+# View logs
+vercel logs [deployment-url]
+```
+
+## Rollback Plan
+If issues detected:
+```bash
+# Rollback to previous deployment
+vercel rollback
+```
+
+## Output
+Report deployment status:
+- Deployment URL
+- Build time
+- Any warnings or errors
+- Verification results

package/.claude/commands/design.md

@@ -0,0 +1,75 @@
+---
+description: Execute from requirement analysis to design document creation
+---
+
+**Command Context**: This command is dedicated to the design phase.
+
+## Orchestrator Definition
+
+**Core Identity**: "I am not a worker. I am an orchestrator." (see subagents-orchestration-guide skill)
+
+**Execution Protocol**:
+1. **Delegate all work** to sub-agents (NEVER investigate/analyze yourself)
+2. **Follow subagents-orchestration-guide skill design flow exactly**:
+   - Execute: requirement-analyzer → technical-designer → document-reviewer → design-sync
+   - **Stop at every `[Stop: ...]` marker** → Wait for user approval before proceeding
+3. **Scope**: Complete when design documents receive approval
+
+**CRITICAL**: NEVER skip document-reviewer, design-sync, or stopping points defined in subagents-orchestration-guide skill flows.
+
+## Workflow Overview
+
+```
+Requirements → requirement-analyzer → [Stop: Scale determination]
+                                           ↓
+                                   technical-designer → document-reviewer
+                                           ↓
+                                      design-sync → [Stop: Design approval]
+```
+
+Requirements: $ARGUMENTS
+
+**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, analyze with requirement-analyzer and create appropriate design documents according to scale.
+
+Clearly present design alternatives and trade-offs.
+
+## 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
+- Document review with document-reviewer
+- Design Doc consistency verification with design-sync
+
+**Responsibility Boundary**: This command completes with design document approval.
+
+## Execution Flow
+
+1. requirement-analyzer → Requirement analysis
+2. technical-designer → Design Doc creation
+3. document-reviewer → Single document quality check
+4. User approval (WAIT for approval)
+5. design-sync → Design Doc consistency verification
+   - IF conflicts found → Report to user → Wait for fix instructions → Fix with technical-designer(update)
+   - IF no conflicts → End
+
+## Completion Criteria
+
+- [ ] Executed requirement-analyzer and determined scale
+- [ ] Created appropriate design document (ADR or Design Doc) with technical-designer
+- [ ] Executed document-reviewer and addressed feedback
+- [ ] Executed design-sync for consistency verification
+- [ ] Obtained user approval for design document
+
+## Output Example
+Design phase completed.
+- Design document: docs/design/[document-name].md
+- Consistency: No conflicts with other Design Docs (or fixes completed)
+
+**Important**: This command ends with design approval + consistency verification. Does not propose transition to next phase.