create-claude-webapp 1.0.0

package/docs/guides/en/quickstart.md

@@ -0,0 +1,109 @@
+# Quick Start Guide for AI Development
+
+This guide walks you through setting up the AI Coding Project Boilerplate and implementing your first feature. Let's skip the complex stuff for now and just get it running.
+
+## Setup (5 minutes to complete)
+
+### For New Projects
+
+Open your terminal and run these commands. Feel free to change the project name to whatever you like.
+
+```bash
+npx github:svenmalvik/claude-boilerplate-4-web my-awesome-project
+cd my-awesome-project
+npm install
+```
+
+That's it! You now have a `my-awesome-project` folder with all the necessary files ready to use.
+
+### For Existing Projects
+
+If you already have a TypeScript project, you can copy the necessary files. First, download the boilerplate to a temporary location.
+
+```bash
+# Download the boilerplate temporarily
+npx github:svenmalvik/claude-boilerplate-4-web temp-boilerplate
+```
+
+Then copy the following files into the root directory of your existing project.
+
+```bash
+# Run in your existing project directory
+cp -r temp-boilerplate/.claude/agents .claude/agents
+cp -r temp-boilerplate/.claude/commands .claude/commands
+cp -r temp-boilerplate/docs/rules docs/rules
+cp -r temp-boilerplate/docs/adr docs/
+cp -r temp-boilerplate/docs/design docs/
+cp -r temp-boilerplate/docs/plans docs/
+cp -r temp-boilerplate/docs/prd docs/
+cp -r temp-boilerplate/docs/guides/en/sub-agents.md docs/guides/sub-agents.md
+cp temp-boilerplate/CLAUDE.md .
+```
+
+If you want to change the directory structure, you'll need to adjust paths starting with `@docs/rules/` in sub-agents and command definition files. Also update `docs/rules-index.yaml` accordingly.
+Because this can get complicated, we recommend sticking with the default structure unless you have specific needs.
+
+## Launch Claude Code and Initial Setup
+
+Launch Claude Code in your project directory.
+
+```bash
+claude
+```
+
+Once launched, let's set up project-specific information. This is a crucial step for the AI to understand your project.
+
+Run the following custom slash command inside Claude Code.
+
+```bash
+/project-inject
+```
+
+You'll be guided through an interactive dialog to clarify your project information. Feel free to answer casually - you can change this information later.
+Once you finish answering, your project context will be saved to `docs/rules/project-context.md`. This enables the AI to understand your project's purpose and generate more appropriate code.
+
+After reviewing the file and confirming it looks good, complete this step with the following command.
+
+```bash
+/sync-rules
+```
+
+## Let's Implement Your First Feature
+
+Now let's create your first feature. Specify it using the following command in Claude Code.
+
+```bash
+/implement Create a simple API that returns "Hello"
+```
+
+The `/implement` command guides you through the entire workflow from design to implementation.
+
+First, it analyzes your requirements to determine the feature scale. It might say something like "This is a medium-scale feature requiring about 3 files." Based on the scale, it creates necessary design documents.
+
+For small features, it creates just a simple work plan. For large features, it creates a complete flow from PRD (Product Requirements Document) to Design Doc (Technical Design Document). After each design document is created, an automatic review is performed.
+
+Once the design is complete, the AI will ask "Here's the design I've created. Could you review it?" Read through it and request changes if needed, or approve it if it looks good.
+Depending on the Claude Code model you're using, it may automatically proceed to the next design document if your review is positive. At some point it will ask for your approval, so you can provide batch feedback then.
+
+After design approval, integration test skeletons and a work plan are created. Once you review the implementation steps (requesting changes if needed) and approve, the actual implementation begins.
+
+The AI breaks down the work plan into single-commit task units and autonomously implements each task using a TDD approach. After each task, it performs a defined 6-step quality check, fixes any errors, and creates a commit if everything passes. You can simply watch the progress.
+
+When all tasks are complete, it will report "Implementation complete." Check `git log` to see a clean series of commits.
+
+## Development Philosophy of This Boilerplate
+
+Let me explain the thinking behind this boilerplate.
+
+To maximize throughput with AI assistance, it's crucial to minimize human intervention. However, achieving high execution accuracy with AI requires careful context management—providing the right information at the right time. Without proper systems, humans need to guide the implementation process, which prevents throughput maximization.
+
+This boilerplate solves this through systematic approaches: selecting appropriate context (rules, requirements, specifications) for each phase and limiting unnecessary information during task execution.
+
+The workflow is: create design documents, review them with users to align understanding, use those documents as context for planning and task creation. Tasks are executed by sub-agents with dedicated contexts, which removes unnecessary information and stabilizes implementation. This system helps maintain quality even for projects too large to fit within a single coding agent's context window (Claude Opus 4.1 supports 200K tokens, Sonnet 4 beta supports up to 1M tokens, but the basic limit is 200K tokens).
+
+## Troubleshooting
+
+If things aren't working, check the following.
+
+**If implementation stops midway**
+Describe the current state to Claude Code and ask it to resume, for example: "You've completed up to the Design Doc creation, so please continue from there and complete the implementation."

