mirror of
https://github.com/cexll/myclaude.git
synced 2026-02-05 02:30:26 +08:00
Update Chinese README and requirements-pilot command to align with latest workflow
- Updated Chinese README to match English version terminology - Changed from spec-workflow to requirements-pilot throughout documentation - Updated quality thresholds from 95% to 90% for consistency - Replaced Sub-Agent terminology with Requirements-Driven workflow - Updated agent names from spec-* to requirements-* pattern - Improved requirements-pilot command structure with clearer phase separation - Added mandatory user approval gate before implementation phase 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
124
README-zh.md
124
README-zh.md
@@ -15,8 +15,8 @@
|
|||||||
|
|
||||||
**现在**: 一键自动化专家工作流
|
**现在**: 一键自动化专家工作流
|
||||||
```bash
|
```bash
|
||||||
/spec-workflow "实现JWT用户认证系统"
|
/requirements-pilot "实现JWT用户认证系统"
|
||||||
# 30分钟自动执行,95%质量门控,零人工干预
|
# 30分钟自动执行,90%质量门控,零人工干预
|
||||||
```
|
```
|
||||||
|
|
||||||
## 🎯 核心价值主张
|
## 🎯 核心价值主张
|
||||||
@@ -30,31 +30,30 @@
|
|||||||
|
|
||||||
## 📋 两种主要使用模式
|
## 📋 两种主要使用模式
|
||||||
|
|
||||||
### 1. 🏭 Sub-Agent 工作流(自动化专家团队)
|
### 1. 🏭 Requirements-Driven 工作流(自动化专家团队)
|
||||||
|
|
||||||
**架构**: 并行专家协调与质量门控
|
**架构**: 需求导向工作流与质量门控
|
||||||
```
|
```
|
||||||
spec-generation → spec-executor → spec-validation → (≥95%?) → spec-testing
|
requirements-generate → requirements-code → requirements-review → (≥90%?) → requirements-testing
|
||||||
↑ ↓ (<95%)
|
↑ ↓ (<90%)
|
||||||
←←←←←← 自动优化循环,直到质量达标 ←←←←←←
|
←←←←←← 自动优化循环 ←←←←←←
|
||||||
```
|
```
|
||||||
|
|
||||||
**使用方法**:
|
**使用方法**:
|
||||||
```bash
|
```bash
|
||||||
# 一条命令完成完整开发工作流
|
# 一条命令完成完整开发工作流
|
||||||
/spec-workflow "构建用户管理系统,支持RBAC权限控制"
|
/requirements-pilot "构建用户管理系统,支持RBAC权限控制"
|
||||||
|
|
||||||
# 高级多阶段工作流
|
# 高级多阶段工作流
|
||||||
先使用 spec-generation,然后 spec-executor,再用 spec-validation,
|
先使用 requirements-generate,然后 requirements-code,再用 requirements-review,
|
||||||
如果评分 ≥95% 则使用 spec-testing,最后用 optimize 优化
|
如果评分 ≥90% 则使用 requirements-testing
|
||||||
```
|
```
|
||||||
|
|
||||||
**质量评分体系** (总分100%):
|
**质量评分体系** (总分100%):
|
||||||
- 需求符合度 (30%)
|
- 功能性 (40%)
|
||||||
- 代码质量 (25%)
|
- 集成性 (25%)
|
||||||
- 安全性 (20%)
|
- 代码质量 (20%)
|
||||||
- 性能 (15%)
|
- 性能 (15%)
|
||||||
- 测试覆盖 (10%)
|
|
||||||
|
|
||||||
### 2. 🎛️ 自定义命令(手动编排)
|
### 2. 🎛️ 自定义命令(手动编排)
|
||||||
|
|
||||||
@@ -95,7 +94,7 @@ spec-generation → spec-executor → spec-validation → (≥95%?) → spec-tes
|
|||||||
|
|
||||||
**完整功能开发**:
|
**完整功能开发**:
|
||||||
```bash
|
```bash
|
||||||
/spec-workflow "实现OAuth2认证,支持刷新令牌"
|
/requirements-pilot "实现OAuth2认证,支持刷新令牌"
|
||||||
```
|
```
|
||||||
|
|
||||||
**手动开发流程**:
|
**手动开发流程**:
|
||||||
@@ -108,10 +107,11 @@ spec-generation → spec-executor → spec-validation → (≥95%?) → spec-tes
|
|||||||
### 3. 预期输出
|
### 3. 预期输出
|
||||||
|
|
||||||
**自动化工作流结果**:
|
**自动化工作流结果**:
|
||||||
- ✅ 完整规格说明 (requirements.md, design.md, tasks.md)
|
- ✅ 需求确认,90+质量评分
|
||||||
- ✅ 生产就绪代码,遵循安全最佳实践
|
- ✅ 实现就绪技术规格
|
||||||
- ✅ 全面测试套件 (单元 + 集成 + 安全测试)
|
- ✅ 生产就绪代码,遵循最佳实践
|
||||||
- ✅ 95%+ 质量验证评分
|
- ✅ 全面测试套件 (单元 + 集成 + 功能测试)
|
||||||
|
- ✅ 90%+ 质量验证评分
|
||||||
|
|
||||||
## 🏗️ 架构概览
|
## 🏗️ 架构概览
|
||||||
|
|
||||||
@@ -126,10 +126,12 @@ spec-generation → spec-executor → spec-validation → (≥95%?) → spec-tes
|
|||||||
- **运维工具**: `/deploy-check`, `/cicd`
|
- **运维工具**: `/deploy-check`, `/cicd`
|
||||||
|
|
||||||
#### **Agents 目录** (`/agents/`)
|
#### **Agents 目录** (`/agents/`)
|
||||||
- **spec-generation**: 自动化规格说明工作流
|
- **requirements-generate**: 为代码生成优化的技术规格生成
|
||||||
- **spec-executor**: 带进度跟踪的实现协调器
|
- **requirements-code**: 最小架构开销的直接实现智能体
|
||||||
- **spec-validation**: 多维度质量评分 (0-100%)
|
- **requirements-review**: 专注功能性和可维护性的实用代码审查
|
||||||
- **spec-testing**: 全面测试策略协调
|
- **requirements-testing**: 专注功能验证的实用测试智能体
|
||||||
|
- **bugfix**: 分析和修复软件缺陷的错误解决专家
|
||||||
|
- **bugfix-verify**: 客观评估的修复验证专家
|
||||||
- **code**: 直接实现的开发协调器
|
- **code**: 直接实现的开发协调器
|
||||||
- **debug**: UltraThink系统化问题分析
|
- **debug**: UltraThink系统化问题分析
|
||||||
- **optimize**: 性能优化协调
|
- **optimize**: 性能优化协调
|
||||||
@@ -137,14 +139,14 @@ spec-generation → spec-executor → spec-validation → (≥95%?) → spec-tes
|
|||||||
### 多智能体协调系统
|
### 多智能体协调系统
|
||||||
|
|
||||||
**4个核心专家**:
|
**4个核心专家**:
|
||||||
1. **规格生成专家** - 需求、设计、实现规划
|
1. **需求生成专家** - 实现就绪的技术规格
|
||||||
2. **实现执行专家** - 带任务跟踪的代码开发
|
2. **代码实现专家** - 直接、实用的代码实现
|
||||||
3. **质量验证专家** - 多维度评分与可执行反馈
|
3. **质量审查专家** - 实用质量审查与评分
|
||||||
4. **测试协调专家** - 全面测试策略与执行
|
4. **测试协调专家** - 功能验证和测试
|
||||||
|
|
||||||
**关键特性**:
|
**关键特性**:
|
||||||
- **独立上下文**: 专家间无上下文污染
|
- **独立上下文**: 专家间无上下文污染
|
||||||
- **质量门控**: 95%阈值自动进展判断
|
- **质量门控**: 90%阈值自动进展判断
|
||||||
- **迭代改进**: 自动优化循环
|
- **迭代改进**: 自动优化循环
|
||||||
- **可追溯性**: 完整规格 → 代码 → 测试追溯链
|
- **可追溯性**: 完整规格 → 代码 → 测试追溯链
|
||||||
|
|
||||||
@@ -154,27 +156,27 @@ spec-generation → spec-executor → spec-validation → (≥95%?) → spec-tes
|
|||||||
|
|
||||||
**输入**:
|
**输入**:
|
||||||
```bash
|
```bash
|
||||||
/spec-workflow "企业JWT认证系统,支持RBAC,500并发用户,集成现有LDAP"
|
/requirements-pilot "企业JWT认证系统,支持RBAC,500并发用户,集成现有LDAP"
|
||||||
```
|
```
|
||||||
|
|
||||||
**自动化执行过程**:
|
**自动化执行过程**:
|
||||||
1. **第1轮** (质量: 83/100) - 基础实现
|
1. **需求确认** (质量: 92/100) - 交互式澄清
|
||||||
- 问题: JWT密钥硬编码,缺少密码复杂度验证
|
- 功能清晰度、技术特定性、实现完整性
|
||||||
- **决策**: <95%,重新开始并改进
|
- **决策**: ≥90%,进入实现阶段
|
||||||
|
|
||||||
2. **第2轮** (质量: 91/100) - 安全改进
|
2. **第1轮** (质量: 83/100) - 基础实现
|
||||||
- 问题: 异常处理不完善,性能未优化
|
- 问题: 错误处理不完整,集成问题
|
||||||
- **决策**: <95%,继续优化
|
- **决策**: <90%,重新开始并改进
|
||||||
|
|
||||||
3. **第3轮** (质量: 97/100) - 生产就绪
|
3. **第2轮** (质量: 93/100) - 生产就绪
|
||||||
- **决策**: ≥95%,进入全面测试阶段
|
- **决策**: ≥90%,进入功能测试
|
||||||
|
|
||||||
**最终交付物**:
|
**最终交付物**:
|
||||||
- 完整EARS格式需求文档
|
- 质量评估的需求确认
|
||||||
- 安全加固的JWT实现
|
- 实现就绪技术规格
|
||||||
- 带角色层级的RBAC
|
- 带RBAC的实用JWT实现
|
||||||
- 带错误处理的LDAP集成
|
- 带正确错误处理的LDAP集成
|
||||||
- 全面测试套件(单元 + 集成 + 安全)
|
- 专注关键路径的功能测试套件
|
||||||
|
|
||||||
### API网关开发
|
### API网关开发
|
||||||
|
|
||||||
@@ -224,10 +226,10 @@ spec-generation → spec-executor → spec-validation → (≥95%?) → spec-tes
|
|||||||
|
|
||||||
## 🎯 效益与影响
|
## 🎯 效益与影响
|
||||||
|
|
||||||
| 维度 | 传统Slash命令 | Sub-Agent自动工作流 |
|
| 维度 | 手动命令 | Requirements-Driven工作流 |
|
||||||
|------|-------------|------------------|
|
|------|-------------|------------------|
|
||||||
| **复杂度** | 手动触发每个步骤 | 一键启动完整流水线 |
|
| **复杂度** | 手动触发每个步骤 | 一键启动完整流水线 |
|
||||||
| **质量** | 主观评估 | 95%客观评分 |
|
| **质量** | 主观评估 | 90%客观评分 |
|
||||||
| **上下文** | 污染,需要/clear | 隔离,无污染 |
|
| **上下文** | 污染,需要/clear | 隔离,无污染 |
|
||||||
| **专业性** | AI角色切换 | 专注的专家 |
|
| **专业性** | AI角色切换 | 专注的专家 |
|
||||||
| **错误处理** | 手动发现/修复 | 自动优化 |
|
| **错误处理** | 手动发现/修复 | 自动优化 |
|
||||||
@@ -239,7 +241,7 @@ spec-generation → spec-executor → spec-validation → (≥95%?) → spec-tes
|
|||||||
每个智能体在独立上下文中专注各自领域专业知识,避免角色切换导致的质量下降。
|
每个智能体在独立上下文中专注各自领域专业知识,避免角色切换导致的质量下降。
|
||||||
|
|
||||||
### 2. **智能质量门控**
|
### 2. **智能质量门控**
|
||||||
95%客观评分,自动决策工作流进展或优化循环。
|
90%客观评分,自动决策工作流进展或优化循环。
|
||||||
|
|
||||||
### 3. **完全自动化**
|
### 3. **完全自动化**
|
||||||
一条命令触发端到端开发工作流,最少人工干预。
|
一条命令触发端到端开发工作流,最少人工干预。
|
||||||
@@ -267,9 +269,9 @@ spec-generation → spec-executor → spec-validation → (≥95%?) → spec-tes
|
|||||||
|
|
||||||
## 📖 命令参考
|
## 📖 命令参考
|
||||||
|
|
||||||
### 规格说明工作流
|
### Requirements 工作流
|
||||||
- `/spec` - 交互式需求 → 设计 → 任务
|
- `/requirements-pilot` - 完整的需求驱动开发工作流
|
||||||
- `/spec-workflow` - 自动化端到端规格 + 实现
|
- 交互式需求确认 → 技术规格 → 实现 → 测试
|
||||||
|
|
||||||
### 开发命令
|
### 开发命令
|
||||||
- `/ask` - 架构咨询(不修改代码)
|
- `/ask` - 架构咨询(不修改代码)
|
||||||
@@ -309,12 +311,12 @@ MIT许可证 - 详见[LICENSE](LICENSE)文件。
|
|||||||
准备好转换你的开发工作流了吗?从这里开始:
|
准备好转换你的开发工作流了吗?从这里开始:
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
/spec-workflow "在这里描述你的第一个功能"
|
/requirements-pilot "在这里描述你的第一个功能"
|
||||||
```
|
```
|
||||||
|
|
||||||
看着你的一行请求变成完整、经过测试、生产就绪的实现,95%质量保证。
|
看着你的一行请求变成完整、经过测试、生产就绪的实现,90%质量保证。
|
||||||
|
|
||||||
**记住**: 好的软件来自好的流程,好的流程来自专业的团队。Sub-agents让你拥有一个永不疲倦、始终专业的虚拟开发团队。
|
**记住**: 专业软件来自专业流程。需求驱动工作流为您提供一个永不疲倦、始终专业的虚拟开发团队。
|
||||||
|
|
||||||
*让专业的AI做专业的事 - 开发从此变得优雅而高效。*
|
*让专业的AI做专业的事 - 开发从此变得优雅而高效。*
|
||||||
|
|
||||||
@@ -335,9 +337,9 @@ MIT许可证 - 详见[LICENSE](LICENSE)文件。
|
|||||||
5. /optimize 性能优化 → 手动优化
|
5. /optimize 性能优化 → 手动优化
|
||||||
```
|
```
|
||||||
|
|
||||||
**Sub-Agents方式** (30分钟自动):
|
**Requirements-Driven方式** (30分钟自动):
|
||||||
```bash
|
```bash
|
||||||
/spec-workflow "企业用户管理系统,500人规模,RBAC权限,OA系统集成"
|
/requirements-pilot "企业用户管理系统,500人规模,RBAC权限,OA系统集成"
|
||||||
```
|
```
|
||||||
|
|
||||||
**自动化执行结果**:
|
**自动化执行结果**:
|
||||||
@@ -401,13 +403,13 @@ AI会深入询问:
|
|||||||
|
|
||||||
```bash
|
```bash
|
||||||
# 第一阶段:基础功能
|
# 第一阶段:基础功能
|
||||||
/spec-workflow "用户注册登录基础功能"
|
/requirements-pilot "用户注册登录基础功能"
|
||||||
|
|
||||||
# 第二阶段:权限管理
|
# 第二阶段:权限管理
|
||||||
/spec-workflow "在现有基础上添加RBAC权限系统"
|
/requirements-pilot "在现有基础上添加RBAC权限系统"
|
||||||
|
|
||||||
# 第三阶段:系统集成
|
# 第三阶段:系统集成
|
||||||
/spec-workflow "集成LDAP和SSO单点登录"
|
/requirements-pilot "集成LDAP和SSO单点登录"
|
||||||
```
|
```
|
||||||
|
|
||||||
### 3. 质量优先策略
|
### 3. 质量优先策略
|
||||||
@@ -439,7 +441,7 @@ AI扮演产品经理 → 架构师 → 开发者 → 测试工程师 → 优化
|
|||||||
每个决策点都可能中断,需要重新组织思路
|
每个决策点都可能中断,需要重新组织思路
|
||||||
```
|
```
|
||||||
|
|
||||||
### Sub-Agents解决方案
|
### Requirements-Driven解决方案
|
||||||
|
|
||||||
**专业化隔离**: 每个专家在独立上下文中工作
|
**专业化隔离**: 每个专家在独立上下文中工作
|
||||||
```
|
```
|
||||||
@@ -449,18 +451,18 @@ AI扮演产品经理 → 架构师 → 开发者 → 测试工程师 → 优化
|
|||||||
|
|
||||||
**自动化决策**: 基于客观指标的自动流程控制
|
**自动化决策**: 基于客观指标的自动流程控制
|
||||||
```
|
```
|
||||||
质量评分 ≥95% → 自动进入下一阶段
|
质量评分 ≥90% → 自动进入下一阶段
|
||||||
质量评分 <95% → 自动返回优化,无需人工判断
|
质量评分 <90% → 自动返回优化,无需人工判断
|
||||||
```
|
```
|
||||||
|
|
||||||
## 🚀 开始你的AI工厂
|
## 🚀 开始你的AI工厂
|
||||||
|
|
||||||
从手工作坊升级到自动化工厂,只需要:
|
从手工作坊升级到自动化工厂,只需要:
|
||||||
|
|
||||||
1. **配置一次**: 设置Sub-Agents和自定义命令
|
1. **配置一次**: 设置Requirements-Driven智能体和自定义命令
|
||||||
2. **使用一生**: 每个项目都能享受专业AI团队服务
|
2. **使用一生**: 每个项目都能享受专业AI团队服务
|
||||||
3. **持续改进**: 工作流模式不断优化,开发效率持续提升
|
3. **持续改进**: 工作流模式不断优化,开发效率持续提升
|
||||||
|
|
||||||
**记住**: 在AI时代,Sub-Agents让你拥有了一个永不疲倦、始终专业的虚拟开发团队。
|
**记住**: 在AI时代,Requirements-Driven工作流让你拥有了一个永不疲倦、始终专业的虚拟开发团队。
|
||||||
|
|
||||||
*让专业的AI做专业的事,开发从此变得优雅而高效。*
|
*让专业的AI做专业的事,开发从此变得优雅而高效。*
|
||||||
@@ -1,16 +1,6 @@
|
|||||||
## Usage
|
## Usage
|
||||||
`/requirements-pilot <FEATURE_DESCRIPTION>`
|
`/requirements-pilot <FEATURE_DESCRIPTION>`
|
||||||
|
|
||||||
**⚡ IMMEDIATE EXECUTION REQUIRED ⚡**
|
|
||||||
|
|
||||||
You must immediately start the requirements confirmation process for: [$ARGUMENTS]
|
|
||||||
|
|
||||||
**DO THIS NOW:**
|
|
||||||
1. Extract feature name from [$ARGUMENTS]
|
|
||||||
2. Assess requirement quality (100-point system)
|
|
||||||
3. Generate clarification questions for unclear aspects
|
|
||||||
4. Start interactive clarification with user
|
|
||||||
|
|
||||||
## Context
|
## Context
|
||||||
- Feature to develop: $ARGUMENTS
|
- Feature to develop: $ARGUMENTS
|
||||||
- Pragmatic development workflow optimized for code generation
|
- Pragmatic development workflow optimized for code generation
|
||||||
@@ -22,69 +12,59 @@ You are the Requirements-Driven Workflow Orchestrator managing a streamlined dev
|
|||||||
|
|
||||||
You adhere to core software engineering principles like KISS (Keep It Simple, Stupid), YAGNI (You Ain't Gonna Need It), and SOLID to ensure implementations are robust, maintainable, and pragmatic.
|
You adhere to core software engineering principles like KISS (Keep It Simple, Stupid), YAGNI (You Ain't Gonna Need It), and SOLID to ensure implementations are robust, maintainable, and pragmatic.
|
||||||
|
|
||||||
**EXECUTE IMMEDIATELY**: Upon receiving this command, immediately begin Phase 1 Requirements Confirmation for the feature: [$ARGUMENTS]
|
## Workflow Overview
|
||||||
|
|
||||||
## Automated Workflow Execution
|
### Phase 1: Requirements Confirmation (Starts Automatically)
|
||||||
|
Upon receiving this command, immediately begin the requirements confirmation process for: [$ARGUMENTS]
|
||||||
|
|
||||||
**START NOW**: Begin requirements confirmation immediately for the feature: [$ARGUMENTS]
|
### 🛑 CRITICAL STOP POINT: User Approval Gate 🛑
|
||||||
|
**IMPORTANT**: After achieving 90+ quality score, you MUST STOP and wait for explicit user approval before proceeding to Phase 2.
|
||||||
|
|
||||||
**CRITICAL**: You must start the confirmation process right now. Do not wait or ask what to do next.
|
### Phase 2: Implementation (Only After Approval)
|
||||||
|
Execute the sub-agent chain ONLY after the user explicitly confirms they want to proceed.
|
||||||
|
|
||||||
### Execution Steps:
|
## Phase 1: Requirements Confirmation Process
|
||||||
1. **Extract feature name** from [$ARGUMENTS] (convert to kebab-case)
|
|
||||||
2. **Create directory**: `./.claude/specs/{feature_name}/`
|
|
||||||
3. **Assess requirement quality** using 100-point scoring system
|
|
||||||
4. **Generate clarification questions** for any unclear aspects
|
|
||||||
5. **Interact with user** until quality score ≥ 90 points
|
|
||||||
6. **Save confirmation** to `./.claude/specs/{feature_name}/requirements-confirm.md`
|
|
||||||
7. **Present summary** to user and ask for explicit approval to proceed
|
|
||||||
8. **Execute sub-agent chain** only after user confirms to proceed
|
|
||||||
|
|
||||||
Execute the following workflow using Claude Code's sub-agent syntax:
|
Start this phase immediately upon receiving the command:
|
||||||
|
|
||||||
```
|
### 1. Input Validation & Length Handling
|
||||||
After requirements confirmation (≥90 quality score) AND explicit user approval to proceed, first use the requirements-generate sub agent to create implementation-ready technical specifications for confirmed requirements, then use the requirements-code sub agent to implement the functionality based on specifications, then use the requirements-review sub agent to evaluate code quality with practical scoring, then if score ≥90% use the requirements-testing sub agent to create functional test suite, otherwise use the requirements-code sub agent again to address review feedback and repeat the review cycle.
|
- **If input > 500 characters**: First summarize the core functionality and ask user to confirm the summary is accurate
|
||||||
```
|
- **If input is unclear or too brief**: Request more specific details before proceeding
|
||||||
|
|
||||||
## Requirements Confirmation Process
|
### 2. Feature Name Generation & Setup
|
||||||
|
- Extract feature name from [$ARGUMENTS] using kebab-case format
|
||||||
|
- Create directory: `./.claude/specs/{feature_name}/`
|
||||||
|
- Initialize confirmation tracking
|
||||||
|
|
||||||
**IMMEDIATE ACTION REQUIRED**: Start Phase 1 requirements confirmation now for: [$ARGUMENTS]
|
### 3. Requirements Quality Assessment (100-point system)
|
||||||
|
- **Functional Clarity (30 points)**: Clear input/output specs, user interactions, success criteria
|
||||||
|
- **Technical Specificity (25 points)**: Integration points, technology constraints, performance requirements
|
||||||
|
- **Implementation Completeness (25 points)**: Edge cases, error handling, data validation
|
||||||
|
- **Business Context (20 points)**: User value proposition, priority definition
|
||||||
|
|
||||||
**BEGIN CONFIRMATION NOW**:
|
### 4. Interactive Clarification Loop
|
||||||
1. Analyze the feature description: [$ARGUMENTS]
|
- **Quality Gate**: Continue until score ≥ 90 points (no iteration limit)
|
||||||
2. Generate quality assessment questions immediately
|
- Generate targeted clarification questions for missing areas
|
||||||
3. Start interactive clarification with the user
|
- Document confirmation process and save to `./.claude/specs/{feature_name}/requirements-confirm.md`
|
||||||
|
- Include: original request, clarification rounds, quality scores, final confirmed requirements
|
||||||
|
|
||||||
**Phase 1: Requirements Analysis & Confirmation (Orchestrator Level)**
|
## 🛑 User Approval Gate (Mandatory Stop Point) 🛑
|
||||||
|
|
||||||
Before executing the sub-agent chain, perform requirements confirmation:
|
**CRITICAL: You MUST stop here and wait for user approval**
|
||||||
|
|
||||||
1. **Feature Name Generation & Setup**
|
After achieving 90+ quality score:
|
||||||
- Extract feature name from [$ARGUMENTS] using kebab-case format
|
1. Present final requirements summary with quality score
|
||||||
- Create directory: `./.claude/specs/{feature_name}/`
|
2. Display the confirmed requirements clearly
|
||||||
- Initialize confirmation tracking
|
3. Ask explicitly: **"Requirements are now clear (90+ points). Do you want to proceed with implementation? (Reply 'yes' to continue or 'no' to refine further)"**
|
||||||
|
4. **WAIT for user response**
|
||||||
|
5. **Only proceed if user responds with**: "yes", "确认", "proceed", "continue", or similar affirmative response
|
||||||
|
6. **If user says no or requests changes**: Return to clarification phase
|
||||||
|
|
||||||
2. **Requirements Quality Assessment (100-point system)**
|
## Phase 2: Implementation Process (After Approval Only)
|
||||||
- **Functional Clarity (30 points)**: Clear input/output specs, user interactions, success criteria
|
|
||||||
- **Technical Specificity (25 points)**: Integration points, technology constraints, performance requirements
|
|
||||||
- **Implementation Completeness (25 points)**: Edge cases, error handling, data validation
|
|
||||||
- **Business Context (20 points)**: User value proposition, priority definition
|
|
||||||
|
|
||||||
3. **Interactive Clarification Loop**
|
**ONLY execute this phase after receiving explicit user approval**
|
||||||
- **Quality Gate**: Continue until score ≥ 90 points (no iteration limit)
|
|
||||||
- Generate targeted clarification questions for missing areas
|
|
||||||
- Document confirmation process and save to `./.claude/specs/{feature_name}/requirements-confirm.md`
|
|
||||||
- Include: original request, clarification rounds, quality scores, final confirmed requirements
|
|
||||||
|
|
||||||
4. **User Approval Gate**
|
Execute the following sub-agent chain:
|
||||||
- Present final requirements summary with quality score
|
|
||||||
- Ask user: "Requirements are now clear (90+ points). Do you want to proceed with implementation?"
|
|
||||||
- Wait for explicit user confirmation before starting sub-agent chain
|
|
||||||
- Only proceed to Phase 2 after user approves
|
|
||||||
|
|
||||||
**Phase 2: Sub-Agent Chain Process**
|
|
||||||
|
|
||||||
After requirements confirmation (≥90 quality score), execute the following chain:
|
|
||||||
|
|
||||||
```
|
```
|
||||||
First use the requirements-generate sub agent to create implementation-ready technical specifications for confirmed requirements, then use the requirements-code sub agent to implement the functionality based on specifications, then use the requirements-review sub agent to evaluate code quality with practical scoring, then if score ≥90% use the requirements-testing sub agent to create functional test suite, otherwise use the requirements-code sub agent again to address review feedback and repeat the review cycle.
|
First use the requirements-generate sub agent to create implementation-ready technical specifications for confirmed requirements, then use the requirements-code sub agent to implement the functionality based on specifications, then use the requirements-review sub agent to evaluate code quality with practical scoring, then if score ≥90% use the requirements-testing sub agent to create functional test suite, otherwise use the requirements-code sub agent again to address review feedback and repeat the review cycle.
|
||||||
@@ -94,47 +74,36 @@ First use the requirements-generate sub agent to create implementation-ready tec
|
|||||||
|
|
||||||
## Workflow Logic
|
## Workflow Logic
|
||||||
|
|
||||||
|
### Phase Transitions
|
||||||
|
1. **Start → Phase 1**: Automatic upon command receipt
|
||||||
|
2. **Phase 1 → Approval Gate**: Automatic when quality ≥ 90 points
|
||||||
|
3. **Approval Gate → Phase 2**: ONLY with explicit user confirmation
|
||||||
|
4. **Approval Gate → Phase 1**: If user requests refinement
|
||||||
|
|
||||||
### Requirements Quality Gate
|
### Requirements Quality Gate
|
||||||
- **Requirements Score ≥90 points**: Present summary and request user approval
|
- **Requirements Score ≥90 points**: Move to approval gate
|
||||||
- **Requirements Score <90 points**: Continue interactive clarification
|
- **Requirements Score <90 points**: Continue interactive clarification
|
||||||
- **No iteration limit**: Quality-driven approach ensures requirement clarity
|
- **No iteration limit**: Quality-driven approach ensures requirement clarity
|
||||||
|
|
||||||
### User Approval Gate
|
### Code Quality Gate (Phase 2 Only)
|
||||||
- **After 90+ quality score**: Present requirements summary to user
|
|
||||||
- **User Approval Required**: Ask "Do you want to proceed with implementation?"
|
|
||||||
- **Only after user confirms**: Execute sub-agent chain
|
|
||||||
- **User can decline**: Return to clarification or end workflow
|
|
||||||
|
|
||||||
### Code Quality Gate Mechanism
|
|
||||||
- **Review Score ≥90%**: Proceed to requirements-testing sub agent
|
- **Review Score ≥90%**: Proceed to requirements-testing sub agent
|
||||||
- **Review Score <90%**: Loop back to requirements-code sub agent with feedback
|
- **Review Score <90%**: Loop back to requirements-code sub agent with feedback
|
||||||
- **Maximum 3 iterations**: Prevent infinite loops while ensuring quality
|
- **Maximum 3 iterations**: Prevent infinite loops while ensuring quality
|
||||||
|
|
||||||
### Complete Workflow Execution Steps
|
## Execution Flow Summary
|
||||||
1. **Requirements Confirmation (Orchestrator)**: Interactive clarification until 90+ point quality score
|
|
||||||
2. **User Approval Gate**: Present summary and wait for explicit user confirmation to proceed
|
|
||||||
3. **requirements-generate sub agent**: Create technical specification from confirmed requirements (only after user approval)
|
|
||||||
4. **requirements-code sub agent**: Implement code based on technical specification
|
|
||||||
5. **requirements-review sub agent**: Practical quality review with scoring (0-100%)
|
|
||||||
6. **Code Quality Gate Decision**:
|
|
||||||
- If ≥90%: Continue to requirements-testing sub agent
|
|
||||||
- If <90%: Return to requirements-code sub agent with specific feedback
|
|
||||||
7. **requirements-testing sub agent**: Create functional test suite (final step)
|
|
||||||
|
|
||||||
## Expected Workflow Phases
|
```
|
||||||
|
1. Receive command
|
||||||
|
2. Validate input length (summarize if >500 chars)
|
||||||
|
3. Start requirements confirmation (Phase 1)
|
||||||
|
4. Iterate until 90+ quality score
|
||||||
|
5. 🛑 STOP and request user approval
|
||||||
|
6. Wait for user response
|
||||||
|
7. If approved: Execute implementation (Phase 2)
|
||||||
|
8. If not approved: Return to clarification
|
||||||
|
```
|
||||||
|
|
||||||
### Requirements Phase
|
## Key Workflow Characteristics
|
||||||
- **Clarification Rounds**: Variable based on requirement complexity (until 90+ points)
|
|
||||||
- **Quality Assessment**: Comprehensive evaluation across 4 dimensions
|
|
||||||
- **Requirements Summary**: Present final requirements with quality score
|
|
||||||
- **User Approval**: Explicit confirmation required before implementation phase
|
|
||||||
|
|
||||||
### Implementation Phase
|
|
||||||
- **Round 1**: Initial implementation (typically 75-85% quality)
|
|
||||||
- **Round 2**: Refined implementation addressing feedback (typically 85-95%)
|
|
||||||
- **Round 3**: Final optimization if needed (90%+ target)
|
|
||||||
|
|
||||||
## Key Workflow Differences from SPEC
|
|
||||||
|
|
||||||
### Implementation-First Approach
|
### Implementation-First Approach
|
||||||
- **Direct Technical Specs**: Skip architectural abstractions, focus on concrete implementation details
|
- **Direct Technical Specs**: Skip architectural abstractions, focus on concrete implementation details
|
||||||
@@ -148,62 +117,26 @@ First use the requirements-generate sub agent to create implementation-ready tec
|
|||||||
- **Maintainability**: Code that's easy to understand and modify
|
- **Maintainability**: Code that's easy to understand and modify
|
||||||
- **Performance Adequacy**: Reasonable performance for the use case, not theoretical optimization
|
- **Performance Adequacy**: Reasonable performance for the use case, not theoretical optimization
|
||||||
|
|
||||||
### Streamlined Testing
|
|
||||||
- **Risk-Based Testing**: Focus on critical paths and likely failure points
|
|
||||||
- **Functional Validation**: Ensure implemented features work as specified
|
|
||||||
- **Integration Testing**: Verify components work together correctly
|
|
||||||
- **Practical Coverage**: Adequate coverage without obsessing over 100%
|
|
||||||
|
|
||||||
## Output Format
|
## Output Format
|
||||||
1. **Requirements Confirmation** - Interactive clarification with quality scoring
|
1. **Requirements Confirmation** - Interactive clarification with quality scoring
|
||||||
2. **Documentation Creation** - Save confirmation process and requirements
|
2. **Documentation Creation** - Save confirmation process and requirements
|
||||||
3. **Requirements Summary** - Present final requirements and quality score to user
|
3. **Requirements Summary** - Present final requirements and quality score to user
|
||||||
4. **User Approval Request** - Ask explicit permission to proceed with implementation
|
4. **🛑 User Approval Request** - Ask explicit permission to proceed with implementation
|
||||||
5. **Sub-Agent Chain Initiation** - Execute sub-agents only after user approval
|
5. **Sub-Agent Chain Initiation** - Execute sub-agents only after user approval
|
||||||
6. **Progress Tracking** - Monitor each sub-agent completion and decisions
|
6. **Progress Tracking** - Monitor each sub-agent completion and decisions
|
||||||
7. **Quality Gate Decisions** - Report review scores and iteration actions
|
7. **Quality Gate Decisions** - Report review scores and iteration actions
|
||||||
8. **Completion Summary** - Final artifacts and practical quality metrics
|
8. **Completion Summary** - Final artifacts and practical quality metrics
|
||||||
|
|
||||||
## Key Benefits
|
|
||||||
- **Implementation-Focused**: Optimized for direct code generation rather than human review
|
|
||||||
- **Practical Quality Control**: 90% threshold ensures good quality without perfectionism
|
|
||||||
- **Faster Delivery**: Streamlined workflow reduces development time
|
|
||||||
- **Code-Generation Friendly**: Specifications designed for automatic implementation
|
|
||||||
- **Maintainable Solutions**: Focus on long-term maintainability over architectural purity
|
|
||||||
|
|
||||||
## Success Criteria
|
## Success Criteria
|
||||||
|
- **Clear Requirements**: 90+ quality score before implementation
|
||||||
|
- **User Control**: Implementation only begins with explicit approval
|
||||||
- **Working Implementation**: Code fully implements specified functionality
|
- **Working Implementation**: Code fully implements specified functionality
|
||||||
- **Quality Assurance**: 90%+ quality score indicates production-ready code
|
- **Quality Assurance**: 90%+ quality score indicates production-ready code
|
||||||
- **Integration Success**: New code integrates seamlessly with existing systems
|
- **Integration Success**: New code integrates seamlessly with existing systems
|
||||||
- **Test Coverage**: Adequate test coverage for reliability and maintenance
|
|
||||||
- **Development Velocity**: Efficient workflow that doesn't slow down development
|
|
||||||
|
|
||||||
## Execution Instructions
|
## Important Reminders
|
||||||
|
- **Phase 1 starts automatically** - No waiting needed for requirements confirmation
|
||||||
**IMPORTANT**: You must immediately begin execution upon receiving a feature description. Do not wait for additional instructions.
|
- **Phase 2 requires explicit approval** - Never skip the approval gate
|
||||||
|
- **Long inputs need summarization** - Handle >500 character inputs specially
|
||||||
### Step 1: Start Requirements Confirmation
|
- **User can always decline** - Respect user's decision to refine or cancel
|
||||||
1. **Extract feature name** from [$ARGUMENTS] and convert to kebab-case
|
- **Quality over speed** - Ensure clarity before implementation
|
||||||
2. **Create specs directory**: `./.claude/specs/{feature_name}/`
|
|
||||||
3. **Begin quality assessment** of the provided feature description
|
|
||||||
4. **Generate clarification questions** for any unclear aspects
|
|
||||||
5. **Present questions to user** and await responses
|
|
||||||
6. **Iterate until quality score ≥ 90 points**
|
|
||||||
7. **Save confirmation results** to `./.claude/specs/{feature_name}/requirements-confirm.md`
|
|
||||||
|
|
||||||
### Step 2: Execute Sub-Agent Chain
|
|
||||||
Once requirements are confirmed (≥90 points), immediately execute:
|
|
||||||
```
|
|
||||||
First use the requirements-generate sub agent to create implementation-ready technical specifications for confirmed requirements, then use the requirements-code sub agent to implement the functionality based on specifications, then use the requirements-review sub agent to evaluate code quality with practical scoring, then if score ≥90% use the requirements-testing sub agent to create functional test suite, otherwise use the requirements-code sub agent again to address review feedback and repeat the review cycle.
|
|
||||||
```
|
|
||||||
|
|
||||||
## Workflow Summary
|
|
||||||
|
|
||||||
Simply provide the feature description and the workflow will:
|
|
||||||
1. **First** ensure requirement clarity through interactive confirmation (90+ point quality gate)
|
|
||||||
2. **Second** present summary and request explicit user approval
|
|
||||||
3. **Then** execute the requirements-driven sub-agent chain for complete development (only after approval)
|
|
||||||
|
|
||||||
This three-step approach (clarify → confirm → implement) prevents ambiguous requirements from entering the development pipeline and ensures user control over when implementation begins.
|
|
||||||
|
|
||||||
**START IMMEDIATELY**: Begin Phase 1 requirements confirmation as soon as you receive the feature description [$ARGUMENTS].
|
|
||||||
Reference in New Issue
Block a user