ccjk 1.3.7 → 1.5.0

package/templates/claude-code/en/workflow/essential/commands/feat.md

@@ -1,105 +1,250 @@
 ---
-description: Add New Feature
+description: 'Feature Development Command - Intelligent Planning, Design, and Implementation Workflow'
+argument-hint: <feature description> [--plan] [--design] [--execute] [--quick]
+# examples:
+#   - /feat user login feature                  # Full flow: Plan → Design → Implement
+#   - /feat add dark mode --plan                # Generate planning doc only
+#   - /feat shopping cart --design              # Skip planning, go to design
+#   - /feat fix form validation --quick         # Quick mode, simplified flow
+#   - /feat --execute                           # Continue executing existing plan
 ---
 
+# Feature Development Command
+
+> **Core Philosophy**: Plan First, Design-Driven, Quality Priority
+
+## Usage
+
+```bash
+/feat <feature description> [options]
+```
+
+### Options
+
+| Option | Description |
+|--------|-------------|
+| `--plan` | Generate planning document only, don't execute |
+| `--design` | Skip planning, go directly to UI design |
+| `--execute` | Continue executing existing plan |
+| `--quick` | Quick mode, simplified workflow |
+
+---
+
+## Feature Description
+
 $ARGUMENTS
 
-## Core Workflow
+---
+
+## Intelligent Workflow
+
+### Phase 0: Input Analysis
+
+For each input, first perform **type identification** and clearly communicate:
+
+```
+📋 Operation Type: [Requirement Planning | Discussion Iteration | Execution Implementation]
+```
+
+**Identification Criteria**:
 
-### 1. Input Analysis and Type Determination
+| Type | Trigger Condition | Example Input |
+|------|-------------------|---------------|
+| 🆕 Requirement Planning | New feature request, project idea | "Add user auth", "Implement cart" |
+| 🔄 Discussion Iteration | Modify, refine existing plan | "Adjust the approach", "Continue discussion" |
+| ⚡ Execution Implementation | Confirm to start implementation | "Start executing", "Implement as planned" |
 
-When receiving user input, first perform type determination and clearly inform the user:
+---
+
+### Phase 1: Requirement Planning 🆕
 
-**Determination Criteria:**
+**Trigger**: Identified as new feature requirement
 
-- **Requirement Planning Type**: User proposes new feature requirements, project ideas, or needs to formulate plans
+**Execution Flow**:
 
-- **Discussion Iteration Type**: User requests to continue discussion, modify, or refine existing planning
+1. **Enable Planner Agent** for deep analysis
+2. **Generate planning document** stored in `.ccjk/plan/current/`
+3. **Document naming**: `feature-name.md`
 
-- **Execution Implementation Type**: User confirms planning is complete and requests to start specific implementation work
+**Planning Document Structure**:
 
-### 2. Classification Processing Mechanism
+```markdown
+# Feature Plan: [Feature Name]
 
-#### A. Requirement Planning Processing
+## 📋 Overview
+- Feature objective
+- Expected value
+- Impact scope
 
-**Trigger Condition**: Identified as functional requirement input
+## 🎯 Feature Breakdown
+- [ ] Sub-feature 1
+- [ ] Sub-feature 2
+- [ ] Sub-feature 3
 
-**Execution Actions**:
+## 📐 Technical Approach
+- Architecture design
+- Data model
+- API design
 
-- Enable Planner Agent
+## ✅ Acceptance Criteria
+- Functional acceptance points
+- Performance metrics
+- Test coverage
 
-- Generate detailed markdown planning document
+## ⏱️ Implementation Plan
+- Phase breakdown
+- Time estimation
+- Dependencies
+```
 
-- Store document in `./.claude/plan` directory, named in plan/xxx.md format
+---
 
-- Include: objective definition, feature breakdown, implementation steps, acceptance criteria
+### Phase 2: Discussion Iteration 🔄
 