package/docs/guides/en/rule-editing-guide.md

@@ -0,0 +1,264 @@
+# Rule Editing Guide
+
+This guide explains the core concepts and best practices for writing effective rules that maximize LLM execution accuracy, based on how LLMs work.
+
+## Project Philosophy and the Importance of Rule Files
+
+This boilerplate is designed based on the concepts of "Agentic Coding" and "Context Engineering":
+- **Agentic Coding**: LLMs autonomously making decisions and carrying out implementation tasks
+- **Context Engineering**: Building mechanisms to provide appropriate context at the right time for LLMs to make proper decisions
+
+Proper rule management and [sub-agents](https://docs.anthropic.com/en/docs/claude-code/sub-agents) are crucial keys to realizing these concepts.
+
+Rule files are written to maximize LLM execution accuracy as described below.
+
+Sub-agents have dedicated contexts separate from the main agent. They are designed to load only the necessary rule files to fulfill specific responsibilities.
+When the main agent executes tasks, it uses "metacognition" (reflecting on and analyzing its own reasoning process) to understand task context, select necessary rules from the rule file collection, and execute tasks.
+This approach maximizes execution accuracy by retrieving the right rules at the right time without excess or deficiency.
+
+While it's impossible to completely control LLM output, it is possible to maximize execution accuracy by establishing proper systems.
+Conversely, LLM execution accuracy can easily degrade depending on rule file content.
+
+With the premise that complete control is impossible, executing tasks, reflecting on issues that arise, and feeding back into the system enables maintaining and improving execution accuracy.
+When using this in actual projects and results don't match expectations, consider improving rule files.
+
+## Determining Where to Document Rules
+
+### File Roles and Scope
+
+| File | Scope | When Applied | Example Content |
+|------|-------|--------------|-----------------|
+| **CLAUDE.md** | All tasks | Always | Approval required before Edit/Write, stop at 5+ file changes |
+| **Rule files** | Specific technical domains | When using that technology | Use specific types, error handling required, functions under 30 lines |
+| **Guidelines** | Specific workflows | When performing that workflow | Sub-agent selection strategies |
+| **Design Docs** | Specific features | When developing that feature | Feature requirements, API specifications, security constraints |
+
+### Decision Flow
+
+```
+When is this rule needed?
+├─ Always → CLAUDE.md
+├─ Only for specific feature development → Design Doc
+├─ When using specific technology → Rule files
+└─ When performing specific workflow → Guidelines
+```
+
+## 9 Rule Principles for Maximizing LLM Execution Accuracy
+
+Here are 9 rule creation principles based on LLM characteristics and this boilerplate's design philosophy.
+While we provide a `/refine-rule` custom slash command to assist with rule modifications, we ultimately recommend interactive rule editing through dialogue rather than commands, as LLMs tend to have difficulty reaching issues without comparing output with thinking after generation.
+
+### 1. Achieve Maximum Accuracy with Minimum Description (Context Pressure vs. Execution Accuracy)
+
+Context is a precious resource. Avoid redundant explanations and include only essential information.
+However, it's not just about being short - it must be the minimum description that doesn't cause decision hesitation.
+
+```markdown
+❌ Redundant description (22 words)
+Please make sure to record all errors in the log when they occur
+
+✅ Concise description (9 words)
+All errors must be logged
+
+❌ Over-abbreviated description (6 words)
+Record all errors
+```
+
+Aim for concise expressions that keep the same meaning. But don't shorten so much that ambiguity is introduced.
+
+### 2. Completely Unify Notation
+
+Always use the same terms for the same concepts. Notation inconsistencies hinder LLM understanding.
+
+```markdown
+# Term Definitions (Unified across project)
+- API response/return value → Unified as `response`
+- User/customer → Unified as `user`
+- Error/abnormality → Unified as `error` (exception/failure may be used depending on context)
+```
+
+### 3. Thoroughly Eliminate Duplication
+
+Repeating the same content across multiple files wastes context capacity. Consolidate in one place.
+
+```markdown
+❌ Same content in multiple locations
+# docs/rules/base.md
+Standard error format: { success: false, error: string, code: number }
+
+# docs/rules/api.md
+Error responses follow standard error format `{ success: false, error: string, code: number }`
+
+✅ Consolidated in one location
+# docs/rules/base.md
+Standard error format: { success: false, error: string, code: number }
+```
+
+Check for duplication between files and eliminate contradictions and redundancy.
+Eliminating duplication also reduces maintenance costs by preventing notation inconsistencies from update omissions.
+
+### 4. Appropriately Aggregate Responsibilities
+
+Consolidating related content in one file maintains single responsibility and prevents unnecessary context mixing in tasks.
+
+```markdown
+# Authentication consolidated in one file
+docs/rules/auth.md
+├── JWT Specification
+├── Authentication Flow
+├── Error Handling
+└── Security Requirements
+
+# ❌ Dispersed responsibilities
+docs/rules/auth.md
+├── JWT Specification
+├── Error Handling
+└── Security Requirements
+docs/rules/flow.md
+├── User Registration Flow
+└── Authentication Flow
+```
+
+However, if a file becomes too large, reading costs increase, so aim for logical division or rule selection around 250 lines (approximately 1,500 tokens).
+
+### 5. Set Measurable Decision Criteria
+
+Ambiguous instructions cause interpretation inconsistencies. Clarify criteria with numbers and specific conditions.
+
+```markdown
+✅ Measurable criteria
+- Function lines: 30 or less
+- Cyclomatic complexity: 10 or less
+- Response time: Within 200ms at p95
+- Test coverage: 80% or more
+
+❌ Ambiguous criteria
+- Readable code
+- Fast processing
+- Sufficient tests
+```
+
+Note that LLMs cannot understand time, so descriptions like "break down tasks to complete within 30 minutes" are not effective.
+
+### 6. Show NG Patterns as Recommendations with Background
+
+Showing recommended patterns with reasons is more effective than listing prohibitions.
+
+```markdown
+✅ Description in recommended format
+【State Management】
+Recommended: Use Zustand or Context API
+Reason: Global variables are difficult to test and state tracking is complex
+NG Example: window.globalState = { ... }
+
+❌ List of prohibitions
+- Don't use global variables
+- Don't save values to window object
+```
+
+If prohibitions are needed, present them as background context rather than the main rule.
+
+### 7. Verbalize Implicit Assumptions
+
+Even things obvious to human developers must be explicitly stated for LLMs to understand.
+
+```markdown
+## Prerequisites
+- Execution environment: Node.js 20.x on AWS Lambda
+- Maximum execution time: 15 minutes (Lambda limit)
+- Memory limit: 3GB
+- Concurrent executions: 1000 (account limit)
+- Timezone: All UTC
+- Character encoding: UTF-8 only
+```
+
+Use the `/project-inject` command at project start or when project assumptions change to document project context as rules.
+
+### 8. Arrange Descriptions by Importance
+
+LLMs pay more attention to information at the beginning. Place most important rules first, exceptional cases last.
+
+```markdown
+# API Rules
+
+## Critical Principles (Must follow)
+1. All APIs require JWT authentication
+2. Rate limit: 100 requests/minute
+3. Timeout: 30 seconds
+
+## Standard Specifications
+- Methods: Follow REST principles
+- Body: JSON format
+- Character encoding: UTF-8
+
+## Exceptional Cases (Only for special situations)
+- multipart/form-data allowed only for file uploads
+- WebSocket connections only at /ws endpoint
+```
+
+### 9. Clarify Scope Boundaries
+
+Explicitly stating what is and isn't covered prevents unnecessary processing and misunderstandings.
+
+```markdown
+## Scope of This Rule
+
+### Covered
+- REST APIs in general
+- GraphQL endpoints
+- WebSocket communication
+
+### Not Covered
+- Static file delivery
+- Health check endpoint (/health)
+- Metrics endpoint (/metrics)
+```
+
+## Reference: Efficient Rule Writing
+
+Rule files under `docs/rules` are created with these principles in mind.
+Each is written with no duplication, single responsibility, and minimal description, serving as references when adding or creating new rules.
+
+### Correspondence Between Rule Files and Applied Principles
+
+| Rule File | Main Content | Examples of Applied Principles |
+|-----------|-------------|--------------------------------|
+| **typescript.md** | TypeScript code creation/modification/refactoring, modern type features | **Principle 2**: Unified notation (consistent terms like "any type completely prohibited")<br>**Principle 5**: Measurable criteria (20 fields max, 3 nesting levels max) |
+| **typescript-testing.md** | Test creation, quality checks, development steps | **Principle 5**: Measurable criteria (coverage 70% or more)<br>**Principle 8**: Arrangement by importance (quality requirements at the top) |
+| **ai-development-guide.md** | Technical decision criteria, anti-pattern detection, best practices | **Principle 6**: Show NG patterns in recommended format (anti-pattern collection)<br>**Principle 3**: Eliminate duplication (Rule of Three for consolidation decisions) |
+| **technical-spec.md** | Technical design, environment setup, documentation process | **Principle 4**: Aggregate responsibilities (technical design in one file)<br>**Principle 7**: Verbalize implicit assumptions (security rules documented) |
+| **project-context.md** | Project-specific information, implementation principles | **Principle 7**: Verbalize implicit assumptions (project characteristics documented)<br>**Principle 1**: Maximum accuracy with minimum description (concise bullet format) |
+| **documentation-criteria.md** | Scale determination, document creation criteria | **Principle 5**: Measurable criteria (creation decision matrix)<br>**Principle 9**: Clarify scope boundaries (clearly state what's included/excluded) |
+| **implementation-approach.md** | Implementation strategy selection, task breakdown, large-scale change planning | **Principle 8**: Arrangement by importance (Phase-ordered structure)<br>**Principle 6**: Show NG patterns in recommended format (risk analysis) |
+
+All 9 principles are practiced across these files, serving as practical references for rule creation.
+
+## Troubleshooting
+
+### Problem: Rules are too long and overload the context window
+
+**Solutions**
+1. Find and remove duplications
+2. Minimize examples
+3. Utilize reference format
+4. Move low-priority rules to separate files
+
+### Problem: Inconsistent generation results
+
+**Solutions**
+1. Unify terms and notation
+2. Quantify decision criteria
+3. Clarify priorities
+4. Eliminate contradicting rules
+
+### Problem: Important rules are not followed
+
+**Solutions**
+1. Move to file beginning
+2. Add 【Required】【Important】 tags
+3. Add one specific example
+4. Convert negative form to positive form
+
+## Summary
+
+Well-written rules stabilize LLM output. By following the 9 principles and continuously refining your rules, you can maximize LLM capabilities. Build the optimal rule set for your project through regular implementation review and improvement.

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/` | 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/` for details.
+Having issues? Check [GitHub Issues](https://github.com/svenmalvik/claude-boilerplate-4-web/issues).