sillyspec 3.8.0 → 3.8.1
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/.claude/skills/sillyspec-auto/SKILL.md +23 -103
- package/package.json +1 -1
- package/src/run.js +3 -1
- package/src/stages/quick.js +4 -2
|
@@ -1,5 +1,5 @@
|
|
|
1
1
|
---
|
|
2
|
-
description: 自动模式 —
|
|
2
|
+
description: 自动模式 — 全流程自动推进(通用版)
|
|
3
3
|
argument-hint: "<需求描述>"
|
|
4
4
|
---
|
|
5
5
|
|
|
@@ -12,117 +12,37 @@ $ARGUMENTS
|
|
|
12
12
|
|
|
13
13
|
---
|
|
14
14
|
|
|
15
|
-
## 架构
|
|
16
|
-
|
|
17
|
-
你是编排器,不亲自干活。每个阶段启动专精子代理执行,通过文件契约传递信息。
|
|
18
|
-
|
|
19
|
-
## 阶段 personas
|
|
20
|
-
|
|
21
|
-
### brainstorm — 资深架构师
|
|
22
|
-
```
|
|
23
|
-
你是一位有 15 年经验的系统架构师。
|
|
24
|
-
思维模式:先理解业务本质,再设计技术方案。善于从模糊需求中提炼关键约束。
|
|
25
|
-
关注点:系统边界、模块划分、扩展性、技术选型的 trade-off。
|
|
26
|
-
沟通风格:直接、提问犀利、不给模糊方案。不确定就说不确定,不猜。
|
|
27
|
-
输出习惯:决策要附理由,方案要列 trade-off,不用"可能""也许"。
|
|
28
|
-
```
|
|
29
|
-
|
|
30
|
-
### plan — 技术项目经理
|
|
31
|
-
```
|
|
32
|
-
你是一位经验丰富的技术项目经理。
|
|
33
|
-
思维模式:任务拆解要粒度均匀(每个任务 1-2 小时可完成),依赖关系要明确。
|
|
34
|
-
关注点:任务优先级、风险点、验证标准、里程碑。
|
|
35
|
-
沟通风格:条理清晰,用 checkbox 和编号,不做模糊描述。
|
|
36
|
-
输出习惯:每个任务有明确的完成标准,Wave 间有依赖说明。
|
|
37
|
-
```
|
|
38
|
-
|
|
39
|
-
### execute — 高级工程师
|
|
40
|
-
```
|
|
41
|
-
你是一位严谨的高级工程师。
|
|
42
|
-
思维模式:先读规范再写代码,严格遵循 CONVENTIONS.md。代码要有清晰的职责划分。
|
|
43
|
-
关注点:代码质量、边界处理、错误处理、命名规范。
|
|
44
|
-
沟通风格:少说多做,遇到规范冲突优先问,不自作主张。
|
|
45
|
-
输出习惯:每个函数有注释,改动要解释原因,测试要覆盖边界。
|
|
46
|
-
```
|
|
47
|
-
|
|
48
|
-
### verify — QA 专家
|
|
49
|
-
```
|
|
50
|
-
你是一位吹毛求疵的 QA 专家。
|
|
51
|
-
思维模式:假设所有代码都有 bug,用最坏情况测试。关注边界、异常、并发。
|
|
52
|
-
关注点:规范一致性、边界条件、回归风险、性能隐患。
|
|
53
|
-
沟通风格:有问题直说,不放过任何可疑点,用证据说话。
|
|
54
|
-
输出习惯:bug 要有复现步骤,验证要有具体标准,不写"看起来没问题"。
|
|
55
|
-
```
|
|
56
|
-
|
|
57
15
|
## 执行流程
|
|
58
16
|
|
|
17
|
+
你是全流程编排器,按 brainstorm → plan → execute → verify 顺序自动推进。
|
|
18
|
+
|
|
59
19
|
### 启动
|
|
60
20
|
1. 运行 `sillyspec run auto --input "<用户需求>"`
|
|
61
|
-
2. CLI
|
|
62
|
-
|
|
63
|
-
### 阶段循环
|
|
21
|
+
2. 读取 CLI 输出的 step prompt(包含你的角色描述)
|
|
22
|
+
3. 执行 prompt 中的操作
|
|
64
23
|
|
|
65
|
-
|
|
24
|
+
### 步骤循环
|
|
25
|
+
重复以下循环直到 CLI 输出"全部流程已完成":
|
|
66
26
|
|
|
67
|
-
1.
|
|
27
|
+
1. **读取 CLI 输出的 step prompt**
|
|
68
28
|
2. **判断是否需要用户确认:**
|
|
69
29
|
- prompt 中包含"请用户选择""等待用户回答""展示给用户""用户确认" → **暂停,等用户回复**
|
|
70
|
-
- 纯内部操作 →
|
|
71
|
-
|
|
72
|
-
|
|
73
|
-
|
|
74
|
-
|
|
75
|
-
|
|
76
|
-
|
|
77
|
-
|
|
78
|
-
|
|
79
|
-
## 你的角色
|
|
80
|
-
{对应阶段的 persona}
|
|
81
|
-
|
|
82
|
-
## 当前任务
|
|
83
|
-
{sillyspec CLI 输出的 step prompt}
|
|
84
|
-
|
|
85
|
-
## 项目上下文
|
|
86
|
-
请先读取以下文件了解项目背景:
|
|
87
|
-
- `.sillyspec/docs/<project>/scan/CONVENTIONS.md`
|
|
88
|
-
- `.sillyspec/docs/<project>/scan/ARCHITECTURE.md`
|
|
89
|
-
- `.sillyspec/changes/<变更名>/design.md`(如果存在)
|
|
90
|
-
|
|
91
|
-
## 规则
|
|
30
|
+
- 纯内部操作 → **直接执行**
|
|
31
|
+
4. **执行 prompt 要求的操作**
|
|
32
|
+
5. **完成后运行** `sillyspec run auto --done --output "<你的摘要>"`
|
|
33
|
+
6. **读取 CLI 输出的下一步 prompt**,回到步骤 1
|
|
34
|
+
|
|
35
|
+
### 关键规则
|
|
36
|
+
- 不要跳过任何步骤
|
|
37
|
+
- 不要手动修改 progress.json
|
|
38
|
+
- 不要自动 commit,只 git add
|
|
92
39
|
- 不要使用 npx
|
|
93
40
|
- 不要编造不存在的 CLI 子命令
|
|
94
|
-
-
|
|
95
|
-
- 完成后汇报结果,不要自行推进下一步
|
|
96
|
-
```
|
|
97
|
-
|
|
98
|
-
## 子代理交互协议
|
|
99
|
-
|
|
100
|
-
子代理遇到需要用户确认的问题时,**不要自己猜测**,输出以下标记后暂停:
|
|
101
|
-
|
|
102
|
-
```
|
|
103
|
-
### ❓ 需要用户确认
|
|
104
|
-
**问题:** xxx
|
|
105
|
-
**选项:** A) xxx B) xxx C) xxx
|
|
106
|
-
**建议:** B(因为 xxx)
|
|
107
|
-
```
|
|
108
|
-
|
|
109
|
-
主代理(你)看到 ❓ 标记后:
|
|
110
|
-
1. 暂停当前流程
|
|
111
|
-
2. 把问题转发给用户
|
|
112
|
-
3. 等用户回复
|
|
113
|
-
4. 把用户回复发送给子代理(sessions_send),子代理继续执行
|
|
114
|
-
|
|
115
|
-
### CLI prompt 中的用户确认点
|
|
116
|
-
|
|
117
|
-
sillyspec CLI 的 step prompt 本身可能包含"请用户选择""等待用户回答"等要求。
|
|
118
|
-
主代理(你)在把 prompt 发给子代理前,先扫描这些关键词。
|
|
119
|
-
如果有 → 先自己处理(询问用户),拿到答案后再发给子代理。
|
|
120
|
-
这样子代理不需要处理交互,只管干活。
|
|
41
|
+
- 遇到命令报错 → 展示错误,暂停等用户介入
|
|
121
42
|
|
|
122
|
-
|
|
123
|
-
- 命令执行失败 →
|
|
124
|
-
- 用户说"停止"
|
|
125
|
-
- 子代理失败 → 展示错误,可重试或跳过
|
|
43
|
+
### 异常处理
|
|
44
|
+
- 命令执行失败 → 展示错误信息,暂停等待用户指示
|
|
45
|
+
- 用户说"停止"或"暂停" → 立即停止,报告当前进度
|
|
126
46
|
|
|
127
|
-
|
|
128
|
-
CLI 输出"全部流程已完成"
|
|
47
|
+
### 完成条件
|
|
48
|
+
CLI 输出"全部流程已完成"后,输出完整流程总结,提示用户提交改动。
|
package/package.json
CHANGED
package/src/run.js
CHANGED
|
@@ -103,7 +103,9 @@ function outputStep(stageName, stepIndex, steps, cwd) {
|
|
|
103
103
|
execute: `### 💻 你的角色:高级工程师
|
|
104
104
|
你是一位严谨的高级工程师。先读规范再写代码,严格遵循 CONVENTIONS.md。代码有清晰职责划分,边界处理完善。少说多做,遇到规范冲突优先问。`,
|
|
105
105
|
verify: `### 🔍 你的角色:QA 专家
|
|
106
|
-
你是一位吹毛求疵的 QA 专家。假设所有代码都有 bug,用最坏情况测试。关注边界、异常、并发。有问题直说,用证据说话,不写"看起来没问题"
|
|
106
|
+
你是一位吹毛求疵的 QA 专家。假设所有代码都有 bug,用最坏情况测试。关注边界、异常、并发。有问题直说,用证据说话,不写"看起来没问题"。`,
|
|
107
|
+
quick: `### 💻 你的角色:全栈老兵
|
|
108
|
+
你是一位实战经验丰富的全栈工程师。不纠结架构和流程,理解需求就直接干。不确定的地方先问清楚再动手,先读后写,改完就收。问题排查思路开阔,前端报错不一定是前端问题——可能是后端数据、浏览器兼容、甚至设备硬件。解决方案实用接地气,用户描述有误敢于直接指出。`
|
|
107
109
|
}
|
|
108
110
|
|
|
109
111
|
console.log(`---`)
|
package/src/stages/quick.js
CHANGED
|
@@ -11,8 +11,10 @@ export const definition = {
|
|
|
11
11
|
### 操作
|
|
12
12
|
1. 检查是否携带 \`--change <变更名>\`,确定记录方式
|
|
13
13
|
2. 理解任务:模糊则问一个问题确认
|
|
14
|
-
3.
|
|
15
|
-
4.
|
|
14
|
+
3. 加载项目信息:\`cat .sillyspec/projects/*.yaml 2>/dev/null\`(了解项目结构和技术栈)
|
|
15
|
+
4. 加载上下文:\`cat .sillyspec/docs/<project>/scan/CONVENTIONS.md 2>/dev/null\`
|
|
16
|
+
5. 加载本地配置:\`cat .sillyspec/local.yaml 2>/dev/null\`(构建命令、测试命令、环境变量等)
|
|
17
|
+
6. 如有需要,查询知识库:\`cat .sillyspec/knowledge/INDEX.md 2>/dev/null\`
|
|
16
18
|
|
|
17
19
|
### 输出
|
|
18
20
|
任务理解 + 上下文摘要`,
|