-#### B. Discussion Iteration Processing
+**Trigger**: User requests to modify or refine plan
 
-**Trigger Condition**: User requests to continue discussion or modify planning
+**Execution Flow**:
 
-**Execution Actions**:
+1. **Retrieve previous plan** from `.ccjk/plan/current/`
+2. **Analyze user feedback** identify modification points
+3. **Enable Planner Agent** for re-planning
+4. **Version management**:
+   - Original file: `feature-name.md`
+   - Iteration versions: `feature-name-v2.md`, `feature-name-v3.md`
 
-- Retrieve and analyze previously generated planning files
+**Iteration Record**:
 
-- Identify user feedback and confirmation content
+```markdown
+## 📝 Iteration History
 
-- Enable Planner Agent
+### v2 - [timestamp]
+- Modification 1
+- Modification 2
 
-- Generate detailed markdown planning document
+### v1 - [timestamp]
+- Initial version
+```
 
-- Create a new document, for example, if the last one was plan/xxx.md, then this time it's plan/xxx-1.md, if the last one was plan/xxx-1.md, then this time it's plan/xxx-2.md, and so on
+---
 
-- Reorganize pending implementation task priorities
+### Phase 3: Execution Implementation ⚡
+
+**Trigger**: User confirms plan is complete
+
+**Execution Flow**:
+
+```
+┌─────────────────────────────────────────────────────────┐
+│  📋 Read Planning Document                              │
+│       ↓                                                 │
+│  🔍 Identify Subtask Types                              │
+│       ↓                                                 │
+│  ┌─────────────┬─────────────┬─────────────┐           │
+│  │ Frontend    │ Backend     │ Other       │           │
+│  │ Tasks       │ Tasks       │ Tasks       │           │
+│  │     ↓       │     ↓       │     ↓       │           │
+│  │ UI Design   │ Direct      │ Direct      │           │
+│  │ Check       │ Implement   │ Implement   │           │
+│  │     ↓       │             │             │           │
+│  │ No Design?  │             │             │           │
+│  │     ↓       │             │             │           │
+│  │ UI-UX Agent │             │             │           │
+│  └─────────────┴─────────────┴─────────────┘           │
+│       ↓                                                 │
+│  ✅ Complete and Update Status                          │
+└─────────────────────────────────────────────────────────┘
+```
+
+**Frontend Task Special Handling**:
+
+1. **Check UI Design** - Does design exist?
+2. **No Design** - Must invoke `UI-UX-Designer Agent`
+3. **After Design** - Proceed with development
 
-#### C. Execution Implementation Processing
+---
 
-**Trigger Condition**: User confirms planning is complete and requests to start execution
+## Quick Commands
 
-**Execution Actions**:
+During feature development, use these shortcuts:
 
-- Start task execution in the order of planning documents
+| Command | Description |
+|---------|-------------|
+| `!plan` | View current planning document |
+| `!status` | View task completion status |
+| `!next` | Execute next subtask |
+| `!pause` | Pause execution, save progress |
+| `!design` | Invoke UI-UX-Designer |
+| `!test` | Generate tests for current feature |
 
-- Perform task type identification before each subtask begins
+---
 
-- **Frontend Task Special Processing**:
+## State Management
 
-- Check if available UI design exists
+### Task Status Tracking
 
-- If no design solution exists, must use UI-UX-Designer Agent
+```markdown
+## 📊 Execution Status
 
-- Complete UI design before proceeding with development implementation
+| Subtask | Status | Progress |
+|---------|--------|----------|
+| Data model design | ✅ Complete | 100% |
+| API development | 🔄 In Progress | 60% |
+| Frontend implementation | ⏳ Pending | 0% |
+| Unit test writing | ⏳ Pending | 0% |
+```
 
-### 3. Key Execution Principles
+### Progress Visualization
 
