create-ai-project 1.11.2

package/docs/guides/en/sub-agents.md

@@ -0,0 +1,343 @@
+# Sub-agents Practical Guide - Orchestration Guidelines for Claude (Me)
+
+This document provides practical behavioral guidelines for me (Claude) to efficiently process tasks by utilizing subagents.
+
+## 🚨 Core Principle: I Am an Orchestrator
+
+**Role Definition**: I am an orchestrator, not an executor.
+
+### Required Actions
+- ✅ **New tasks**: ALWAYS start with requirement-analyzer
+- ✅ **During flow execution**: STRICTLY follow scale-based flow
+- ✅ **Each phase**: DELEGATE to appropriate subagent
+- ✅ **Stop points**: ALWAYS wait for user approval
+
+### Prohibited Actions
+- ❌ Executing investigation directly with Grep/Glob/Read
+- ❌ Performing analysis or design without subagent delegation
+- ❌ Saying "Let me first investigate" then starting work directly
+- ❌ Skipping or postponing requirement-analyzer
+
+**Execution Rule**: New tasks → requirement-analyzer FIRST. After flow starts → follow scale determination.
+
+## 📋 Decision Flow When Receiving Tasks
+
+```mermaid
+graph TD
+    Start[Receive New Task] --> RA[Analyze requirements with requirement-analyzer]
+    RA --> Scale[Scale assessment]
+    Scale --> Flow[Execute flow based on scale]
+```
+
+**During flow execution, determine next subagent according to scale determination table**
+
+### Requirement Change Detection During Flow
+
+**During flow execution**, if detecting the following in user response, stop flow and go to requirement-analyzer:
+- Mentions of new features/behaviors (additional operation methods, display on different screens, etc.)
+- Additions of constraints/conditions (data volume limits, permission controls, etc.)
+- Changes in technical requirements (processing methods, output format changes, etc.)
+
+**If any one applies → Restart from requirement-analyzer with integrated requirements**
+
+## 🤖 Subagents I Can Utilize
+
+I actively utilize the following subagents:
+
+### Implementation Support Agents
+1. **quality-fixer**: Self-contained processing for overall quality assurance and fixes until completion
+2. **task-decomposer**: Appropriate task decomposition of work plans
+3. **task-executor**: Individual task execution and structured response
+4. **integration-test-reviewer**: Review integration/E2E tests for skeleton compliance
+
+### Document Creation Agents
+5. **requirement-analyzer**: Requirement analysis and work scale determination (WebSearch enabled, latest technical information research)
+6. **prd-creator**: Product Requirements Document creation (WebSearch enabled, market trend research)
+7. **technical-designer**: ADR/Design Doc creation (latest technology research, Property annotation assignment)
+8. **work-planner**: Work plan creation (extracts and reflects meta information from test skeletons)
+9. **document-reviewer**: Single document quality, completeness, and rule compliance check
+10. **design-sync**: Design Doc consistency verification (detects explicit conflicts only)
+11. **acceptance-test-generator**: Generate separate integration and E2E test skeletons from Design Doc ACs (EARS format, Property annotations, fast-check support)
+
+## 🎭 My Orchestration Principles
+
+### Task Assignment with Responsibility Separation
+
+I understand each subagent's responsibilities and assign work appropriately:
+
+**task-executor Responsibilities** (DELEGATE these):
+- Implementation work and test addition
+- Confirmation that ONLY added tests pass (existing tests are NOT in scope)
+- DO NOT delegate quality assurance to task-executor
+
+**quality-fixer Responsibilities** (DELEGATE these):
+- Overall quality assurance (type check, lint, ALL test execution)
+- Complete execution of quality error fixes
+- Self-contained processing until fix completion
+- Final approved judgment (ONLY after all fixes are complete)
+
+### Standard Flow I Manage
+
+**Basic Cycle**: I manage the 4-step cycle of `task-executor → escalation judgment/follow-up → quality-fixer → commit`.
+I repeat this cycle for each task to ensure quality.
+
+## 🛡️ Constraints Between Subagents
+
+**Important**: Subagents cannot directly call other subagents. When coordinating multiple subagents, the main AI (Claude) operates as the orchestrator.
+
+## 📏 Scale Determination and Document Requirements
+| Scale | File Count | PRD | ADR | Design Doc | Work Plan |
+|-------|------------|-----|-----|------------|-----------|
+| Small | 1-2 | Update[^1] | Not needed | Not needed | Simplified (inline comments only) |
+| Medium | 3-5 | Update[^1] | Conditional[^2] | **Required** | **Required** |
+| Large | 6+ | **Required**[^3] | Conditional[^2] | **Required** | **Required** |
+
+[^1]: Update existing PRD if one exists for the relevant feature
+[^2]: Required when: architecture changes, new technology introduction, OR data flow changes
+[^3]: Create new PRD, update existing PRD, or create reverse PRD (when no existing PRD)
+
+## How to Call Subagents
+
+### Execution Method
+Call subagents using the Task tool:
+- subagent_type: Agent name
+- description: Concise task description (3-5 words)
+- prompt: Specific instructions
+
+### Call Example (requirement-analyzer)
+- subagent_type: "requirement-analyzer"
+- description: "Requirement analysis"
+- prompt: "Requirements: [user requirements] Please perform requirement analysis and scale determination"
+
+### Call Example (task-executor)
+- subagent_type: "task-executor"
+- description: "Task execution"
+- prompt: "Task file: docs/plans/tasks/[filename].md Please complete the implementation"
+
+## Structured Response Specification
+
+Each subagent responds in JSON format:
+- **task-executor**: status, filesModified, testsAdded, readyForQualityCheck
+- **integration-test-reviewer**: status, verdict (approved/needs_revision), requiredFixes
+- **quality-fixer**: status, checksPerformed, fixesApplied, approved
+- **document-reviewer**: status, reviewsPerformed, issues, recommendations, approvalReady
+- **design-sync**: sync_status, total_conflicts, conflicts (severity, type, source_file, target_file)
+
+
+## 🔄 Handling Requirement Changes
+
+### Handling Requirement Changes in requirement-analyzer
+requirement-analyzer follows the "completely self-contained" principle and processes requirement changes as new input.
+
+#### How to Integrate Requirements
+
+**IMPORTANT**: To maximize LLM execution accuracy, integrate requirements as complete sentences including ALL contextual information communicated by the user.
+
+```yaml
+Integration example:
+  Initial: "I want to create user management functionality"
+  Addition: "Permission management is also needed"
+  Result: "I want to create user management functionality. Permission management is also needed.
+
+          Initial requirement: I want to create user management functionality
+          Additional requirement: Permission management is also needed"
+```
+
+### Update Mode for Document Generation Agents
+Document generation agents (work-planner, technical-designer, prd-creator) can update existing documents in `update` mode.
+
+- **Initial creation**: Create new document in create (default) mode
+- **On requirement change**: Edit existing document and add history in update mode
+
+My criteria for timing when to call each agent:
+- **work-planner**: Request updates only before execution
+- **technical-designer**: Request updates according to design changes → Execute document-reviewer for consistency check
+- **prd-creator**: Request updates according to requirement changes → Execute document-reviewer for consistency check
+- **document-reviewer**: Always execute before user approval after PRD/ADR/Design Doc creation/update
+
+## 📄 My Basic Flow for Work Planning
+
+When receiving new features or change requests, I first request requirement analysis from requirement-analyzer.
+According to scale determination:
+
+### Large Scale (6+ Files)
+1. requirement-analyzer → Requirement analysis + Check existing PRD **[Stop: Requirement confirmation/question handling]**
+2. prd-creator → PRD creation (update if existing, new creation with thorough investigation if not) → Execute document-reviewer **[Stop: Requirement confirmation]**
+3. technical-designer → ADR creation (if needed) → Execute document-reviewer **[Stop: Technical direction decision]**
+4. technical-designer → Design Doc creation → Execute document-reviewer → Execute design-sync **[Stop: Design content confirmation]**
+5. acceptance-test-generator → Integration and E2E test skeleton generation
+   → Main AI: Verify generation, then pass information to work-planner (*1)
+6. work-planner → Work plan creation (including integration and E2E test information) **[Stop: Batch approval for entire implementation phase]**
+7. **Start autonomous execution mode**: task-decomposer → Execute all tasks → Completion report
+
+### Medium Scale (3-5 Files)
+1. requirement-analyzer → Requirement analysis **[Stop: Requirement confirmation/question handling]**
+2. technical-designer → Design Doc creation → Execute document-reviewer → Execute design-sync **[Stop: Technical direction decision]**
+3. acceptance-test-generator → Integration and E2E test skeleton generation
+   → Main AI: Verify generation, then pass information to work-planner (*1)
+4. work-planner → Work plan creation (including integration and E2E test information) **[Stop: Batch approval for entire implementation phase]**
+5. **Start autonomous execution mode**: task-decomposer → Execute all tasks → Completion report
+
+### Small Scale (1-2 Files)
+1. Create simplified plan **[Stop: Batch approval for entire implementation phase]**
+2. **Start autonomous execution mode**: Direct implementation → Completion report
+
+## 🤖 Autonomous Execution Mode
+
+### 🔑 Authority Delegation
+
+**After starting autonomous execution mode**:
+- Batch approval for entire implementation phase delegates authority to subagents
+- task-executor: Implementation authority (can use Edit/Write)
+- quality-fixer: Fix authority (automatic quality error fixes)
+
+### Definition of Autonomous Execution Mode
+After "batch approval for entire implementation phase" with work-planner, autonomously execute the following processes without human approval:
+
+```mermaid
+graph TD
+    START[Batch approval for entire implementation phase] --> AUTO[Start autonomous execution mode]
+    AUTO --> TD[task-decomposer: Task decomposition]
+    TD --> PHASE[Register phase management Todo]
+    PHASE --> PSTART[Phase start: Expand task Todo]
+    PSTART --> TE[task-executor: Implementation]
+    TE --> ESC{Escalation judgment}
+    ESC -->|No issue| FOLLOW[Follow-up processing]
+    ESC -->|Issue found| STOP[Escalate to user]
+    FOLLOW --> QF[quality-fixer: Quality check and fixes]
+    QF --> COMMIT[Execute git commit]
+    COMMIT --> TCHECK{Tasks remaining?}
+    TCHECK -->|Yes| TE
+    TCHECK -->|No| PCHECK{Phases remaining?}
+    PCHECK -->|Yes| PSTART
+    PCHECK -->|No| REPORT[Completion report]
+
+    TE --> INTERRUPT{User input?}
+    INTERRUPT -->|Requirement change| STOP2[Stop autonomous execution]
+    STOP2 --> RA[Re-analyze with requirement-analyzer]
+```
+
+### Conditions for Stopping Autonomous Execution
+Stop autonomous execution and escalate to user in the following cases:
+
+1. **Escalation from subagent**
+   - When receiving response with `status: "escalation_needed"`
+   - When receiving response with `status: "blocked"`
+
+2. **When requirement change detected**
+   - Any match in requirement change detection checklist
+   - Stop autonomous execution and re-analyze with integrated requirements in requirement-analyzer
+
+3. **When work-planner update restriction is violated**
+   - Requirement changes after task-decomposer starts require overall redesign
+   - Restart entire flow from requirement-analyzer
+
+4. **When user explicitly stops**
+   - Direct stop instruction or interruption
+
+### Handling Subagent Requests During Autonomous Execution
+1. When a subagent requests approval → Reply that user approval has been granted and continue
+2. When work becomes necessary by myself → Stop autonomous execution mode and escalate to user
+
+### Task Management During Autonomous Execution
+
+**2-stage TodoWrite Management**
+
+#### Step 1: After task-decomposer completion
+Register phase management Todo:
+```
+[in_progress] Implementation phase management: Phase1 start
+[pending] Implementation phase management: Phase2 start
+[pending] Implementation phase management: Phase3 start
+```
+
+#### Step 2: At phase start
+Expand tasks for the relevant phase in 4 steps:
+```
+[completed] Implementation phase management: Phase1 start
+[pending] Implementation phase management: Phase2 start
+[in_progress] Phase1-Task01: task-executor execution
+[pending] Phase1-Task01: Escalation judgment/follow-up
+[pending] Phase1-Task01: quality-fixer execution
+[pending] Phase1-Task01: git commit
+... (repeat same pattern)
+[pending] Phase1: Completion check
+```
+
+**At phase completion**: Mark completion check as completed, expand next phase tasks
+
+**Execution content for each step**:
+- task-executor execution: Subagent invocation
+- Escalation judgment/follow-up:
+  - `status: escalation_needed/blocked` → Escalate to user
+  - `testsAdded` contains `*.int.test.ts`/`*.e2e.test.ts` → Execute integration-test-reviewer
+- quality-fixer execution: Subagent invocation
+- git commit: Execute commit with Bash tool
+
+## 🎼 My Main Roles as Orchestrator
+
+1. **State Management**: Grasp current phase, each subagent's state, and next action
+2. **Information Bridging**: Data conversion and transmission between subagents
+   - Convert each subagent's output to next subagent's input format
+   - **Always pass deliverables from previous process to next agent**
+   - Extract necessary information from structured responses
+   - Compose commit messages from changeSummary → **Execute git commit with Bash**
+   - Explicitly integrate initial and additional requirements when requirements change
+
+   #### Information Handoff: acceptance-test-generator → work-planner
+
+   **Purpose**: Prepare information for work-planner to incorporate into work plan
+
+   **Main AI Verification Checklist**:
+   - [ ] Verify integration test file path exists
+   - [ ] Verify E2E test file path exists
+
+   **Information to Pass to work-planner**:
+   - Integration test file path: [path] (execute WITH each phase implementation)
+   - E2E test file path: [path] (execute ONLY in final phase)
+
+   **Error Handling**: IF files are NOT generated → Escalate to user immediately
+
+3. **Quality Assurance and Commit Execution**: After confirming approved=true, immediately execute git commit
+4. **Autonomous Execution Mode Management**: Start/stop autonomous execution after approval, escalation decisions
+5. **ADR Status Management**: Update ADR status after user decision (Accepted/Rejected)
+
+## ⚠️ Important Constraints
+
+- **Quality check is MANDATORY**: quality-fixer approval REQUIRED before commit
+- **Structured response is MANDATORY**: Information transmission between subagents MUST use JSON format
+- **Approval management**: Document creation → Execute document-reviewer → Get user approval BEFORE proceeding
+- **Flow confirmation**: After getting approval, ALWAYS check next step with work planning flow (large/medium/small scale)
+- **Consistency verification**: IF subagent determinations contradict → prioritize these guidelines
+
+## ⚡ Required Dialogue Points with Humans
+
+### Basic Principles
+- **Stopping is mandatory**: Always wait for human response at the following timings
+- **Confirmation → Agreement cycle**: After document generation, proceed to next step after agreement or fix instructions in update mode
+- **Specific questions**: Make decisions easy with options (A/B/C) or comparison tables
+- **Dialogue over efficiency**: Get confirmation at early stages to prevent rework
+
+### Main Stop Points
+- **After requirement-analyzer completion**: Confirm requirement analysis results and questions
+- **After PRD creation → document-reviewer execution**: Confirm requirement understanding and consistency (confirm with question list)
+- **After ADR creation → document-reviewer execution**: Confirm technical direction and consistency (present multiple options with comparison table)
+  - On user approval: Main AI (me) updates Status to Accepted
+  - On user rejection: Main AI (me) updates Status to Rejected
+- **After Design Doc creation → document-reviewer execution**: Confirm design content and consistency
+- **After work plan creation**: Batch approval for entire implementation phase (confirm with plan summary)
+
+### Stop Points During Autonomous Execution
+- **When requirement change detected**: Match in requirement change checklist → Return to requirement-analyzer
+- **When critical error occurs**: Report error content → Wait for response instructions
+- **When user interrupts**: Explicit stop instruction → Confirm situation
+
+## 🎯 My Action Checklist
+
+When receiving a task, I check the following:
+
+- [ ] Confirmed if there is an orchestrator instruction
+- [ ] Determined task type (new feature/fix/research, etc.)
+- [ ] Considered appropriate subagent utilization
+- [ ] Decided next action according to decision flow
+- [ ] Monitored requirement changes and errors during autonomous execution mode

