create-claude-webapp 1.0.0 → 1.0.1

package/.claude/skills/documentation-criteria/references/design-template.md

@@ -0,0 +1,263 @@
+# [Feature Name] Design Document
+
+## Overview
+
+[Explain the purpose and overview of this feature in 2-3 sentences]
+
+## Design Summary (Meta)
+
+```yaml
+design_type: "new_feature|extension|refactoring"
+risk_level: "low|medium|high"
+complexity_level: "low|medium|high"
+complexity_rationale: "[Required if medium/high: (1) which requirements/ACs necessitate this complexity, (2) which constraints/risks it addresses]"
+main_constraints:
+  - "[constraint 1]"
+  - "[constraint 2]"
+biggest_risks:
+  - "[risk 1]"
+  - "[risk 2]"
+unknowns:
+  - "[uncertainty 1]"
+  - "[uncertainty 2]"
+```
+
+## Background and Context
+
+### Prerequisite ADRs
+
+- [ADR File Name]: [Related decision items]
+- Reference common technical ADRs when applicable
+
+### Agreement Checklist
+
+#### Scope
+- [ ] [Features/components to change]
+- [ ] [Features to add]
+
+#### Non-Scope (Explicitly not changing)
+- [ ] [Features/components not to change]
+- [ ] [Existing logic to preserve]
+
+#### Constraints
+- [ ] Parallel operation: [Yes/No]
+- [ ] Backward compatibility: [Required/Not required]
+- [ ] Performance measurement: [Required/Not required]
+
+### Problem to Solve
+
+[Specific problems or challenges this feature aims to address]
+
+### Current Challenges
+
+[Current system issues or limitations]
+
+### Requirements
+
+#### Functional Requirements
+
+- [List mandatory functional requirements]
+
+#### Non-Functional Requirements
+
+- **Performance**: [Response time, throughput requirements]
+- **Scalability**: [Requirements for handling increased load]
+- **Reliability**: [Error rate, availability requirements]
+- **Maintainability**: [Code readability and changeability]
+
+## Acceptance Criteria (AC) - EARS Format
+
+Each AC is written in EARS format. Keywords determine test type.
+
+### [Functional Requirement 1]
+
+- [ ] **When** user clicks login button with valid credentials, the system shall authenticate and redirect to dashboard
+- [ ] **If** credentials are invalid, **then** the system shall display error message "Invalid credentials"
+- [ ] **While** user is logged in, the system shall maintain the session for 60 minutes
+
+### [Functional Requirement 2]
+
+- [ ] The system shall display data list with pagination of 10 items per page
+- [ ] **When** input is entered in search field, the system shall apply real-time filtering
+  - **Property**: `filtered.every(item => item.name.includes(query))`
+
+## Existing Codebase Analysis
+
+### Implementation Path Mapping
+| Type | Path | Description |
+|------|------|-------------|
+| Existing | src/[actual-path] | [Current implementation] |
+| New | src/[planned-path] | [Planned new creation] |
+
+### Integration Points (Include even for new implementations)
+- **Integration Target**: [What to connect with]
+- **Invocation Method**: [How it will be invoked]
+
+## Design
+
+### Change Impact Map
+
+```yaml
+Change Target: [Component/feature to change]
+Direct Impact:
+  - [Files/functions requiring direct changes]
+  - [Interface change points]
+Indirect Impact:
+  - [Data format changes]
+  - [Processing time changes]
+No Ripple Effect:
+  - [Explicitly specify unaffected features]
+```
+
+### Architecture Overview
+
+[How this feature is positioned within the overall system]
+
+### Data Flow
+
+```
+[Express data flow using diagrams or pseudo-code]
+```
+
+### Integration Points List
+
+| Integration Point | Location | Old Implementation | New Implementation | Switching Method |
+|-------------------|----------|-------------------|-------------------|------------------|
+| Integration Point 1 | [Class/Function] | [Existing Process] | [New Process] | [DI/Factory etc.] |
+| Integration Point 2 | [Another Location] | [Existing] | [New] | [Method] |
+
+### Main Components
+
+#### Component 1
+
+- **Responsibility**: [Scope of responsibility for this component]
+- **Interface**: [APIs and type definitions provided]
+- **Dependencies**: [Relationships with other components]
+
+#### Component 2
+
+- **Responsibility**: [Scope of responsibility for this component]
+- **Interface**: [APIs and type definitions provided]
+- **Dependencies**: [Relationships with other components]
+
+### Type Definitions
+
+```typescript
+// Record major type definitions here
+```
+
+### Data Contract
+
+#### Component 1
+
+```yaml
+Input:
+  Type: [TypeScript type definition]
+  Preconditions: [Required items, format constraints]
+  Validation: [Validation method]
+
+Output:
+  Type: [TypeScript type definition]
+  Guarantees: [Conditions that must always be met]
+  On Error: [Exception/null/default value]
+
+Invariants:
+  - [Conditions that remain unchanged before and after processing]
+```
+
+### State Transitions and Invariants
+
+[If the feature involves state management, describe state transitions and invariants here]
+
+```
+[State A] ---(event 1)---> [State B]
+[State B] ---(event 2)---> [State C]
+```
+
+**Invariants**:
+- [Condition that must always hold true]
+- [Constraints on valid state transitions]
+
+### Error Handling
+
+[Types of errors and how to handle them]
+
+### Logging and Monitoring
+
+[What to record in logs and how to monitor]
+
+## Implementation Plan
+
+### Implementation Approach
+
+**Selected Approach**: [Approach name or combination]
+**Selection Reason**: [Reason considering project constraints and technical dependencies]
+
+### Technical Dependencies and Implementation Order
+
+#### Required Implementation Order
+1. **[Component/Feature A]**
+   - Technical Reason: [Why this needs to be implemented first]
+   - Dependent Elements: [Other components that depend on this]
+
+2. **[Component/Feature B]**
+   - Technical Reason: [Technical necessity to implement after A]
+   - Prerequisites: [Required pre-implementations]
+
+### Integration Points
+Each integration point requires E2E verification:
+
+**Integration Point 1: [Name]**
+- Components: [Component A] -> [Component B]
+- Verification: [How to verify integration works]
+
+### Migration Strategy
+
+[Technical migration approach, ensuring backward compatibility]
+
+## Test Strategy
+
+### Unit Tests
+
+[Unit testing policy and coverage goals]
+- Verify individual elements of functional acceptance criteria
+
+### Integration Tests
+
+[Integration testing policy and important test cases]
+- Verify combined operations of functional acceptance criteria
+
+### E2E Tests
+
+[E2E testing policy]
+- Verify entire scenarios of acceptance criteria
+- Confirm functional operation from user perspective
+
+## Security Considerations
+
+[Security concerns and countermeasures]
+
+## Alternative Solutions
+
+### Alternative 1
+
+- **Overview**: [Description of alternative solution]
+- **Advantages**: [Advantages]
+- **Disadvantages**: [Disadvantages]
+- **Reason for Rejection**: [Why it wasn't adopted]
+
+## Risks and Mitigation
+
+| Risk | Impact | Probability | Mitigation |
+|------|--------|-------------|------------|
+| [Risk 1] | High/Medium/Low | High/Medium/Low | [Countermeasure] |
+
+## References
+
+- [Related documentation and links]
+
+## Update History
+
+| Date | Version | Changes | Author |
+|------|---------|---------|--------|
+| YYYY-MM-DD | 1.0 | Initial version | [Name] |

package/.claude/skills/documentation-criteria/references/plan-template.md

@@ -0,0 +1,130 @@
+# Work Plan: [Title]
+
+Created Date: YYYY-MM-DD
+Type: feature|fix|refactor
+Estimated Impact: X files
+Related Issue/PR: #XXX (if any)
+
+## Related Documents
+- Design Doc: [docs/design/XXX.md]
+- ADR: [docs/adr/ADR-XXXX.md] (if any)
+- PRD: [docs/prd/XXX.md] (if any)
+
+## Objective
+[Why this change is necessary, what problem it solves]
+
+## Impact Scope
+### Target Files
+- [ ] src/domain/xxx
+- [ ] src/application/xxx
+- [ ] src/infrastructure/xxx
+- [ ] src/presentation/xxx
+
+### Test Files
+- [ ] __tests__/xxx.test.ts
+- [ ] __tests__/xxx.test.ts
+
+### Documentation
+- [ ] ADR creation needed (for architecture changes)
+- [ ] Design Doc update needed
+- [ ] README update needed
+
+## Implementation Plan
+
+(Note: Phase structure is determined based on Design Doc technical dependencies and implementation approach)
+
+### Phase 1: [Phase Name] (Estimated commits: X)
+**Purpose**: [What this phase aims to achieve]
+
+#### Tasks
+- [ ] Task 1: Specific work content
+- [ ] Task 2: Specific work content
+- [ ] Quality check: Implement staged quality checks (refer to technical-spec skill)
+- [ ] Unit tests: All related tests pass
+
+#### Phase Completion Criteria
+- [ ] [Functional completion criteria]
+- [ ] [Quality completion criteria]
+
+#### Operational Verification Procedures
+1. [Operation verification steps]
+2. [Expected result verification]
+3. [Performance verification (when applicable)]
+
+### Phase 2: [Phase Name] (Estimated commits: X)
+**Purpose**: [What this phase aims to achieve]
+
+#### Tasks
+- [ ] Task 1: Specific work content
+- [ ] Task 2: Specific work content
+- [ ] Quality check: Implement staged quality checks (refer to technical-spec skill)
+- [ ] Integration tests: Verify overall feature functionality
+
+#### Phase Completion Criteria
+- [ ] [Functional completion criteria]
+- [ ] [Quality completion criteria]
+
+#### Operational Verification Procedures
+1. [Operation verification steps]
+2. [Expected result verification]
+3. [Performance verification (when applicable)]
+
+### Phase 3: [Phase Name] (Estimated commits: X)
+**Purpose**: [What this phase aims to achieve]
+
+#### Tasks
+- [ ] Task 1: Specific work content
+- [ ] Task 2: Specific work content
+- [ ] Quality check: Implement staged quality checks (refer to technical-spec skill)
+- [ ] Integration tests: Verify component coordination
+
+#### Phase Completion Criteria
+- [ ] [Functional completion criteria]
+- [ ] [Quality completion criteria]
+
+#### Operational Verification Procedures
+[Copy relevant integration point E2E verification from Design Doc]
+
+### Final Phase: Quality Assurance (Required) (Estimated commits: 1)
+**Purpose**: Overall quality assurance and Design Doc consistency verification
+
+#### Tasks
+- [ ] Verify all Design Doc acceptance criteria achieved
+- [ ] Quality checks (types, lint, format)
+- [ ] Execute all tests
+- [ ] Coverage 70%+
+- [ ] Document updates
+
+#### Operational Verification Procedures
+[Copy E2E verification procedures from Design Doc]
+
+### Quality Assurance
+- [ ] Implement staged quality checks (details: refer to technical-spec skill)
+
+## Risks and Countermeasures
+| Risk | Countermeasure |
+|------|----------------|
+| [Expected risk] | [How to address it] |
+
+## Completion Criteria
+- [ ] All phases completed
+- [ ] Each phase's operational verification procedures executed
+- [ ] Design Doc acceptance criteria satisfied
+- [ ] Staged quality checks completed (zero errors)
+- [ ] All tests pass
+- [ ] Necessary documentation updated
+- [ ] User review approval obtained
+
+## Progress Tracking
+### Phase 1
+- Start: YYYY-MM-DD HH:MM
+- Complete: YYYY-MM-DD HH:MM
+- Notes: [Any special remarks]
+
+### Phase 2
+- Start: YYYY-MM-DD HH:MM
+- Complete: YYYY-MM-DD HH:MM
+- Notes: [Any special remarks]
+
+## Notes
+[Special notes, reference information, important points, etc.]

package/.claude/skills/documentation-criteria/references/prd-template.md

@@ -0,0 +1,109 @@
+# PRD: [Feature Name]
+
+## Overview
+
+### One-line Summary
+[Describe this feature in one line]
+
+### Background
+[Why is this feature needed? What problem does it solve?]
+
+## User Stories
+
+### Primary Users
+[Define the main target users]
+
+### User Stories
+```
+As a [user type]
+I want to [goal/desire]
+So that [expected value/benefit]
+```
+
+### Use Cases
+1. [Specific usage scenario 1]
+2. [Specific usage scenario 2]
+3. [Specific usage scenario 3]
+
+## Functional Requirements
+
+### Must Have (MVP)
+- [ ] Requirement 1: [Detailed description]
+  - AC: [Acceptance criteria - Given/When/Then format or measurable standard]
+- [ ] Requirement 2: [Detailed description]
+  - AC: [Acceptance criteria]
+- [ ] Requirement 3: [Detailed description]
+  - AC: [Acceptance criteria]
+
+### Nice to Have
+- [ ] Requirement 1: [Detailed description]
+- [ ] Requirement 2: [Detailed description]
+
+### Out of Scope
+- Item 1: [Description and reason]
+- Item 2: [Description and reason]
+
+## Non-Functional Requirements
+
+### Performance
+- Response Time: [Target value]
+- Throughput: [Target value]
+- Concurrency: [Target value]
+
+### Reliability
+- Availability: [Target value]
+- Error Rate: [Target value]
+
+### Security
+- [Security requirements details]
+
+### Scalability
+- [Considerations for future scaling]
+
+## Success Criteria
+
+### Quantitative Metrics
+1. [Measurable success metric 1]
+2. [Measurable success metric 2]
+3. [Measurable success metric 3]
+
+### Qualitative Metrics
+1. [User experience metric 1]
+2. [User experience metric 2]
+
+## Technical Considerations
+
+### Dependencies
+- [Dependencies on existing systems]
+- [Dependencies on external services]
+
+### Constraints
+- [Technical constraints]
+- [Resource constraints]
+
+### Assumptions
+- [Prerequisite requiring validation 1]
+- [Prerequisite requiring validation 2]
+
+### Risks and Mitigation
+| Risk | Impact | Probability | Mitigation |
+|------|--------|-------------|------------|
+| [Risk 1] | High/Medium/Low | High/Medium/Low | [Countermeasure] |
+| [Risk 2] | High/Medium/Low | High/Medium/Low | [Countermeasure] |
+
+## Undetermined Items
+
+- [ ] [Question 1]: [Description of options or impacts]
+- [ ] [Question 2]: [Description of options or impacts]
+
+*Discuss with user until this section is empty, then delete after confirmation*
+
+## Appendix
+
+### References
+- [Related document 1]
+- [Related document 2]
+
+### Glossary
+- **Term 1**: [Definition]
+- **Term 2**: [Definition]

package/.claude/skills/documentation-criteria/references/task-template.md

@@ -0,0 +1,38 @@
+# Task: [Task Name]
+
+Metadata:
+- Dependencies: task-01 -> Deliverable: docs/plans/analysis/research-results.md
+- Provides: docs/plans/analysis/api-spec.md (for research/design tasks)
+- Size: Small (1-2 files)
+
+## Implementation Content
+[What this task will achieve]
+*Reference dependency deliverables if applicable
+
+## Target Files
+- [ ] [Implementation file path]
+- [ ] [Test file path]
+
+## Implementation Steps (TDD: Red-Green-Refactor)
+### 1. Red Phase
+- [ ] Review dependency deliverables (if any)
+- [ ] Verify/create contract definitions
+- [ ] Write failing tests
+- [ ] Run tests and confirm failure
+
+### 2. Green Phase
+- [ ] Add minimal implementation to pass tests
+- [ ] Run only added tests and confirm they pass
+
+### 3. Refactor Phase
+- [ ] Improve code (maintain passing tests)
+- [ ] Confirm added tests still pass
+
+## Completion Criteria
+- [ ] All added tests pass
+- [ ] Operation verified (select L1/L2/L3, per implementation-approach skill)
+- [ ] Deliverables created (for research/design tasks)
+
+## Notes
+- Impact scope: [Areas where changes may propagate]
+- Constraints: [Areas not to be modified]

package/.claude/skills/frontend/technical-spec/SKILL.md

@@ -0,0 +1,147 @@
+---
+name: frontend/technical-spec
+description: Defines frontend environment variables, component design, and data flow patterns. Use when configuring React environment.
+---
+
+# Technical Design Rules (Frontend)
+
+## Basic Technology Stack Policy
+TypeScript-based React application implementation. Architecture patterns should be selected according to project requirements and scale.
+
+## Environment Variable Management and Security
+
+### Environment Variable Management
+- **Use build tool's environment variable system**: `process.env` does not work in browser environments
+- Centrally manage environment variables through configuration layer
+- Implement proper type safety with TypeScript
+- Properly implement default value settings and mandatory checks
+
+```typescript
+// Build tool environment variables (public values only)
+const config = {
+  apiUrl: import.meta.env.API_URL || 'http://localhost:3000',
+  appName: import.meta.env.APP_NAME || 'My App'
+}
+
+// Does not work in frontend
+const apiUrl = process.env.API_URL
+```
+
+### Security (Client-side Constraints)
+- **CRITICAL**: All frontend code is public and visible in browser
+- **Never store secrets client-side**: No API keys, tokens, or secrets in environment variables
+- Do not include `.env` files in Git (same as backend)
+- Prohibit logging of sensitive information (passwords, tokens, personal data)
+- Do not include sensitive information in error messages
+
+**Correct Approach for Secrets**:
+```typescript
+// Security risk: API key exposed in browser
+const apiKey = import.meta.env.API_KEY
+const response = await fetch(`https://api.example.com/data?key=${apiKey}`)
+
+// Correct: Backend manages secrets, frontend accesses via proxy
+const response = await fetch('/api/data') // Backend handles API key authentication
+```
+
+## Architecture Design
+
+### Frontend Architecture Patterns
+
+**React Component Architecture**:
+- **Function Components**: Mandatory, class components deprecated
+- **Custom Hooks**: For logic reuse and dependency injection
+- **Component Hierarchy**: Atoms -> Molecules -> Organisms -> Templates -> Pages
+- **Props-driven**: Components receive all necessary data via props
+- **Co-location**: Place tests, styles, and related files alongside components
+
+**State Management Patterns**:
+- **Local State**: `useState` for component-specific state
+- **Context API**: For sharing state across component tree (theme, auth, etc.)
+- **Custom Hooks**: Encapsulate state logic and side effects
+- **Server State**: React Query or SWR for API data caching
+
+## Unified Data Flow Principles
+
+### Client-side Data Flow
+Maintain consistent data flow throughout the React application:
+
+- **Single Source of Truth**: Each piece of state has one authoritative source
+  - UI state: Component state or Context
+  - Server data: API responses cached in React Query/SWR
+  - Form data: Controlled components with React Hook Form
+
+- **Unidirectional Flow**: Data flows top-down via props
+  ```
+  API Response -> State -> Props -> Render -> UI
+  User Input -> Event Handler -> State Update -> Re-render
+  ```
+
+- **Immutable Updates**: Use immutable patterns for state updates
+  ```typescript
+  // Immutable state update
+  setUsers(prev => [...prev, newUser])
+
+  // Mutable state update (avoid)
+  users.push(newUser)
+  setUsers(users)
+  ```
+
+### Type Safety in Data Flow
+- **Frontend -> Backend**: Props/State (Type Guaranteed) -> API Request (Serialization)
+- **Backend -> Frontend**: API Response (`unknown`) -> Type Guard -> State (Type Guaranteed)
+
+```typescript
+// Type-safe data flow
+async function fetchUser(id: string): Promise<User> {
+  const response = await fetch(`/api/users/${id}`)
+  const data: unknown = await response.json()
+
+  if (!isUser(data)) {
+    throw new Error('Invalid user data')
+  }
+
+  return data // Type guaranteed as User
+}
+```
+
+## Build and Testing
+Use the appropriate run command based on the `packageManager` field in package.json.
+
+### Build Commands
+- `dev` - Development server
+- `build` - Production build
+- `preview` - Preview production build
+- `type-check` - Type check (no emit)
+
+### Testing Commands
+- `test` - Run tests
+- `test:coverage` - Run tests with coverage
+- `test:coverage:fresh` - Run tests with coverage (fresh cache)
+- `test:safe` - Safe test execution (with auto cleanup)
+- `cleanup:processes` - Cleanup Vitest processes
+
+### Quality Check Requirements
+Quality checks are mandatory upon implementation completion:
+
+**Phase 1-3: Basic Checks**
+- `check` - Biome (lint + format)
+- `build` - TypeScript build
+
+**Phase 4-5: Tests and Final Confirmation**
+- `test` - Test execution
+- `test:coverage:fresh` - Coverage measurement
+- `check:all` - Overall integrated check
+
+### Coverage Requirements
+- **Mandatory**: Unit test coverage must be 60% or higher
+- **Component-specific targets**:
+  - Atoms: 70% or higher
+  - Molecules: 65% or higher
+  - Organisms: 60% or higher
+  - Custom Hooks: 65% or higher
+  - Utils: 70% or higher
+
+### Non-functional Requirements
+- **Browser Compatibility**: Chrome/Firefox/Safari/Edge (latest 2 versions)
+- **Rendering Time**: Within 5 seconds for major pages