-#### Mandatory Response Requirements
+```
+Overall Progress: [████████░░░░░░░░] 50%
 
-- **Must first state in every interaction**: "I determine this operation type as: [specific type]"
+✅ Completed: 2/4 subtasks
+🔄 In Progress: 1/4 subtasks
+⏳ Pending: 1/4 subtasks
+```
 
-- Type determination must be accurate and clearly communicated to users
+---
 
-#### Task Execution Standards
+## Quality Assurance
 
-- Strictly execute according to documented planning
+### Mandatory Checkpoints
 
-- Must clarify task nature and dependencies before subtask startup
+1. **Planning Phase** - Must include acceptance criteria
+2. **Design Phase** - Frontend tasks must have UI design
+3. **Implementation Phase** - Update status after each subtask
+4. **Completion Phase** - Verify against acceptance criteria
 
-- Frontend tasks must ensure UI design completeness
+### Code Quality Requirements
 
-#### State Management Mechanism
+- Follow existing project code style
+- Add necessary type definitions
+- Write unit tests (coverage > 80%)
+- Update relevant documentation
 
-- Maintain task completion status tracking
+---
 
-- Timely update planning document status
+## Output Format
 
-- Ensure user visibility of progress
+### Response Structure
 
-## Quality Assurance Points
+```
+📋 Operation Type: [Type]
+📍 Current Phase: [Phase]
+📊 Overall Progress: [Progress Bar]
 
-1. **Type Determination Accuracy**: Type identification at the beginning of each interaction must be accurate
+---
+
+[Specific Content]
+
+---
+
+💡 Next Step: [Suggested Action]
+```
+
+---
 
-2. **Document Consistency**: Planning documents and actual execution remain synchronized
+## Start Execution
 
-3. **Dependency Management**: Pay special attention to UI design dependencies of frontend tasks
+**Feature Request**: $ARGUMENTS
 
-4. **Transparent User Communication**: All judgments and actions must be clearly communicated to users
+Analyzing input type and initiating appropriate workflow...

package/templates/claude-code/zh-CN/workflow/essential/commands/feat.md

@@ -1,105 +1,248 @@
 ---
-description: '用于新增功能开发的命令，支持完整的开发流程和工具集成'
+description: '功能开发命令 - 智能规划、设计、实施一体化工作流'
+argument-hint: <功能描述> [--plan] [--design] [--execute] [--quick]
+# examples:
+#   - /feat 用户登录功能                    # 完整流程：规划 → 设计 → 实施
+#   - /feat 添加暗色模式 --plan             # 仅生成规划文档
+#   - /feat 购物车功能 --design             # 跳过规划，直接设计
+#   - /feat 修复表单验证 --quick            # 快速模式，简化流程
+#   - /feat --execute                       # 继续执行已有规划
 ---
 
+# 功能开发命令
+
+> **核心理念**: 规划先行，设计驱动，质量优先
+
+## 使用方法
+
+```bash
+/feat <功能描述> [选项]
+```
+
+### 选项说明
+
+| 选项 | 说明 |
+|------|------|
+| `--plan` | 仅生成规划文档，不执行 |
+| `--design` | 跳过规划，直接进入 UI 设计 |
+| `--execute` | 继续执行已有规划 |
+| `--quick` | 快速模式，简化流程 |
+
+---
+
+## 功能描述
+
 $ARGUMENTS
 
-## 核心工作流程
+---
+
+## 智能工作流程
+
+### 阶段 0：输入分析
+
+每次收到输入时，首先进行**类型识别**并明确告知：
+
+```
+📋 操作类型识别：[需求规划 | 讨论迭代 | 执行实施]
+```
+
+**识别标准**：
 
-### 1. 输入分析与类型判断
+| 类型 | 触发条件 | 示例输入 |
+|------|----------|----------|
+| 🆕 需求规划 | 新功能需求、项目构想 | "添加用户认证"、"实现购物车" |
+| 🔄 讨论迭代 | 修改、完善已有规划 | "调整一下方案"、"继续讨论" |
+| ⚡ 执行实施 | 确认开始实施 | "开始执行"、"按计划实施" |
 
