dev-playbooks 1.7.4 → 2.0.0

package/README.md

@@ -31,6 +31,39 @@ AI coding assistants are powerful, but often **unpredictable**:
 
 ---
 
+## ✨ v2.0.0 New Features: Human-Friendly Document Templates
+
+**Core Philosophy**: In the AI era, humans need concise information to make decisions, not reading thousands of lines of AI-generated documents.
+
+### Bottom Line Up Front (30-second understanding)
+
+Every document (proposal, design, tasks, verification) has a brief summary at the top:
+- ✅ **What will result**: List changes in plain language
+- ❌ **What won't result**: Clearly state what won't change
+- 📝 **One-sentence summary**: Understandable even for non-technical people
+
+### Alignment Check (Uncover hidden requirements)
+
+In the proposal phase, guide users through questions:
+- 👤 **Who are you?**: Quick Starter / Platform Builder / Rapid Validator
+- 🎯 **What do you want?**: Explicit requirements + hidden requirements
+- 💡 **Multi-perspective recommendations**: Different recommendations based on different roles
+
+### Default Approval Mechanism (Reduce decision fatigue)
+
+- ⏰ **User silence = agreement**: Auto-approve after timeout
+- 🎛️ **Configurable timeout**: proposal 48h / design 24h / tasks 24h / verification 12h
+- 🔒 **Retain control**: Users can reject or customize at any time
+
+### Project-Level Documents (Knowledge retention)
+
+- 📋 **User Profile** (project-profile.md): Record role, requirements, constraints, preferences
+- 📝 **Decision Log** (decision-log.md): Record all important decisions for retrospection
+
+**See**: `docs/v2.0.0-changelog.md`
+
+---
+
 ## How It Works
 
 **Hard constraint**: Test Owner and Coder **must work in separate conversations**. This is not a suggestion. Coder cannot modify `tests/**`. "Done" is defined by tests/build verification, not AI self-evaluation.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "dev-playbooks",
