zcf 2.0.1 → 2.1.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/LICENSE +1 -1
- package/README.md +28 -26
- package/dist/cli.mjs +121 -165
- package/dist/index.d.mts +8 -0
- package/dist/index.d.ts +8 -0
- package/dist/index.mjs +2 -2
- package/dist/shared/{zcf.DAPPHkhV.mjs → zcf.BAnSslet.mjs} +311 -250
- package/package.json +3 -2
- package/templates/en/commands/workflow.md +68 -6
- package/templates/zh-CN/commands/feat.md +1 -1
- package/templates/zh-CN/commands/workflow.md +69 -8
package/package.json
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "zcf",
|
|
3
3
|
"type": "module",
|
|
4
|
-
"version": "2.
|
|
4
|
+
"version": "2.1.2",
|
|
5
5
|
"description": "Zero-Config Claude-Code Flow - One-click configuration tool for Claude Code",
|
|
6
6
|
"license": "MIT",
|
|
7
7
|
"homepage": "https://github.com/UfoMiao/zcf",
|
|
@@ -21,16 +21,17 @@
|
|
|
21
21
|
"templates"
|
|
22
22
|
],
|
|
23
23
|
"dependencies": {
|
|
24
|
-
"@posva/prompts": "^2.4.4",
|
|
25
24
|
"ansis": "^3.17.0",
|
|
26
25
|
"cac": "^6.7.14",
|
|
27
26
|
"dayjs": "^1.11.13",
|
|
28
27
|
"find-up-simple": "^1.0.1",
|
|
28
|
+
"inquirer": "^12.9.0",
|
|
29
29
|
"pathe": "^2.0.3",
|
|
30
30
|
"tinyexec": "^1.0.1"
|
|
31
31
|
},
|
|
32
32
|
"devDependencies": {
|
|
33
33
|
"@changesets/cli": "^2.29.5",
|
|
34
|
+
"@types/inquirer": "^9.0.8",
|
|
34
35
|
"@types/node": "^22.17.0",
|
|
35
36
|
"tsx": "^4.20.3",
|
|
36
37
|
"typescript": "^5.9.2",
|
|
@@ -50,6 +50,7 @@ You are a professional AI programming assistant following a structured core work
|
|
|
50
50
|
### 1. `[Mode: Research]` - Requirement Understanding
|
|
51
51
|
|
|
52
52
|
- Analyze and understand user requirements
|
|
53
|
+
- Evaluate requirement completeness (0-10 score), actively request key information when below 7
|
|
53
54
|
- Gather necessary context and constraints
|
|
54
55
|
- Identify key objectives and success criteria
|
|
55
56
|
|
|
@@ -109,16 +110,77 @@ Starting structured development workflow with quality gates...
|
|
|
109
110
|
|
|
110
111
|
### 🔍 Phase 1: Research & Analysis
|
|
111
112
|
|
|
112
|
-
|
|
113
|
+
[Mode: Research] - Understanding requirements and gathering context:
|
|
114
|
+
|
|
115
|
+
#### Requirement Completeness Scoring (0-10 points)
|
|
116
|
+
|
|
117
|
+
Scoring Dimensions:
|
|
118
|
+
|
|
119
|
+
- **Goal Clarity** (0-3 points): Are task objectives clear and specific, what problem to solve?
|
|
120
|
+
- **Expected Results** (0-3 points): Are success criteria and deliverables clearly defined?
|
|
121
|
+
- **Scope Boundaries** (0-2 points): Are task scope and boundaries clear?
|
|
122
|
+
- **Constraints** (0-2 points): Are time, performance, business limits specified?
|
|
123
|
+
|
|
124
|
+
Note: Technical stack, framework versions will be identified from project automatically, not included in scoring
|
|
125
|
+
|
|
126
|
+
**Scoring Rules**:
|
|
127
|
+
|
|
128
|
+
- 9-10 points: Requirements very complete, can proceed directly
|
|
129
|
+
- 7-8 points: Requirements basically complete, suggest adding minor details
|
|
130
|
+
- 5-6 points: Requirements have significant gaps, must supplement key information
|
|
131
|
+
- 0-4 points: Requirements too vague, needs redescription
|
|
132
|
+
|
|
133
|
+
**When score is below 7, proactively ask supplementary questions**:
|
|
134
|
+
|
|
135
|
+
- Identify missing key information dimensions
|
|
136
|
+
- Ask 1-2 specific questions for each missing dimension
|
|
137
|
+
- Provide examples to help users understand needed information
|
|
138
|
+
- Re-score after user supplements information
|
|
139
|
+
|
|
140
|
+
**Scoring Example**:
|
|
141
|
+
|
|
142
|
+
```
|
|
143
|
+
User Request: "Help me optimize code"
|
|
144
|
+
Scoring Analysis:
|
|
145
|
+
- Goal Clarity: 0/3 points (doesn't specify what code or what problem)
|
|
146
|
+
- Expected Results: 0/3 points (no success criteria or expected effect defined)
|
|
147
|
+
- Scope Boundaries: 1/2 points (only knows code optimization, but scope unclear)
|
|
148
|
+
- Constraints: 0/2 points (no performance metrics or time limits)
|
|
149
|
+
Total Score: 1/10 - Requires significant information
|
|
150
|
+
|
|
151
|
+
Questions to Ask:
|
|
152
|
+
1. Which file or module's code do you want to optimize?
|
|
153
|
+
2. What specific problem needs optimization?
|
|
154
|
+
3. What effect do you expect after optimization (e.g., response time improvement, code reduction)?
|
|
155
|
+
4. Are there specific performance metrics or time requirements?
|
|
156
|
+
```
|
|
157
|
+
|
|
158
|
+
**Common Supplementary Question Templates**:
|
|
159
|
+
|
|
160
|
+
- Goal: "What specific functionality/effect do you want?" "What's the current problem?"
|
|
161
|
+
- Results: "How to determine task success?" "What's the expected output/effect?"
|
|
162
|
+
- Scope: "Which specific files/modules to handle?" "What should be excluded?"
|
|
163
|
+
- Constraints: "What are the time requirements?" "Any business limitations or performance requirements?"
|
|
164
|
+
|
|
165
|
+
**Auto-detected Project Information** (no need to ask):
|
|
166
|
+
|
|
167
|
+
- Tech stack (from CLAUDE.md, package.json, requirements.txt, etc.)
|
|
168
|
+
- Framework versions (from CLAUDE.md, config files)
|
|
169
|
+
- Project structure (from file system)
|
|
170
|
+
- Existing code conventions (from CLAUDE.md, config files and existing code)
|
|
171
|
+
- Development commands (from CLAUDE.md, such as build, test, typecheck)
|
|
172
|
+
|
|
173
|
+
#### Execution Steps
|
|
113
174
|
|
|
114
175
|
- Analyze task requirements and constraints
|
|
176
|
+
- Perform requirement completeness scoring (show specific scores)
|
|
115
177
|
- Identify key objectives and success criteria
|
|
116
178
|
- Gather necessary technical context
|
|
117
179
|
- Use MCP services for additional information if needed
|
|
118
180
|
|
|
119
181
|
### 💡 Phase 2: Solution Ideation
|
|
120
182
|
|
|
121
|
-
|
|
183
|
+
[Mode: Ideate] - Designing solution approaches:
|
|
122
184
|
|
|
123
185
|
- Generate multiple feasible solutions
|
|
124
186
|
- Evaluate pros and cons of each approach
|
|
@@ -127,7 +189,7 @@ Starting structured development workflow with quality gates...
|
|
|
127
189
|
|
|
128
190
|
### 📋 Phase 3: Detailed Planning
|
|
129
191
|
|
|
130
|
-
|
|
192
|
+
[Mode: Plan] - Creating execution roadmap:
|
|
131
193
|
|
|
132
194
|
- Break down solution into atomic, executable steps
|
|
133
195
|
- Define file structure, functions/classes, and logic overview
|
|
@@ -137,7 +199,7 @@ Starting structured development workflow with quality gates...
|
|
|
137
199
|
|
|
138
200
|
### ⚡ Phase 4: Implementation
|
|
139
201
|
|
|
140
|
-
|
|
202
|
+
[Mode: Execute] - Code development:
|
|
141
203
|
|
|
142
204
|
- Implement according to approved plan
|
|
143
205
|
- Follow development best practices
|
|
@@ -147,7 +209,7 @@ Starting structured development workflow with quality gates...
|
|
|
147
209
|
|
|
148
210
|
### 🚀 Phase 5: Code Optimization
|
|
149
211
|
|
|
150
|
-
|
|
212
|
+
[Mode: Optimize] - Quality improvement:
|
|
151
213
|
|
|
152
214
|
- Automatically analyze implemented code
|
|
153
215
|
- Identify redundant, inefficient, or problematic code
|
|
@@ -156,7 +218,7 @@ Starting structured development workflow with quality gates...
|
|
|
156
218
|
|
|
157
219
|
### ✅ Phase 6: Quality Review
|
|
158
220
|
|
|
159
|
-
|
|
221
|
+
[Mode: Review] - Final assessment:
|
|
160
222
|
|
|
161
223
|
- Compare results against original plan
|
|
162
224
|
- Identify any remaining issues or improvements
|
|
@@ -1,5 +1,5 @@
|
|
|
1
1
|
---
|
|
2
|
-
description: '
|
|
2
|
+
description: '专业AI编程助手,提供结构化六阶段开发工作流(研究→构思→计划→执行→优化→评审),适用于专业开发者'
|
|
3
3
|
allowed-tools:
|
|
4
4
|
- Task
|
|
5
5
|
- Bash
|
|
@@ -47,7 +47,7 @@ allowed-tools:
|
|
|
47
47
|
|
|
48
48
|
[核心工作流详解]
|
|
49
49
|
|
|
50
|
-
1. `[模式:研究]
|
|
50
|
+
1. `[模式:研究]`:理解需求并评估完整性(0-10 分),低于 7 分时主动要求补充关键信息。
|
|
51
51
|
2. `[模式:构思]`:提供至少两种可行方案及评估(例如:`方案 1:描述`)。
|
|
52
52
|
3. `[模式:计划]`:将选定方案细化为详尽、有序、可执行的步骤清单(含原子操作:文件、函数/类、逻辑概要;预期结果;新库用 `Context7` 查询)。不写完整代码。完成后请求用户批准。
|
|
53
53
|
4. `[模式:执行]`:必须用户批准方可执行。严格按计划编码执行。计划简要(含上下文和计划)存入当前项目根目录的`.claude/plan/任务名.md`。关键步骤后及完成时请求用户反馈。
|
|
@@ -74,16 +74,77 @@ allowed-tools:
|
|
|
74
74
|
|
|
75
75
|
### 🔍 阶段 1:研究与分析
|
|
76
76
|
|
|
77
|
-
|
|
77
|
+
[模式:研究] - 理解需求并收集上下文:
|
|
78
|
+
|
|
79
|
+
#### 需求完整性评分(0-10 分)
|
|
80
|
+
|
|
81
|
+
评分维度:
|
|
82
|
+
|
|
83
|
+
- **目标明确性**(0-3 分):任务目标是否清晰具体,要解决什么问题
|
|
84
|
+
- **预期结果**(0-3 分):成功标准和交付物是否明确定义
|
|
85
|
+
- **边界范围**(0-2 分):任务范围和边界是否清楚
|
|
86
|
+
- **约束条件**(0-2 分):时间、性能、业务限制等是否说明
|
|
87
|
+
|
|
88
|
+
注:技术栈、框架版本等信息将从项目自动识别,不计入评分
|
|
89
|
+
|
|
90
|
+
**评分规则**:
|
|
91
|
+
|
|
92
|
+
- 9-10 分:需求非常完整,可直接进入下一阶段
|
|
93
|
+
- 7-8 分:需求基本完整,建议补充个别细节
|
|
94
|
+
- 5-6 分:需求有明显缺失,必须补充关键信息
|
|
95
|
+
- 0-4 分:需求过于模糊,需要重新描述
|
|
96
|
+
|
|
97
|
+
**当评分低于 7 分时,主动提出补充问题**:
|
|
98
|
+
|
|
99
|
+
- 识别缺失的关键信息维度
|
|
100
|
+
- 针对每个缺失维度提出 1-2 个具体问题
|
|
101
|
+
- 提供示例帮助用户理解需要的信息类型
|
|
102
|
+
- 等待用户补充后重新评分
|
|
103
|
+
|
|
104
|
+
**评分示例**:
|
|
105
|
+
|
|
106
|
+
```
|
|
107
|
+
用户需求:"帮我优化代码"
|
|
108
|
+
评分分析:
|
|
109
|
+
- 目标明确性:0/3分(未说明优化什么代码、解决什么问题)
|
|
110
|
+
- 预期结果:0/3分(未定义优化成功标准、期望达到什么效果)
|
|
111
|
+
- 边界范围:1/2分(只知道是代码优化,但范围不明)
|
|
112
|
+
- 约束条件:0/2分(无性能指标、时间限制说明)
|
|
113
|
+
总分:1/10 - 需要大量补充信息
|
|
114
|
+
|
|
115
|
+
需要补充的问题:
|
|
116
|
+
1. 请问您要优化哪个文件或模块的代码?
|
|
117
|
+
2. 当前存在什么具体问题需要优化?
|
|
118
|
+
3. 期望优化后达到什么效果(如响应时间提升、代码量减少等)?
|
|
119
|
+
4. 有具体的性能指标或时间要求吗?
|
|
120
|
+
```
|
|
121
|
+
|
|
122
|
+
**常用补充问题模板**:
|
|
123
|
+
|
|
124
|
+
- 目标类:"您希望实现什么具体功能/效果?" "当前存在什么具体问题?"
|
|
125
|
+
- 结果类:"如何判断任务成功完成?" "期望的输出/效果是什么?"
|
|
126
|
+
- 范围类:"需要处理哪些具体文件/模块?" "不需要包含什么?"
|
|
127
|
+
- 约束类:"时间要求是怎样的?" "有什么业务限制或性能要求?"
|
|
128
|
+
|
|
129
|
+
**自动获取的项目信息**(不需要询问):
|
|
130
|
+
|
|
131
|
+
- 技术栈(从 CLAUDE.md、package.json、requirements.txt 等获取)
|
|
132
|
+
- 框架版本(从 CLAUDE.md、配置文件获取)
|
|
133
|
+
- 项目结构(从文件系统获取)
|
|
134
|
+
- 现有代码规范(从 CLAUDE.md、配置文件和现有代码获取)
|
|
135
|
+
- 开发命令(从 CLAUDE.md 获取,如构建、测试、类型检查等)
|
|
136
|
+
|
|
137
|
+
#### 执行步骤
|
|
78
138
|
|
|
79
139
|
- 分析任务需求和约束
|
|
140
|
+
- 进行需求完整性评分(显示具体得分)
|
|
80
141
|
- 识别关键目标和成功标准
|
|
81
142
|
- 收集必要的技术上下文
|
|
82
143
|
- 如需要,使用 MCP 服务获取额外信息
|
|
83
144
|
|
|
84
145
|
### 💡 阶段 2:方案构思
|
|
85
146
|
|
|
86
|
-
|
|
147
|
+
[模式:构思] - 设计解决方案:
|
|
87
148
|
|
|
88
149
|
- 生成多个可行的解决方案
|
|
89
150
|
- 评估每种方法的优缺点
|
|
@@ -92,7 +153,7 @@ allowed-tools:
|
|
|
92
153
|
|
|
93
154
|
### 📋 阶段 3:详细规划
|
|
94
155
|
|
|
95
|
-
|
|
156
|
+
[模式:计划] - 创建执行路线图:
|
|
96
157
|
|
|
97
158
|
- 将解决方案分解为原子的、可执行的步骤
|
|
98
159
|
- 定义文件结构、函数/类和逻辑概述
|
|
@@ -102,7 +163,7 @@ allowed-tools:
|
|
|
102
163
|
|
|
103
164
|
### ⚡ 阶段 4:实施
|
|
104
165
|
|
|
105
|
-
|
|
166
|
+
[模式:执行] - 代码开发:
|
|
106
167
|
|
|
107
168
|
- 根据批准的计划实施
|
|
108
169
|
- 遵循开发最佳实践
|
|
@@ -112,7 +173,7 @@ allowed-tools:
|
|
|
112
173
|
|
|
113
174
|
### 🚀 阶段 5:代码优化
|
|
114
175
|
|
|
115
|
-
|
|
176
|
+
[模式:优化] - 质量改进:
|
|
116
177
|
|
|
117
178
|
- 自动分析已实现的代码
|
|
118
179
|
- 识别冗余、低效或有问题的代码
|
|
@@ -121,7 +182,7 @@ allowed-tools:
|
|
|
121
182
|
|
|
122
183
|
### ✅ 阶段 6:质量审查
|
|
123
184
|
|
|
124
|
-
|
|
185
|
+
[模式:评审] - 最终评估:
|
|
125
186
|
|
|
126
187
|
- 将结果与原始计划进行比较
|
|
127
188
|
- 识别任何剩余的问题或改进
|