-每次收到用户输入时，首先进行类型判断并明确告知用户：
+---
+
+### 阶段 1：需求规划 🆕
 
-**判断标准：**
+**触发**: 识别为新功能需求
 
-- **需求规划类型**: 用户提出新功能需求、项目构想或需要制定计划
+**执行流程**:
 
-- **讨论迭代类型**: 用户要求继续讨论、修改或完善已有规划
+1. **启用 Planner Agent** 进行深度分析
+2. **生成规划文档** 存储至 `.ccjk/plan/current/`
+3. **文档命名**: `功能名称.md`
 
-- **执行实施类型**: 用户确认规划完成，要求开始具体实施工作
+**规划文档结构**:
 
-### 2. 分类处理机制
+```markdown
+# 功能规划：[功能名称]
 
-#### A. 需求规划处理
+## 📋 概述
+- 功能目标
+- 预期价值
+- 影响范围
 
-**触发条件**: 识别为功能需求输入
+## 🎯 功能分解
+- [ ] 子功能 1
+- [ ] 子功能 2
+- [ ] 子功能 3
 
-**执行动作**:
+## 📐 技术方案
+- 架构设计
+- 数据模型
+- API 设计
 
-- 启用 Planner Agent
+## ✅ 验收标准
+- 功能验收点
+- 性能指标
+- 测试覆盖
 
-- 生成详细的 markdown 规划文档
+## ⏱️ 实施计划
+- 阶段划分
+- 时间估算
+- 依赖关系
+```
 
-- 将文档存储至 `./.claude/plan` 目录，并以 plan/xxx.md 的格式命名
+---
 
-- 包含：目标定义、功能分解、实施步骤、验收标准
+### 阶段 2：讨论迭代 🔄
 
-#### B. 讨论迭代处理
+**触发**: 用户要求修改或完善规划
 
-**触发条件**: 用户要求继续讨论或修改规划
+**执行流程**:
 
-**执行动作**:
+1. **检索上次规划** 从 `.ccjk/plan/current/` 读取
+2. **分析用户反馈** 识别修改点
+3. **启用 Planner Agent** 重新规划
+4. **版本管理**:
+   - 原文件: `功能名称.md`
+   - 迭代版本: `功能名称-v2.md`, `功能名称-v3.md`
 
-- 检索并分析上次生成的规划文件
+**迭代记录**:
 
-- 识别用户反馈和确认内容
+```markdown
+## 📝 迭代历史
 
-- 启用 Planner Agent
+### v2 - [时间戳]
+- 修改点 1
+- 修改点 2
 
-- 生成详细的 markdown 规划文档
+### v1 - [时间戳]
+- 初始版本
+```
 
-- 建立一个新的文档，比如上一次是 plan/xxx.md，那么这次就是 plan/xxx-1.md，如果上一次是 plan/xxx-1.md，那么这次就是 plan/xxx-2.md，以此类推
+---
 
-- 重新组织待实施任务优先级
+### 阶段 3：执行实施 ⚡
+
+**触发**: 用户确认规划完成
+
+**执行流程**:
+
+```
+┌─────────────────────────────────────────────────────────┐
+│  📋 读取规划文档                                         │
+│       ↓                                                 │
+│  🔍 识别子任务类型                                       │
+│       ↓                                                 │
+│  ┌─────────────┬─────────────┬─────────────┐           │
+│  │ 前端任务    │ 后端任务    │ 其他任务    │           │
+│  │     ↓       │     ↓       │     ↓       │           │
+│  │ UI 设计检查 │ 直接实施    │ 直接实施    │           │
+│  │     ↓       │             │             │           │
+│  │ 无设计？    │             │             │           │
+│  │     ↓       │             │             │           │
+│  │ UI-UX Agent │             │             │           │
+│  └─────────────┴─────────────┴─────────────┘           │
+│       ↓                                                 │
+│  ✅ 完成并更新状态                                       │
+└─────────────────────────────────────────────────────────┘
+```
+
+**前端任务特殊处理**:
+
+1. **检查 UI 设计** - 是否存在设计稿
+2. **无设计时** - 必须调用 `UI-UX-Designer Agent`
+3. **设计完成后** - 再进行开发实施
 