-  "version": "1.7.4",
+  "version": "2.0.0",
   "description": "AI-powered spec-driven development workflow",
   "keywords": [
     "devbooks",

package/skills/_shared/references/approval-configuration-guide.md

@@ -0,0 +1,285 @@
+# Approval Configuration Guide
+
+> This document explains how to configure the approval mechanism, including default approval, timeout settings, etc.
+
+## Configuration File Location
+
+```
+.devbooks/config.yaml
+```
+
+## Configuration Example
+
+```yaml
+# Approval configuration
+approval:
+  # Default approval strategy
+  # - auto_approve: Auto-approve after timeout (default)
+  # - require_explicit: Must explicitly approve
+  # - disabled: Disable approval mechanism
+  default_strategy: auto_approve
+
+  # Timeout (hours)
+  timeout:
+    proposal: 48      # Proposal needs 48 hours
+    design: 24        # Design needs 24 hours
+    tasks: 24         # Tasks needs 24 hours
+    verification: 12  # Verification needs 12 hours
+
+  # Whether explicit approval is required
+  require_explicit:
+    proposal: true    # Proposal must be explicitly approved
+    design: false     # Design can be auto-approved
+    tasks: false      # Tasks can be auto-approved
+    verification: false  # Verification can be auto-approved
+
+  # Approval methods
+  approval_methods:
+    - cli           # Command-line approval
+    - chat          # Chat approval
+    - auto          # Auto-approval
+
+  # Notification methods
+  notification:
+    - terminal      # Terminal notification
+    # - desktop     # Desktop notification (optional)
+    # - email       # Email notification (optional)
+```
+
+## Configuration Details
+
+### 1. Default Approval Strategy
+
+| Strategy | Description | Use Case |
+|----------|-------------|----------|
+| `auto_approve` | Auto-approve after timeout | Most cases (recommended) |
+| `require_explicit` | Must explicitly approve | High-risk projects |
+| `disabled` | Disable approval mechanism | Complete trust in AI |
+
+### 2. Timeout Settings
+
+- **Proposal**: 48 hours (needs more time to think)
+- **Design**: 24 hours (technical details)
+- **Tasks**: 24 hours (task breakdown)
+- **Verification**: 12 hours (acceptance results)
+
+**Recommendations**:
+- Personal projects: Can shorten timeout (e.g., 12/6/6/3 hours)
+- Team projects: Keep default timeout
+- High-risk projects: Extend timeout (e.g., 72/48/48/24 hours)
+
+### 3. Explicit Approval Required
+
+- **true**: Must explicitly approve, won't auto-approve
+- **false**: Auto-approve after timeout
+
+**Recommendations**:
+- Set Proposal to true (important decisions)
+- Set other phases to false (reduce burden)
+
+### 4. Approval Methods
+
+#### CLI Approval
+
+```bash
+# Approve
+devbooks approve <change-id> --stage proposal
+
+# Reject
+devbooks reject <change-id> --stage proposal --reason "reason"
+
+# Revise
+devbooks revise <change-id> --stage proposal
+```
+
+#### Chat Approval
+
+Say directly in chat:
+- "agree" / "approve"
+- "disagree" / "reject"
+- "I want to modify XXX"
+
+#### Auto-approval
+
+Auto-approve after timeout (based on configuration)
+
+### 5. Notification Methods
+
+- **terminal**: Terminal notification (default)
+- **desktop**: Desktop notification (requires additional configuration)
+- **email**: Email notification (requires additional configuration)
+
+## Approval Process
+
+### 1. Creation Phase
+
+After AI creates a document, it adds an approval block at the end:
+
+```markdown
+## ✅ Approval Process
+
+**Current status**:
+- 📝 Status: Pending approval
+- ⏰ Created at: 2026-01-19 10:00
+- ⏰ Timeout at: 2026-01-20 10:00 (after 24 hours)
+
+**If you agree**:
+- [ ] ✅ Approve, start next phase
+
+**If you disagree**:
+- [ ] ❌ Reject, explain reason
+
+**Default choice**: ✅ Approve (auto-approved after 24 hours)
+```
+
+### 2. Notification Phase
+
+System reminds users through configured notification methods:
+
+```
+⏰ Reminder: Proposal pending approval
+- Change: 20260119-1000-add-feature-x
+- Phase: Proposal
+- Timeout at: 2026-01-20 10:00 (23 hours remaining)
+- Action: devbooks approve 20260119-1000-add-feature-x --stage proposal
+```
+
+### 3. Approval Phase
+
+Users can approve through:
+
+- **CLI**: `devbooks approve <change-id> --stage proposal`
+- **Chat**: Say "agree" directly
+- **Auto**: Do nothing, wait for timeout
+
+### 4. Timeout Phase
+
+If timeout and configured as `auto_approve`, system auto-approves:
+
+```
+✅ Auto-approved: Proposal
+- Change: 20260119-1000-add-feature-x
+- Phase: Proposal
+- Reason: Auto-approved after timeout (24 hours)
+```
+
+### 5. Recording Phase
+
+All approval actions are recorded in approval history:
+
+```markdown
+## Approval History
+
+| Time | Phase | Action | Actor | Reason |
+|------|-------|--------|-------|--------|
+| 2026-01-19 10:00 | Proposal | Created | AI | - |
+| 2026-01-20 10:00 | Proposal | Auto-approved | System | 24-hour timeout |
+```
+
+## FAQ
+
+### Q1: How to disable auto-approval?
+
+Modify configuration file:
+
+```yaml
+approval:
+  default_strategy: require_explicit
+  require_explicit:
+    proposal: true
+    design: true
+    tasks: true
+    verification: true
+```
+
+### Q2: How to shorten timeout?
+
+Modify configuration file:
+
+```yaml
+approval:
+  timeout:
+    proposal: 12
+    design: 6
+    tasks: 6
+    verification: 3
+```
+
+### Q3: How to view pending approvals?
+
+```bash
+devbooks status
+```
+
+Output:
+
+```
+Pending approvals:
+- 20260119-1000-add-feature-x (Proposal, 23 hours remaining)
+- 20260119-1100-fix-bug-y (Design, 5 hours remaining)
+```
+
+### Q4: How to batch approve?
+
+```bash
+devbooks approve --all
+```
+
+### Q5: How to revoke approval?
+
+```bash
+devbooks revoke <change-id> --stage proposal
+```
+
+## Best Practices
+
+### 1. Personal Projects
+
+```yaml
+approval:
+  default_strategy: auto_approve
+  timeout:
+    proposal: 12
+    design: 6
+    tasks: 6
+    verification: 3
+  require_explicit:
+    proposal: false
+    design: false
+    tasks: false
+    verification: false
+```
+
+### 2. Team Projects
+
+```yaml
+approval:
+  default_strategy: auto_approve
+  timeout:
+    proposal: 48
+    design: 24
+    tasks: 24
+    verification: 12
+  require_explicit:
+    proposal: true
+    design: false
+    tasks: false
+    verification: false
+```
+
+### 3. High-risk Projects
+
+```yaml
+approval:
+  default_strategy: require_explicit
+  timeout:
+    proposal: 72
+    design: 48
+    tasks: 48
+    verification: 24
+  require_explicit:
+    proposal: true
+    design: true
+    tasks: true
+    verification: true
+```

package/skills/_shared/references/document-template-decision-log.md

@@ -0,0 +1,137 @@
+# Decision Log Document Template
+
+> This template defines the standard structure for decision-log.md, used to record all important decisions for easy retrospection and learning.
+
+## File Location
+
+```
+<truth-root>/specs/_meta/decision-log.md
+```
+
+## Standard Structure
+
+```markdown
+# Decision Log: <Project Name>
+
+> **Purpose**: Record all important decisions for easy retrospection and learning
+
+## Decision #001: [Decision Title]
+
+**Decision time**: YYYY-MM-DD
+**Decision phase**: Proposal / Design / Tasks / Verification
+**Decision maker**: User / AI recommendation / Default
+
+**Background**:
+[Why this decision needs to be made]
+
+**Options**:
+- Option A: [Description]
+  - Advantages: [Advantages]
+  - Disadvantages: [Disadvantages]
+  - Suitable for: [What scenarios]
+
+- Option B: [Description]
+  - Advantages: [Advantages]
+  - Disadvantages: [Disadvantages]
+  - Suitable for: [What scenarios]
+
+**Decision**:
+Choose option [X]
+
+**Reason**:
+- [Reason 1]
+- [Reason 2]
+- [Reason 3]
+
+**Impact**:
+- ✅ [Positive impact]
+- ⚠️ [Negative impact]
+- ⚠️ [Risk]
+
+**Subsequent evolution**:
+- YYYY-MM-DD: [Evolution record]
+
+---
+
+## Decision #002: [Decision Title]
+
+...
+
+---
+
+## Decision Template
+
+**Decision #XXX: [Decision Title]**
+
+**Decision time**: YYYY-MM-DD
+**Decision phase**: Proposal / Design / Tasks / Verification
+**Decision maker**: User / AI recommendation / Default
+
+**Background**:
+[Why this decision needs to be made]
+
+**Options**:
+- Option A: [Description]
+- Option B: [Description]
+- Option C: [Description]
+
+**Decision**:
+Choose option X
+
+**Reason**:
+- [Reason 1]
+- [Reason 2]
+- [Reason 3]
+
+**Impact**:
+- ✅ [Positive impact]
+- ⚠️ [Negative impact]
+- ⚠️ [Risk]
+
+**Subsequent evolution**:
+- YYYY-MM-DD: [Evolution record]
+```
+
+## Usage Guide
+
+### 1. Who writes Decision Log?
+
+- **proposal-author**: Records decisions from Proposal phase
+- **design-doc**: Records decisions from Design phase
+- **implementation-plan**: Records decisions from Tasks phase
+- **archiver**: Organizes decision log during archiving
+
+### 2. Who reads Decision Log?
+
+| Skill | Reading Purpose |
+|-------|-----------------|
+| proposal-author | Understand historical decisions, avoid repeated discussions |
+| design-doc | Understand historical reasons for technology selection |
+| impact-analysis | Assess long-term impact of decisions |
+| archiver | Organize decision log, build knowledge base |
+
+### 3. Purpose of Decision Log
+
+- **Knowledge retention**: Record background, reasons, and impact of decisions
+- **Avoid repetition**: Avoid repeated discussions of the same issues
+- **Learning and improvement**: Review subsequent evolution of decisions, learn lessons
+- **Team collaboration**: Help new members quickly understand project's decision history
+
+### 4. Decision Log Update Frequency
+
+- **Real-time updates**: Record immediately when important decisions are made
+- **Regular review**: Review monthly, update "Subsequent evolution" section
+- **Archiving organization**: Organize decision log during each archiving, remove outdated decisions
+
+### 5. What decisions need to be recorded?
+
+**Decisions to record**:
+- Technology selection (choosing A over B)
+- Architecture design (choosing solution A over solution B)
+- Important trade-offs (sacrificing X for Y)
+- Boundary conditions (explicitly not doing something)
+
+**Decisions not to record**:
+- Obvious decisions (like using Git for version control)
+- Temporary decisions (like variable naming)
+- Reversible decisions (like code formatting)

package/skills/_shared/references/document-template-design.md

@@ -0,0 +1,202 @@
+# Design Document Template
+
+> This template defines the standard structure for design.md to ensure designs are clear, implementable, and verifiable.
+
+## File Location
+
+```
+<change-root>/<change-id>/design.md
+```
+
+## Standard Structure
+
+```markdown
+# <Change Title> - Design Document
+
+## 🎯 Bottom Line Up Front (30-second read)
+
+**This design will result in**:
+- ✅ [Change 1 that will happen]
+- ✅ [Change 2 that will happen]
+- ✅ [Change 3 that will happen]
+
+**This design will NOT result in**:
+- ❌ [What won't happen 1]
+- ❌ [What won't happen 2]
+
+**Difference from Proposal**:
+- 📝 Proposal said "[Proposal content]"
+- 🎨 Design says "[Specific implementation approach]"
+
+---
+
+## 🤔 Requirements Alignment Check (2-minute read)
+
+> Purpose: Confirm the design meets your needs
+
+### Quick Check
+
+**In the Proposal phase you chose**:
+- Role: [Role name]
+- Solution: [Solution name]
+
+**Changes in the Design phase**:
+- ⚠️ [New issues or constraints discovered]
+- ✅ [Suggested adjustments]
+- ⚠️ Trade-offs: [Explain trade-offs]
+
+**Need your confirmation**:
+- [ ] ✅ Agree with adjustments ([reason])
+- [ ] ❌ Disagree, continue with original plan ([reason])
+- [ ] 🤔 I need more information
+
+**Default choice**: ✅ Agree with adjustments (auto-approved after 24 hours)
+
+---
+
+## ✅ Approval Process (1 minute)
+
+**Current status**:
+- 📝 Status: Pending approval
+- ⏰ Created at: [time]
+- ⏰ Timeout at: [time] (after 24 hours)
+
+**If you agree**:
+- [ ] ✅ Approve design, start implementation
+
+**If you disagree**:
+- [ ] ❌ Reject design, reason: [reason]
+
+**Default choice**: ✅ Approve design (auto-approved after 24 hours)
+
+---
+
+## 📋 Detailed Design (AI reading)
+
+### What (What to do)
+
+#### Objective
+
+[Describe the design objective]
+
+#### Scope
+
+[Explain the design scope]
+
+---
+
+### Constraints
+
+#### Technical Constraints
+
+| Constraint | Description | Impact |
+|------------|-------------|--------|
+| [Constraint1] | [Description] | [Impact] |
+
+#### Business Constraints
+
+| Constraint | Description | Impact |
+|------------|-------------|--------|
+| [Constraint1] | [Description] | [Impact] |
+
+---
+
+### Architecture
+
+#### Component Diagram
+
+```
+[Use Mermaid or text to describe component relationships]
+```
+
+#### Data Flow
+
+```
+[Describe data flow]
+```
+
+#### Interface Design
+
+| Interface | Input | Output | Description |
+|-----------|-------|--------|-------------|
+| [Interface1] | [Input] | [Output] | [Description] |
+
+---
+
+### Acceptance Criteria
+
+#### AC-001: [Acceptance Criteria Title]
+
+**Description**: [One-sentence description]
+
+**Acceptance conditions**:
+- [ ] [Condition 1]
+- [ ] [Condition 2]
+
+**Testing approach**: [Explain how to test]
+
+---
+
+### Documentation Impact
+
+#### Documents to Update
+
+| Document | Update Reason | Priority |
+|----------|---------------|----------|
+| [Document1] | [Reason] | P0 |
+
+#### Documents Not Requiring Updates
+
+- [ ] This change is an internal refactoring and doesn't affect user-visible functionality
+- [ ] This change only fixes bugs and doesn't introduce new features
+
+---
+
+### Architecture Impact
+
+#### New Dependencies
+
+| Dependency | Version | Purpose | Risk |
+|------------|---------|---------|------|
+| [Dependency1] | [Version] | [Purpose] | [Risk] |
+
+#### Modified Modules
+
+| Module | Modification Type | Impact Scope |
+|--------|-------------------|--------------|
+| [Module1] | [Add/Modify/Delete] | [Impact scope] |
+
+---
+
+## Approval History
+
+| Time | Phase | Action | Actor | Reason |
+|------|-------|--------|-------|--------|
+| [Time] | Design | Created | AI | - |
+| [Time] | Design | Approved | User | [Reason] |
+```
+
+## Usage Guide
+
+### 1. Purpose of Bottom Line Up Front
+
+- **30-second quick understanding**: Let users immediately know the core content of the design
+- **Comparison with Proposal**: Clearly explain the difference between design and proposal
+- **Reduce cognitive load**: Use plain language, avoid technical jargon
+
+### 2. Purpose of Requirements Alignment Check
+
+- **Lightweight alignment**: Only requires user confirmation when new issues or constraints are discovered
+- **Quick decision**: In most cases, users only need to confirm "agree" or "disagree"
+- **Retain control**: Users can reject adjustments at any time
+
+### 3. Purpose of Detailed Design
+
+- **AI reading**: Provides complete technical details for AI reference
+- **Humans can skip**: Humans only need to read "Bottom Line Up Front" and "Requirements Alignment Check" sections
+
+### 4. Purpose of Acceptance Criteria
+
+- **Testable**: Each acceptance criterion should be testable
+- **Traceable**: Acceptance criteria should correspond to Proposal objectives
+- **Verifiable**: Acceptance criteria should clearly explain how to verify

package/skills/_shared/references/document-template-project-profile.md

@@ -0,0 +1,159 @@
+# Project Profile Document Template
+
+> This template defines the standard structure for project-profile.md, used to record user profiles, core requirements, and decision preferences.
+
+## File Location
+
+```
+<truth-root>/specs/_meta/project-profile.md
+```
+
+## Standard Structure
+
+```markdown
+# Project Profile: <Project Name>
+
+## 👤 Who are you? (Role positioning)
+
+**Current role**: [Quick starter / Platform builder / Fast validator / Other]
+
+**Role characteristics**:
+- Core needs: [Simple, fast, good enough / Scalable, high quality / Fastest to see results]
+- Technical preference: [Out-of-the-box / Architecture-first / Prototype-first]
+- Time budget: [1-2 days / 1-2 weeks / Unlimited]
+- Technical level: [Beginner / Intermediate / Advanced]
+
+**Role evolution**:
+- [Date]: [Role] (Initial)
+- [Date]: [Role] (Upgraded) ← If upgraded
+
+---
+
+## 🎯 What do you want? (Core requirements)
+
+### Explicit Requirements (What you clearly stated)
+
+**Functional requirements**:
+- ✅ [Requirement 1]
+- ✅ [Requirement 2]
+- ❌ Don't need [Requirement 3]
+
+**Non-functional requirements**:
+- ✅ Accuracy >[X]%
+- ✅ Performance <[X] seconds
+- ✅ Memory <[X]MB
+
+---
+
+### Hidden Requirements (What you need but didn't say)
+
+**Team collaboration**:
+- Team size: [X] people
+- Need shared cache: [Yes / No]
+- Decision reason: [Reason]
+
+**CI/CD integration**:
+- Have CI: [Yes / No]
+- Need integration: [Yes / No]
+- Decision reason: [Reason]
+
+**Offline usage**:
+- Need offline: [Yes / No]
+- Decision reason: [Reason]
+
+**Multi-project support**:
+- Multi-project: [Yes / No]
+- Decision reason: [Reason]
+
+**Historical version analysis**:
+- Need it: [Yes / No]
+- Decision reason: [Reason]
+
+---
+
+## 🚫 What don't you want? (Boundaries)
+
+**Explicitly not doing**:
+- ❌ [Thing not to do 1]
+- ❌ [Thing not to do 2]
+
+**Technical constraints**:
+- ✅ Can install new tools
+- ❌ Can't use cloud services
+- ✅ Can use space (<[X]MB)
+
+**Time constraints**:
+- ⏰ Must complete within [X] weeks
+- ⏰ Each milestone <[X] days
+
+---
+
+## 🧭 Your North Star (Long-term goals)
+
+**Long-term vision**:
+[Describe long-term vision]
+
+**Core values**:
+- [Value 1] > [Value 2]
+- [Value 3] > [Value 4]
+
+**What not to do**:
+- Don't do [Thing 1] (Reason: [Reason])
+- Don't do [Thing 2] (Reason: [Reason])
+
+---
+
+## 📊 Decision Preferences (Historical decisions)
+
+**Technology selection preference**:
+- Tendency: [Mature and stable / Cutting edge]
+- Example: [Example]
+
+**Architecture preference**:
+- Tendency: [Simple and direct / Complex and flexible]
+- Example: [Example]
+
+**Quality preference**:
+- Tendency: [Accuracy / Performance]
+- Example: [Example]
+
+---
+
+## 🔄 Profile Update Log
+
+| Date | Change | Reason |
+|------|--------|--------|
+| [Date] | Created profile | Project initialization |
+| [Date] | Role upgrade: [Old role] → [New role] | [Reason] |
+| [Date] | New requirement: [Requirement] | [Reason] |
+```
+
+## Usage Guide
+
+### 1. Who writes Project Profile?
+
+- **Initialization**: brownfield-bootstrap skill creates it during project initialization
+- **Updates**: proposal-author skill updates it with each proposal
+- **Maintenance**: archiver skill syncs updates during archiving
+
+### 2. Who reads Project Profile?
+
+| Skill | Reading Purpose |
+|-------|-----------------|
+| proposal-author | Understand user profile, recommend suitable solutions |
+| design-doc | Understand technical preferences, choose suitable architecture |
+| implementation-plan | Understand time constraints, create reasonable plans |
+| archiver | Update profile, record decision evolution |
+
+### 3. Purpose of Profile
+
+- **Personalized recommendations**: Recommend suitable solutions based on user profile
+- **Decision consistency**: Ensure all decisions align with user's long-term goals
+- **Knowledge retention**: Record user's decision preferences, avoid repeated questions
+
+### 4. Profile Update Frequency
+
+- **Initialization**: When project is created
+- **Role upgrade**: When user requirements undergo major changes
+- **New requirements**: When new hidden requirements are discovered
+- **Regular review**: Review quarterly to ensure profile accuracy

package/skills/_shared/references/document-template-proposal.md

@@ -0,0 +1,226 @@
+# Proposal Document Template
+
+> This template defines the standard structure for proposal.md to ensure proposals are clear, reviewable, and actionable.
+
+## File Location
+
+```
+<change-root>/<change-id>/proposal.md
+```
+
+## Standard Structure
+
+```markdown
+# <Change Title>
+
+## 🎯 Executive Summary (30-second read)
+
+**This proposal will result in**:
+- ✅ [Change 1 in plain language]
+- ✅ [Change 2 in plain language]
+- ✅ [Change 3 in plain language]
+
+**This proposal will NOT result in**:
+- ❌ [What won't change 1]
+- ❌ [What won't change 2]
+
+**One-sentence summary**: [Explain this change in plain language]
+
+---
+
+## 🤔 Alignment Check (5-minute read)
+
+> Purpose: Ensure direction is correct and uncover hidden requirements
+
+### Who are you? (Role identification)
+
+Please select the description that best fits you:
+
+- [ ] **Quick Starter**: Just want to implement features quickly, no hassle
+  - Core needs: Simple, fast, good enough
+  - Tech preference: Out-of-the-box, no complex configuration
+
+- [ ] **Platform Builder**: Want to develop it into a platform serving more users
+  - Core needs: Scalable, high quality, multi-scenario
+  - Tech preference: Architecture first, quality first
+
+- [ ] **Rapid Validator**: Want to quickly validate ideas, uncertain if useful
+  - Core needs: See results fastest, can optimize later
+  - Tech preference: Prototype first, rapid iteration
+
+**If you're unsure**: Default to "Quick Starter", can upgrade later.
+
+---
+
+### What do you want? (Core requirements)
+
+**Basic requirements** (all roles need):
+- [x] [Requirement 1]
+- [x] [Requirement 2]
+
+**Advanced requirements** (select based on role):
+- [ ] [Advanced requirement 1]
+- [ ] [Advanced requirement 2]
+
+**If you're unsure**: Only check basic requirements, advanced can be added later.
+
+---
+
+### What might you have missed? (Hidden requirements)
+
+> Purpose: Help you discover potentially overlooked requirements
+
+#### Hidden Requirement 1: [Requirement name]
+
+**Question**: [Guide user thinking with a question]
+
+**Why it matters**: [Explain why this requirement is important]
+
+**Please select**:
+- [ ] [Option A]
+- [ ] [Option B]
+
+**Default selection**: [Option A]
+
+---
+
+### 🎯 Based on your selection, recommended approach
+
+**If you selected "Quick Starter"**:
+Recommended approach: Simple and sufficient version
+- [Approach description]
+- Trade-off: [Explain trade-off]
+
+**If you selected "Platform Builder"**:
+Recommended approach: Complete platform version
+- [Approach description]
+- Trade-off: [Explain trade-off]
+
+**If you made no selection**:
+Default approach: Quick Starter version
+
+---
+
+## ✅ Approval Process (1 minute)
+
+### Quick Approval (Recommended)
+
+**If you agree with the recommended approach**:
+- [ ] ✅ I agree with the recommended approach, start immediately
+
+**If you want to customize**:
+- [ ] 🔧 I want to customize the approach (need to fill in the table below)
+
+**If you're unsure**:
+- [ ] 🤔 I need more information
+
+**Default selection**: ✅ I agree with the recommended approach (auto-approve after 24 hours)
+
+---
+
+## 📋 Detailed Proposal (AI reading)
+
+### Why (Why change)
+
+#### Problem Description
+
+[Describe the current problem]
+
+#### Impact
+
+[Explain the scope and severity of the problem]
+
+---
+
+### What (What to change)
+
+#### Objectives
+
+[Describe the objectives of the change]
+
+#### Scope
+
+[Explain the scope of the change]
+
+---
+
+### Impact (Impact Analysis)
+
+#### Affected Modules
+
+| Module | Impact Type | Impact Level |
+|--------|-------------|--------------|
+| [Module1] | [Add/Modify/Delete] | [High/Medium/Low] |
+
+#### Risks
+
+| Risk | Probability | Impact | Mitigation |
+|------|-------------|--------|------------|
+| [Risk1] | [High/Medium/Low] | [High/Medium/Low] | [Mitigation] |
+
+---
+
+### Alternatives (Alternative Approaches)
+
+#### Approach A: [Approach name]
+
+**Advantages**:
+- [Advantage1]
+
+**Disadvantages**:
+- [Disadvantage1]
+
+**Suitable for**: [What scenarios]
+
+#### Approach B: [Approach name]
+
+**Advantages**:
+- [Advantage1]
+
+**Disadvantages**:
+- [Disadvantage1]
+
+**Suitable for**: [What scenarios]
+
+---
+
+### Decision
+
+**Selected approach**: [Approach name]
+
+**Rationale**: [Explain selection rationale]
+
+---
+
+## Approval History
+
+| Time | Stage | Action | Actor | Reason |
+|------|-------|--------|-------|--------|
+| [Time] | Proposal | Created | AI | - |
+| [Time] | Proposal | Approved | User | [Reason] |
+```
+
+## Usage Guide
+
+### 1. Purpose of Executive Summary
+
+- **30-second quick understanding**: Let users immediately know "what will result, what won't result"
+- **Reduce cognitive load**: Use plain language, avoid technical jargon
+- **Set expectations**: Clearly state scope of changes
+
+### 2. Purpose of Alignment Check
+
+- **Role identification**: Help users clarify their role and requirements
+- **Uncover hidden requirements**: Guide users to think about potentially overlooked requirements through questions
+- **Multi-perspective recommendations**: Provide different recommendations based on different roles
+
+### 3. Purpose of Approval Process
+
+- **Default approval**: User silence = agreement (auto-approve after 24 hours)
+- **Reduce decision burden**: Most cases don't require manual approval
+- **Retain control**: Users can reject or customize at any time
+
+### 4. Purpose of Detailed Proposal
+
+- **AI reading**: Provide complete technical details for AI reference
+- **Humans can skip**: Humans only need to read "Executive Summary" and "Alignment Check" sections

package/skills/_shared/references/document-template-tasks.md

@@ -0,0 +1,181 @@
+# Tasks Document Template
+
+> This template defines the standard structure for tasks.md to ensure tasks are clear, executable, and trackable.
+
+## File Location
+
+```
+<change-root>/<change-id>/tasks.md
+```
+
+## Standard Structure
+
+```markdown
+# <Change Title> - Task Plan
+
+## 🎯 Bottom Line Up Front (30-second read)
+
+**This task will result in**:
+- ✅ [Feature 1 to be implemented]
+- ✅ [Feature 2 to be implemented]
+- ✅ Development time: [X-Y days]
+
+**This task will NOT result in**:
+- ❌ [What won't be modified 1]
+- ❌ [What won't be affected 2]
+
+**Difference from Design**:
+- 📝 Design said "[Design content]"
+- 🔨 Tasks says "Implement in [X] milestones"
+
+---
+
+## ⚡ Quick Approval (30 seconds)
+
+**Task breakdown**:
+- MP1: [Milestone 1] ([X-Y days])
+- MP2: [Milestone 2] ([X-Y days])
+- MP3: [Milestone 3] ([X-Y days])
+
+**If you agree**:
+- [ ] ✅ Agree with task breakdown, start implementation
+
+**If you want to adjust**:
+- [ ] 🔧 I want to adjust priorities (please explain)
+- [ ] 🔧 I want to adjust timeline (please explain)
+
+**Default choice**: ✅ Agree with task breakdown (auto-approved after 24 hours)
+
+---
+
+## ✅ Approval Process (1 minute)
+
+**Current status**:
+- 📝 Status: Pending approval
+- ⏰ Created at: [time]
+- ⏰ Timeout at: [time] (after 24 hours)
+
+**If you agree**:
+- [ ] ✅ Approve task plan, start implementation
+
+**If you disagree**:
+- [ ] ❌ Reject task plan, reason: [reason]
+
+**Default choice**: ✅ Approve task plan (auto-approved after 24 hours)
+
+---
+
+## 📋 Detailed Tasks (AI reading)
+
+### Main Plan
+
+#### MP1: [Milestone 1 Title]
+
+**Objective**: [Describe milestone objective]
+
+**Task list**:
+- [ ] Task 1.1: [Task description]
+  - Estimated time: [X hours]
+  - Dependencies: None
+  - Acceptance criteria: [Acceptance criteria]
+
+- [ ] Task 1.2: [Task description]
+  - Estimated time: [X hours]
+  - Dependencies: Task 1.1
+  - Acceptance criteria: [Acceptance criteria]
+
+**Milestone acceptance**:
+- [ ] [Acceptance condition 1]
+- [ ] [Acceptance condition 2]
+
+---
+
+#### MP2: [Milestone 2 Title]
+
+**Objective**: [Describe milestone objective]
+
+**Task list**:
+- [ ] Task 2.1: [Task description]
+  - Estimated time: [X hours]
+  - Dependencies: MP1
+  - Acceptance criteria: [Acceptance criteria]
+
+**Milestone acceptance**:
+- [ ] [Acceptance condition 1]
+- [ ] [Acceptance condition 2]
+
+---
+
+### Temp Plan
+
+> Temporary tasks discovered during implementation
+
+- [ ] Temp 1: [Temporary task description]
+  - Discovered at: [time]
+  - Reason: [Why this task is needed]
+  - Estimated time: [X hours]
+
+---
+
+### Checkpoint
+
+> Record key decisions and issues during implementation
+
+#### Checkpoint 1: [time]
+
+**Issue**: [Issue encountered]
+
+**Decision**: [Decision made]
+
+**Impact**: [Impact on task plan]
+
+---
+
+### Progress Tracking
+
+| Milestone | Status | Completed at | Notes |
+|-----------|--------|--------------|-------|
+| MP1 | ✅ Completed | [time] | - |
+| MP2 | 🔄 In progress | - | - |
+| MP3 | ⏳ Pending | - | - |
+
+---
+
+## Approval History
+
+| Time | Phase | Action | Actor | Reason |
+|------|-------|--------|-------|--------|
+| [Time] | Tasks | Created | AI | - |
+| [Time] | Tasks | Approved | User | [Reason] |
+```
+
+## Usage Guide
+
+### 1. Purpose of Bottom Line Up Front
+
+- **30-second quick understanding**: Let users immediately know the core content of the task
+- **Time estimation**: Clearly state development time
+- **Reduce cognitive load**: Use plain language, avoid technical jargon
+
+### 2. Purpose of Quick Approval
+
+- **Task breakdown**: Break large tasks into manageable milestones
+- **Quick decision**: Users only need to confirm "agree" or "adjust"
+- **Default approval**: Auto-approved after 24 hours
+
+### 3. Purpose of Main Plan
+
+- **Structured**: Organize tasks by milestones
+- **Trackable**: Each task has clear acceptance criteria
+- **Parallelizable**: Clearly define dependencies between tasks
+
+### 4. Purpose of Temp Plan
+
+- **Flexibility**: Record temporary tasks discovered during implementation
+- **Traceable**: Explain why this task is needed
+
+### 5. Purpose of Checkpoint
+
+- **Decision recording**: Record key decisions during implementation
+- **Issue tracking**: Record issues encountered and solutions
+- **Knowledge retention**: Provide reference for similar future tasks

package/skills/_shared/references/document-template-verification.md

@@ -0,0 +1,186 @@
+# Verification Document Template
+
+> This template defines the standard structure for verification.md to ensure acceptance is clear, testable, and traceable.
+
+## File Location
+
+```
+<change-root>/<change-id>/verification.md
+```
+
+## Standard Structure
+
+```markdown
+# <Change Title> - Verification Document
+
+## 🎯 Bottom Line Up Front (30-second read)
+
+**This verification will result in**:
+- ✅ Run [X] test cases
+- ✅ Verify accuracy >[X]%
+- ✅ Verify performance <[X] seconds
+
+**This verification will NOT result in**:
+- ❌ Won't modify code
+- ❌ Won't affect functionality
+
+**Acceptance criteria**:
+- ✅ All tests pass
+- ✅ Accuracy >[X]%
+- ✅ Performance <[X] seconds
+
+---
+
+## ✅ Verification Approval (30 seconds)
+
+**Test results**:
+- ✅ Unit tests: [X]/[Y] passed
+- ✅ Integration tests: [X]/[Y] passed
+- ✅ Performance tests: Passed ([X] seconds)
+
+**If you agree**:
+- [ ] ✅ Verification passed, ready to archive
+
+**If you disagree**:
+- [ ] ❌ Verification failed (please explain reason)
+
+**Default choice**: ✅ Verification passed (auto-approved after 12 hours)
+
+---
+
+## ✅ Approval Process (1 minute)
+
+**Current status**:
+- 📝 Status: Pending approval
+- ⏰ Created at: [time]
+- ⏰ Timeout at: [time] (after 12 hours)
+
+**If you agree**:
+- [ ] ✅ Approve verification, start archiving
+
+**If you disagree**:
+- [ ] ❌ Reject verification, reason: [reason]
+
+**Default choice**: ✅ Approve verification (auto-approved after 12 hours)
+
+---
+
+## 📋 Detailed Verification (AI reading)
+
+### Test Coverage
+
+#### Unit Tests
+
+| Test Case | Status | Description |
+|-----------|--------|-------------|
+| test_xxx_1 | ✅ Passed | [Description] |
+| test_xxx_2 | ✅ Passed | [Description] |
+
+**Coverage**: [X]%
+
+---
+
+#### Integration Tests
+
+| Test Case | Status | Description |
+|-----------|--------|-------------|
+| test_integration_1 | ✅ Passed | [Description] |
+| test_integration_2 | ✅ Passed | [Description] |
+
+---
+
+#### Performance Tests
+
+| Metric | Target | Actual | Status |
+|--------|--------|--------|--------|
+| Response time | <[X]ms | [Y]ms | ✅ Passed |
+| Throughput | >[X] QPS | [Y] QPS | ✅ Passed |
+| Memory usage | <[X]MB | [Y]MB | ✅ Passed |
+
+---
+
+### Acceptance Criteria Traceability
+
+#### AC-001: [Acceptance Criteria Title]
+
+**Source**: design.md AC-001
+
+**Acceptance conditions**:
+- [x] [Condition 1] - Test case: test_xxx_1
+- [x] [Condition 2] - Test case: test_xxx_2
+
+**Verification result**: ✅ Passed
+
+---
+
+#### AC-002: [Acceptance Criteria Title]
+
+**Source**: design.md AC-002
+
+**Acceptance conditions**:
+- [x] [Condition 1] - Test case: test_xxx_3
+- [x] [Condition 2] - Test case: test_xxx_4
+
+**Verification result**: ✅ Passed
+
+---
+
+### Regression Testing
+
+#### Existing Functionality Verification
+
+| Feature | Test Case | Status | Description |
+|---------|-----------|--------|-------------|
+| [Feature 1] | test_regression_1 | ✅ Passed | Not affected |
+| [Feature 2] | test_regression_2 | ✅ Passed | Not affected |
+
+---
+
+### Documentation Verification
+
+#### Documentation Update Check
+
+- [x] README.md updated
+- [x] User documentation updated
+- [x] API documentation updated
+- [x] CHANGELOG.md updated
+
+---
+
+## Approval History
+
+| Time | Phase | Action | Actor | Reason |
+|------|-------|--------|-------|--------|
+| [Time] | Verification | Created | AI | - |
+| [Time] | Verification | Approved | User | [Reason] |
+```
+
+## Usage Guide
+
+### 1. Purpose of Bottom Line Up Front
+
+- **30-second quick understanding**: Let users immediately know the core content of verification
+- **Test results**: Clearly state test results
+- **Reduce cognitive load**: Use plain language, avoid technical jargon
+
+### 2. Purpose of Verification Approval
+
+- **Quick decision**: Users only need to confirm "pass" or "fail"
+- **Default approval**: Auto-approved after 12 hours (shorter than other phases)
+- **Retain control**: Users can reject verification at any time
+
+### 3. Purpose of Acceptance Criteria Traceability
+
+- **Traceable**: Each acceptance criterion should correspond to an AC in Design
+- **Verifiable**: Each acceptance condition should have a corresponding test case
+- **Completeness check**: Ensure all ACs are verified
+
+### 4. Purpose of Regression Testing
+
+- **Prevent breakage**: Ensure existing functionality is not affected
+- **Quality assurance**: Ensure changes don't introduce new issues
+
+### 5. Purpose of Documentation Verification
+
+- **Documentation sync**: Ensure documentation is in sync with code
+- **User experience**: Ensure users can correctly use new features