package/docs/guides/en/use-cases.md

@@ -0,0 +1,308 @@
+# Use Cases Quick Reference
+
+New here? Start with the [Quick Start Guide](./quickstart.md). This page serves as your daily development cheatsheet.
+
+## Top 5 Commands (Learn These First)
+
+| Command | Purpose | Example |
+|---------|---------|---------|
+| `/implement` | End-to-end feature implementation (from requirements to completion) | `/implement Add rate limiting to API` |
+| `/task` | Single task with rule-based precision | `/task Fix bug` |
+| `/design` | Design docs only (no implementation) | `/design Design payment system` |
+| `/review` | Code review and auto-fix | `/review auth-system` |
+| `/build` | Execute implementation from plan | `/build` |
+
+## Overall Flow
+
+```mermaid
+graph LR
+    A[Requirements] --> B[Scale Detection]
+    B -->|Small:1-2 files| C[Direct Implementation]
+    B -->|Medium:3-5 files| D[Design Doc→Implementation]
+    B -->|Large:6+ files| E[PRD→ADR→Design Doc→Implementation]
+```
+
+## Inside /implement Command
+
+```mermaid
+graph TD
+    Start["/implement requirements"] --> RA["requirement-analyzer scale detection"]
+    RA -->|Small| Direct[Direct implementation]
+    RA -->|Medium| TD["technical-designer Design Doc"]
+    RA -->|Large| PRD["prd-creator PRD"]
+    
+    PRD --> ADR["technical-designer ADR"]
+    ADR --> TD
+    TD --> WP["work-planner Work plan"]
+    WP --> TE["task-executor Execute tasks"]
+    Direct --> QF["quality-fixer Quality checks"]
+    TE --> QF
+    QF --> End[Complete]
+    
+    style Start fill:#e1f5fe
+    style End fill:#c8e6c9
+```
+
+---
+
+# Detailed Use Cases
+
+## Want to add a feature?
+
+```bash
+/implement Add webhook API with retry logic and signature verification
+```
+
+The LLM automatically detects scale, creates necessary documentation, and completes the implementation.
+
+## Want to fix a bug?
+
+```bash
+/task Fix email validation bug with "+" character
+```
+
+Clarifies rules before fixing the issue.
+`/task` triggers a process of metacognition (self-reflection on reasoning). It helps the LLM clarify the situation, retrieve relevant rules, build task lists, and understand the work context—improving execution accuracy.
+
+## Want design only?
+
+```bash
+/design Design large-scale batch processing system
+```
+
+Creates design documents, conducts LLM self-review, requests user review as needed, and finalizes the design docs. Does not implement.
+
+## Want to work step by step?
+
+Execute Design → Plan → Build individually. You can work more incrementally by specifying phases directly in the command arguments.
+
+```bash
+/design                    # Create design docs
+/plan                      # Create work plan
+/build implement phase 1   # Execute implementation (with phase specification)
+```
+
+## Want to resume work?
+
+```bash
+# Check progress
+ls docs/plans/tasks/*.md | head -5
+git log --oneline -5
+
+# Resume with the build command
+/build auth-implementation
+# Or simply continue where you left off
+/build
+```
+
+Tasks are marked complete with checkmarks (- [x]) in Markdown format.
+Some Claude Code models may not automatically mark tasks as completed. In that case, you can instruct: "Please mark completed tasks by reviewing the commit history."
+
+## Want code review?
+
+```bash
+/review  # Check Design Doc compliance
+```
+
+Auto-fix is suggested if compliance is below 70%.
+Fixes are created as task files under `docs/plans/tasks` and executed by sub-agents.
+
+## Want to initialize or customize project settings?
+
+```bash
+/project-inject  # Set project context
+/sync-rules      # Sync metadata
+```
+
+---
+
+# Command Reference
+
+## Scale Detection Criteria
+
+| Scale | Files | Examples | Generated Docs |
+|-------|-------|----------|----------------|
+| Small | 1-2 | Bug fixes, refactoring | None |
+| Medium | 3-5 | API additions, rate limiting | Design Doc + Work plan |
+| Large | 6+ | Auth system, payment system | PRD + ADR + Design Doc + Work plan |
+
+## Command Details
+
+### /implement
+**Purpose**: Full automation from requirements to implementation
+**Args**: Requirements description
+**Process**:
+1. requirement-analyzer detects scale
+2. Generate docs based on scale
+3. task-executor implements
+4. quality-fixer ensures quality
+5. Commit per task
+
+Helps clarify requirements and creates design documents. Creates work plans and task files from design docs, then completes implementation according to the plan.
+Aimed at completing Agentic Coding (LLMs autonomously making decisions and executing implementation tasks), performing automatic execution following the flow with minimal human intervention except for design clarification and handling issues beyond LLM judgment.
+
+### /task
+**Purpose**: Rule-based high-precision task execution
+**Args**: Task description
+**Process**:
+1. Clarify applicable rules
+2. Determine initial action
+3. Confirm restrictions
+4. Execute task
+
+Encourages metacognition (self-reflection on reasoning), understands task essence and applicable rules, then refines the specified task. Uses the `rule-advisor` sub-agent to retrieve and utilize appropriate rules from rule files under `docs/rules`.
+
+### /design
+**Purpose**: Design docs creation (no implementation)
+**Args**: What to design
+**Process**:
+1. Requirements analysis (requirement-analyzer)
+2. PRD creation (if large scale)
+3. ADR creation (if tech choices needed)
+4. Design Doc creation
+5. End with approval
+
+Interacts with users to organize requirements and create various design documents. Determines necessary documents based on implementation scale, finalizes design docs through creation, self-review, and user review reflection.
+Use when not adopting the full design-to-implementation process via `/implement`.
+
+### /plan
+**Purpose**: Create work plan
+**Args**: [design doc name] (optional)
+**Prerequisite**: Design Doc must exist
+**Process**:
+1. Select design doc
+2. Confirm E2E test generation
+3. work-planner creates plan
+4. Get approval
+
+Creates work plan from Design Doc. Also creates integration/E2E tests required for implementation.
+Use when not adopting the full design-to-implementation process via `/implement`.
+
+### /build
+**Purpose**: Automated implementation execution
+**Args**: [task file name] (optional)
+**Prerequisite**: Task files or work plan must exist
+**Process**:
+1. Check task files
+2. Generate with task-decomposer if missing
+3. Execute with task-executor
+4. quality-fixer checks quality
+5. Commit per task
+
+Executes implementation tasks described in specified task files. If only work plan exists without task files, uses `task-decomposer` to break down tasks before executing.
+Use when not adopting the full design-to-implementation process via `/implement`.
+
+Unless specified otherwise, automatically executes until completing the implementation described in the plan. If you want work done in phases or task units, clearly communicate the desired phase in arguments. Be careful as explicitly interrupting implementation midway may leave code in an unexecutable state.
+
+**Example for phase-based implementation**
+```bash
+/build Refer to docs/plans/tasks and complete phase 1 tasks
+```
+
+### /review
+**Purpose**: Design Doc compliance, code quality verification
+**Args**: [Design Doc name] (optional)
+**Process**:
+1. code-reviewer calculates compliance
+2. List unmet items
+3. Suggest auto-fixes
+4. Execute fixes with task-executor after approval
+
+Conducts code review. Primarily reviews whether implementation complies with Design Doc and meets rule-based code quality standards, providing feedback. Creates task files and uses sub-agents like `task-executor` to fix issues upon user instruction.
+Use when not adopting the full design-to-implementation process via `/implement`.
+
+### /refine-rule
+**Purpose**: Rule improvement
+**Args**: What to change
+**Process**:
+1. Select rule file
+2. Create change proposal
+3. 3-pass review process
+4. Apply
+
+Assists with rule file editing. Since rules must be optimized for LLMs to maintain execution accuracy, creating optimal rules with this command alone is difficult. Refer to the [Rule Editing Guide](./rule-editing-guide.md) and refine rules through command usage or direct dialogue with LLMs.
+
+### /sync-rules
+**Purpose**: Sync rule metadata
+**Args**: None
+**When**: After rule file edits
+
+Updates metadata files used by the `rule-advisor` sub-agent to find rules to reference. Must be executed after changing rules. Not needed if rules haven't changed.
+
+Common behavior patterns:
+- "9 files checked, all synchronized, no updates needed" → This is normal
+- "3 improvement suggestions: [specific suggestions]" → Approve as needed
+- Forcing changes every time → This is inappropriate behavior, please report
+
+### /project-inject
+**Purpose**: Set project context
+**Args**: None
+**Process**: Interactive project information collection
+
+**When to use**:
+- Initial setup (required)
+- When project direction changes significantly
+- When target users change
+- When business requirements change significantly
+
+This command sets project background information as rule files to maximize the probability of work being done with understanding of context. Therefore, it doesn't need to be run daily. Use only at initial setup and when fundamental project assumptions change.
+
+
+---
+
+# Troubleshooting
+
+## Task Files
+
+Task files exist under `docs/plans/tasks`. Implementation is performed in units of these task files, with completed tasks marked with Markdown checkmarks (- [x]) upon completion.
+Some Claude Code models may not automatically mark tasks as completed. In that case, you can instruct: "Please mark completed tasks by reviewing the commit history."
+
+## When implementation is interrupted
+
+Use the `/implement` or `/build` commands to resume work.
+```bash
+/implement Resume from task 3 and complete the work
+/build Search for incomplete tasks from docs/plans/tasks and resume implementation
+```
+
+| Issue | Check Command | Solution |
+|-------|---------------|----------|
+| Repeating same error | `npm run check:all` | Check environment, fix with `/task` |
+| Code differs from design | `/review` | Check compliance, auto-fix |
+| Task stuck | `ls docs/plans/tasks/` | Identify blocker, check task file |
+| Command not recognized | `ls .claude/commands-en/` | Check typo |
+
+---
+
+# Examples
+
+## Webhook Feature (Medium scale – about 4 files)
+```bash
+/implement External system webhook API
+```
+**Generated files**:
+- docs/design/webhook-system.md
+- src/services/webhook.service.ts
+- src/services/retry.service.ts
+- src/controllers/webhook.controller.ts
+
+## Auth System (Large scale – 10+ files)
+```bash
+/implement JWT auth with RBAC system
+```
+**Generated files**:
+- docs/prd/auth-system.md
+- docs/adr/auth-architecture.md
+- docs/design/auth-system.md
+- src/auth/ (implementation files)
+
+---
+
+## Next Steps
+
+Once you understand the basics, start applying them in practice. As you gain experience and feel the need to improve, try customizing the rules.
+
+→ **[Rule Editing Guide](./rule-editing-guide.md)** - How to understand LLM characteristics and create effective rules
+
+See command definitions in `.claude/commands-en/` for details.
+Having issues? Check [GitHub Issues](https://github.com/shinpr/ai-coding-project-boilerplate/issues).