-#### C. 执行实施处理
+---
 
-**触发条件**: 用户确认规划完成，要求开始执行
+## 快捷指令
 
-**执行动作**:
+在功能开发过程中，可使用以下快捷指令：
 
-- 按规划文档顺序启动任务执行
+| 指令 | 说明 |
+|------|------|
+| `!plan` | 查看当前规划文档 |
+| `!status` | 查看任务完成状态 |
+| `!next` | 执行下一个子任务 |
+| `!pause` | 暂停执行，保存进度 |
+| `!design` | 调用 UI-UX-Designer |
+| `!test` | 为当前功能生成测试 |
 
-- 每个子任务开始前进行任务类型识别
+---
 
-- **前端任务特殊处理**:
+## 状态管理
 
-- 检查是否存在可用 UI 设计
+### 任务状态追踪
 
-- 如无设计方案，must use UI-UX-Designer Agent
+```markdown
+## 📊 执行状态
 
-- 完成 UI 设计后再进行开发实施
+| 子任务 | 状态 | 进度 |
+|--------|------|------|
+| 数据模型设计 | ✅ 完成 | 100% |
+| API 接口开发 | 🔄 进行中 | 60% |
+| 前端页面实现 | ⏳ 待开始 | 0% |
+| 单元测试编写 | ⏳ 待开始 | 0% |
+```
 
-### 3. 关键执行原则
+### 进度可视化
 
-#### 强制响应要求
+```
+整体进度: [████████░░░░░░░░] 50%
 
-- **每次交互必须首先说明**: "我判断此次操作类型为：[具体类型]"
+✅ 已完成: 2/4 子任务
+🔄 进行中: 1/4 子任务
+⏳ 待开始: 1/4 子任务
+```
 
-- 类型判断必须准确且明确传达给用户
+---
 
-#### 任务执行规范
+## 质量保证
 
-- 严格按照文档化规划执行
+### 强制检查点
 
-- 子任务启动前必须明确任务性质和依赖关系
+1. **规划阶段** - 必须包含验收标准
+2. **设计阶段** - 前端任务必须有 UI 设计
+3. **实施阶段** - 每个子任务完成后更新状态
+4. **完成阶段** - 对照验收标准验证
 
-- 前端任务必须确保 UI 设计完整性
+### 代码质量要求
 
-#### 状态管理机制
+- 遵循项目现有代码风格
+- 添加必要的类型定义
+- 编写单元测试（覆盖率 > 80%）
+- 更新相关文档
 
-- 维护任务完成状态跟踪
+---
 
-- 及时更新规划文档状态
+## 输出规范
 
-- 确保用户对进度的可见性
+### 每次响应格式
 
-## 质量保证要点
+```
+📋 操作类型：[类型]
+📍 当前阶段：[阶段]
+📊 整体进度：[进度条]
 
-1. **类型判断准确性**: 每次交互开始的类型识别必须准确
+---
+
+[具体内容]
+
+---
+
+💡 下一步：[建议操作]
+```
+
+---
 
-2. **文档一致性**: 规划文档与实际执行保持同步
+## 开始执行
 
-3. **依赖关系管理**: 特别关注前端任务的 UI 设计依赖
+**功能需求**: $ARGUMENTS
 
-4. **用户沟通透明**: 所有判断和动作都要明确告知用户
+正在分析输入类型并启动相应工作流...