@netpilot/skills 0.7.0 → 0.9.0

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.
Files changed (51) hide show
  1. package/.claude-plugin/marketplace.json +1 -1
  2. package/.claude-plugin/plugin.json +1 -1
  3. package/.codex-plugin/plugin.json +1 -1
  4. package/AGENTS.md +1 -1
  5. package/CHANGELOG.md +17 -0
  6. package/README.md +6 -1
  7. package/docs/skill-evolution.md +43 -0
  8. package/docs/skill-localization.md +60 -0
  9. package/package.json +1 -1
  10. package/skills/ask/SKILL.md +19 -13
  11. package/skills/ask/references/phase-boundaries.md +70 -0
  12. package/skills/code-review/SKILL.md +14 -14
  13. package/skills/codebase-design/SKILL.md +2 -2
  14. package/skills/diagnosing-bugs/SKILL.md +8 -2
  15. package/skills/diagnosing-bugs/scripts/hitl-loop.template.mjs +3 -1
  16. package/skills/domain-modeling/SKILL.md +1 -1
  17. package/skills/grill-me/SKILL.md +2 -2
  18. package/skills/grill-me/agents/openai.yaml +2 -2
  19. package/skills/grill-with-docs/SKILL.md +5 -5
  20. package/skills/grill-with-docs/agents/openai.yaml +1 -1
  21. package/skills/grilling/SKILL.md +27 -11
  22. package/skills/grilling/agents/openai.yaml +2 -2
  23. package/skills/handoff/SKILL.md +1 -1
  24. package/skills/implement/SKILL.md +2 -2
  25. package/skills/implement/references/verification.md +32 -0
  26. package/skills/improve-codebase-architecture/SKILL.md +7 -5
  27. package/skills/prototype/SKILL.md +3 -3
  28. package/skills/prototype/references/logic.md +38 -58
  29. package/skills/prototype/references/ui.md +51 -43
  30. package/skills/research/SKILL.md +4 -2
  31. package/skills/resolving-merge-conflicts/SKILL.md +1 -1
  32. package/skills/tdd/SKILL.md +9 -7
  33. package/skills/teach/SKILL.md +13 -13
  34. package/skills/to-questionnaire/SKILL.md +57 -0
  35. package/skills/to-questionnaire/agents/openai.yaml +6 -0
  36. package/skills/to-spec/SKILL.md +12 -10
  37. package/skills/to-tickets/SKILL.md +2 -2
  38. package/skills/triage/SKILL.md +9 -9
  39. package/skills/wait-what/SKILL.md +7 -0
  40. package/skills/wait-what/agents/openai.yaml +6 -0
  41. package/skills/wayfinder/SKILL.md +16 -16
  42. package/skills/wizard/SKILL.md +51 -0
  43. package/skills/wizard/agents/openai.yaml +6 -0
  44. package/skills/wizard/template.sh +272 -0
  45. package/skills/writing-for-agents/SKILL-MECHANICS.md +70 -0
  46. package/skills/writing-for-agents/SKILL.md +93 -0
  47. package/skills/writing-for-agents/agents/openai.yaml +6 -0
  48. package/skills/writing-for-agents/references/behavioral-evaluation.md +29 -0
  49. package/skills/writing-great-skills/SKILL.md +0 -125
  50. package/skills/writing-great-skills/agents/openai.yaml +0 -6
  51. package/skills/writing-great-skills/references/glossary.md +0 -279
@@ -0,0 +1,57 @@
1
+ ---
2
+ name: to-questionnaire
3
+ description: 当一项决定依赖另一位知识持有者提供用户自己无法回答的事实或判断,需要生成可异步填写或会议共填的 Markdown questionnaire 时使用。
4
+ disable-model-invocation: true
5
+ ---
6
+
7
+ # To Questionnaire
8
+
9
+ 把用户无法独自回答的事情变成一份 **questionnaire(问卷)**:一份交给某一个人异步填写,或在会议中共同填写的 Markdown 文档。接收者掌握用户缺少的知识;问卷把这些知识提取出来。
10
+
11
+ **Grill the send, not the subject(盘问发送目的,不盘问待解主题)。** 只访谈用户能够回答的 _send_:发给谁,以及需要拿回什么。文档中的问题再瞄准接收者已知与用户所需之间的 **gap(信息缺口)**。
12
+
13
+ 1. **发给谁?** 在一次交流中询问接收者的角色、专业知识,以及与用户的关系。这决定问卷的语气和需要携带多少背景。完成条件:已经知道接收者是谁,以及对方掌握什么用户不知道的知识。
14
+
15
+ 2. **需要拿回什么?** 在一次交流中询问用户无法独自解决、必须由这个人提供的具体决定或事实。完成条件:已经得到一份具体清单,说明用户在收到回答后必须能够做什么或决定什么。
16
+
17
+ 3. **编写 questionnaire。** 针对步骤 1–2 确定的 gap 起草问题,严格采用下方文档结构。写入当前目录的 `to-questionnaire-<slug>.md`,slug 来自主题,并报告最终路径。目标路径已存在时,选择唯一的新后缀或 slug;不得覆盖已有文件。完成条件:文件已经存在,并且步骤 2 中用户点名的每一项都由一个问题覆盖。
18
+
19
+ ## 文档结构
20
+
21
+ 把文档框定为 **discovery questionnaire(探索问卷)**:用户缺少背景,接收者掌握它。按 **most-important-first(最重要的问题优先)**排列问题——异步填写意味着可能只有一次回答机会。问题多于少量时,再按主题用 `##` 标题分组。使用下面的模板。
22
+
23
+ <questionnaire-template>
24
+
25
+ # <问卷标题>
26
+
27
+ **目的:** 为什么需要这份问卷,以及哪个决定取决于它。
28
+
29
+ **发起人:** <用户> — **接收者:** <接收者> — **回答用途:** <回答会用于哪里>
30
+
31
+ ## 背景
32
+
33
+ 用一个段落帮助没有参与用户思考过程的接收者了解背景。提供足以高质量回答的信息,但不要写成一页背景资料。
34
+
35
+ ## 如何回答
36
+
37
+ 写明截止时间与大致投入。部分回答和“我不知道”都有价值;对不确定的内容显式标记,而不是跳过。
38
+
39
+ ## <主题标题>
40
+
41
+ 每个主题一个 `##` 章节,下面按 most-important-first 排列问题。每个问题只问一件事,不把多个问题合在一起;紧接一个作答占位。只有问题可能被误解或招致敷衍回答时,才添加一行“为什么重要”。
42
+
43
+ <question-example>
44
+
45
+ ### 系统在首次发布时预计要承受多大负载?
46
+
47
+ _为什么重要:这决定现在就为突发流量预留容量,还是推迟该投入。_
48
+
49
+ >
50
+
51
+ </question-example>
52
+
53
+ ## 还有其他信息吗?
54
+
55
+ 用一个兜底问题收尾:还有什么我们没有问、但应该知道的事情?
56
+
57
+ </questionnaire-template>
@@ -0,0 +1,6 @@
1
+ interface:
2
+ display_name: "To Questionnaire"
3
+ short_description: "为掌握关键信息的人生成可异步填写的结构化问卷并覆盖全部决策缺口"
4
+ default_prompt: "请使用 $to-questionnaire 询问问卷的收件人与信息缺口,并生成可异步填写的 Markdown。"
5
+ policy:
6
+ allow_implicit_invocation: false
@@ -19,7 +19,7 @@ disable-model-invocation: true
19
19
  1. 若尚未完成,探索仓库当前状态。全文使用项目 glossary 的 canonical terms,并遵守相关 ADR。
20
20
  2. 草拟测试 feature 的 Seams:
21
21
  - 优先复用现有 Seam;
22
- - 必须增加时,尽可能放在最高层;
22
+ - 无论复用还是新增,都尽可能使用最高层的 Seam;
23
23
  - Seam 越少越好,理想情况只有一个。
24
24
 
25
25
  向用户校准这些 Seams 是否符合预期。这是规格发布前的定向确认,不重新开始需求访谈。
@@ -27,23 +27,25 @@ disable-model-invocation: true
27
27
 
28
28
  ## Spec 结构
29
29
 
30
- ### Problem Statement
30
+ ### 问题陈述(Problem Statement
31
31
 
32
32
  从用户视角描述其面对的问题。
33
33
 
34
- ### Solution
34
+ ### 解决方案(Solution
35
35
 
36
36
  从用户视角描述解决方案。
37
37
 
38
- ### User Stories
38
+ ### 用户故事(User Stories
39
39
 
40
40
  使用足够详尽的编号列表覆盖所有用户可观察行为;每条都能独立检查,合在一起覆盖 feature 的全部方面:
41
41
 
42
42
  ```text
43
- 1. As a <actor>, I want a <feature>, so that <benefit>.
43
+ 1. 作为<角色>,我希望<功能>,以便<收益>。
44
44
  ```
45
45
 
46
- ### Implementation Decisions
46
+ 例如:作为手机银行客户,我希望查看各账户余额,以便作出更有依据的消费决策。
47
+
48
+ ### 实施决定(Implementation Decisions)
47
49
 
48
50
  记录已经形成的实施决定,包括:
49
51
 
@@ -58,7 +60,7 @@ disable-model-invocation: true
58
60
 
59
61
  不要写具体文件路径或工作代码,它们很快会过时。唯一例外:prototype 产生的 state machine、reducer、schema 或 type shape 比文字更精确时,可以只嵌入承载 decision 的最小片段,并注明来自 prototype。
60
62
 
61
- ### Testing Decisions
63
+ ### 测试决定(Testing Decisions
62
64
 
63
65
  至少说明:
64
66
 
@@ -66,15 +68,15 @@ disable-model-invocation: true
66
68
  - 哪些 Modules / Seams 要测试;
67
69
  - 代码库中可复用的同类测试先例。
68
70
 
69
- ### Acceptance Criteria
71
+ ### 验收标准(Acceptance Criteria
70
72
 
71
73
  用可观察、可验证的条件定义完成。适合时使用 Given / When / Then;不要把“修改某文件”当作用户行为的验收条件。
72
74
 
73
- ### Out of Scope
75
+ ### 范围外事项(Out of Scope
74
76
 
75
77
  明确与当前 spec 相邻但不包含的事项。
76
78
 
77
- ### Further Notes
79
+ ### 补充说明(Further Notes
78
80
 
79
81
  只放无法归入以上章节、但实施者确实需要的补充信息;没有内容时省略。
80
82
 
@@ -6,7 +6,7 @@ disable-model-invocation: true
6
6
 
7
7
  # To Tickets
8
8
 
9
- 把 plan、spec 或当前对话拆成一组 **tracer-bullet vertical slices**。每个 ticket 都声明阻塞它的 **blocking edges**。
9
+ 把 plan、spec 或当前对话拆成一组 **tracer-bullet vertical slices(曳光弹式垂直切片)**。每个 ticket 都声明阻塞它的 **blocking edges(阻塞关系)**。
10
10
 
11
11
  ## 动作授权
12
12
 
@@ -37,7 +37,7 @@ disable-model-invocation: true
37
37
  - 能在一个新鲜上下文窗口中完成;
38
38
  - 声明真正阻塞它的 tickets;没有 blockers 的 ticket 可立即开始。
39
39
 
40
- **Wide refactor 是垂直切片的例外。** 识别信号不是“改动文件很多”,而是一次不可避免的机械变化——例如 **rename a column** 或 **retype a shared symbol**——会同时打破大量调用点,使普通垂直切片无法先 green。此时使用 **expand–migrate–contract**:
40
+ **Wide refactor(大范围重构)是垂直切片的例外。** 识别信号不是“改动文件很多”,而是一次不可避免的机械变化——例如 **rename a column** 或 **retype a shared symbol**——会同时打破大量调用点,使普通垂直切片无法先 green。此时使用 **expand–migrate–contract**:
41
41
 
42
42
  1. **Expand**:让新旧形式并存,不破坏现有调用者;
43
43
  2. **Migrate**:按 package、目录或其他 blast-radius 边界拆成批次,每批一个 ticket,均被 expand 阻塞,并保持每批 CI green;
@@ -28,18 +28,18 @@ disable-model-invocation: true
28
28
 
29
29
  执行前用一句话列出拟进行的状态变化和写入,无需再次确认。
30
30
 
31
- 若只是“triage 这个 item”但最终状态仍需维护者判断,先给 recommendation 并等待。bare number 无法唯一解析、label mapping 不明或状态冲突时,只读检查并询问。
31
+ 若只是“triage 这个 item”但最终状态仍需维护者判断,先给建议并等待。裸编号无法唯一解析、label mapping 不明或状态冲突时,只读检查并询问。
32
32
 
33
33
  永不自动 push、创建 PR、merge、deploy 或发布。若 `.out-of-scope/` 更新需要 commit,只能在明确本地 branch 上提交;不自动 push。
34
34
 
35
35
  ## 分类与状态
36
36
 
37
- 两个 category
37
+ 两个 category(类别):
38
38
 
39
39
  - **bug**:已有行为损坏;
40
40
  - **enhancement**:新增功能或改进。
41
41
 
42
- 五个 state
42
+ 五个 state(状态):
43
43
 
44
44
  - **needs-triage**:等待维护者评估;
45
45
  - **needs-info**:等待 reporter 补充;
@@ -62,7 +62,7 @@ state labels 冲突时停止写入,先请求维护者决定。
62
62
 
63
63
  ## 模式一:显示需要关注的内容
64
64
 
65
- 按最旧优先查询三个 bucket:
65
+ 按最旧优先查询三个分组:
66
66
 
67
67
  1. unlabeled;
68
68
  2. needs-triage;
@@ -70,7 +70,7 @@ state labels 冲突时停止写入,先请求维护者决定。
70
70
 
71
71
  若 tracker 配置把外部 PR 纳入 triage,发现列表只包含外部作者 PR,并标记 `[PR]` 或 `[issue]`。显式指定的 PR 不受该发现过滤限制。
72
72
 
73
- 输出每个 bucket 的数量与每项一行摘要,让维护者选择。
73
+ 输出每个分组的数量与每项一行摘要,让维护者选择。
74
74
 
75
75
  ## 模式二:Triage 一个 item
76
76
 
@@ -82,8 +82,8 @@ state labels 冲突时停止写入,先请求维护者决定。
82
82
 
83
83
  执行两项代码库检查:
84
84
 
85
- - **Redundancy**:按领域概念搜索现有实现,而不只搜索 reporter 原话,并说明查过哪里。已实现则进入 wontfix,但不写 `.out-of-scope/`。
86
- - **Prior rejection**:读取 `.out-of-scope/*.md`,按概念相似性寻找以前的拒绝。
85
+ - **Redundancy(重复需求)**:按领域概念搜索现有实现,而不只搜索 reporter 原话,并说明查过哪里。已实现则进入 wontfix,但不写 `.out-of-scope/`。
86
+ - **Prior rejection(已有拒绝决定)**:读取 `.out-of-scope/*.md`,按概念相似性寻找以前的拒绝。
87
87
 
88
88
  ### 给出建议
89
89
 
@@ -112,7 +112,7 @@ state labels 冲突时停止写入,先请求维护者决定。
112
112
 
113
113
  请求仍缺关键决定时调用 `$grilling`;术语、状态或不变量需要沉淀时同时调用 `$domain-modeling`。
114
114
 
115
- 一次一个问题。已确认内容写入 triage notes,后续 session 不重问。
115
+ 每一轮询问当前全部已解锁的 frontier;本轮尚未解决的依赖留到下一轮。已确认内容写入 triage notes,后续 session 不重问。
116
116
 
117
117
  ### 应用结果
118
118
 
@@ -167,5 +167,5 @@ state labels 冲突时停止写入,先请求维护者决定。
167
167
  1. 读取已确认内容和未答问题;
168
168
  2. 检查 reporter 后续回复;
169
169
  3. 标出哪些问题已解决;
170
- 4. 展示更新后的 picture;
170
+ 4. 展示更新后的全貌;
171
171
  5. 只询问仍未解决的问题。
@@ -0,0 +1,7 @@
1
+ ---
2
+ name: wait-what
3
+ description: 当用户表示上一条消息没有听懂、没有讲清楚,或显式要求 wait-what 时,用缺失上下文和项目术语重新讲述上一条消息。
4
+ disable-model-invocation: true
5
+ ---
6
+
7
+ 等等——上一条没有讲清楚。重新讲一遍:补一点上下文;使用当前沟通语言的短句和单义技术词,英语时采用 ASD-STE100 Simplified Technical English(简化技术英语);优先使用项目的统一领域语言,多 context 仓库先沿 `CONTEXT-MAP.md` 找到对应的 `CONTEXT.md`,单 context 仓库直接读取 `CONTEXT.md`,不存在时使用已经确认的项目词汇,不杜撰文档内容。
@@ -0,0 +1,6 @@
1
+ interface:
2
+ display_name: "Wait What"
3
+ short_description: "用当前语言和项目术语重新讲清上一条没有讲明白的消息"
4
+ default_prompt: "请使用 $wait-what 补足必要上下文,并用更简明的当前语言重述上一条消息。"
5
+ policy:
6
+ allow_implicit_invocation: false
@@ -6,7 +6,7 @@ disable-model-invocation: true
6
6
 
7
7
  # Wayfinder
8
8
 
9
- Wayfinding 的目标是找到通往 **Destination** 的路,不是冲向 Destination。命名 Destination 是建图的第一项动作,因为它会塑造每一张 ticket。Destination 可能是交给后续流程迭代的明确 spec、规划前尚待锁定的 decision,或在当前 effort 原地完成的 migration。Map 不限定领域:工程、课程内容或其他超过单会话且仍在 fog of war 中的工作都可以使用。
9
+ Wayfinding 的目标是找到通往 **Destination(目的地)** 的路,不是冲向 Destination。命名 Destination 是建图的第一项动作,因为它会塑造每一张 ticket。Destination 可能是交给后续流程迭代的明确 spec、规划前尚待锁定的 decision,或在当前 effort 原地完成的 migration。Map 不限定领域:工程、课程内容或其他超过单会话且仍在 fog of war 中的工作都可以使用。
10
10
 
11
11
  地图由 decision tickets 组成:每票解决一个问题,产物是 decision,而不是 build slice。Destination 是 spec 时,路线清楚后默认交给 `$to-spec`;Destination 本身是 decision 或 Notes 明确允许原地 migration 时,按该 Destination 的完成条件结束,不机械转成 spec。
12
12
 
@@ -44,9 +44,9 @@ Wayfinding 的目标是找到通往 **Destination** 的路,不是冲向 Destin
44
44
 
45
45
  Map 是一个标记为 `wayfinder:map` 的 tracker item,也是 canonical artifact。远程 tracker 使用 parent/child issue;本地 fallback 使用一份 map 文件和每票一个文件。
46
46
 
47
- Map 是索引,不重复保存 ticket 的完整答案。每个 decision 只在其 ticket 的 resolution 中存在;map 只写一句 gist 并链接。
47
+ Map 是索引,不重复保存 ticket 的完整答案。每个 decision 只在其 ticket 的 resolution 中存在;map 只写一句摘要并链接。
48
48
 
49
- Map body 是每个 session 只加载一次的低分辨率视图。Open tickets 不列在 body 中,而是通过 child-ticket query 获取。
49
+ Map body 是每个 session 只加载一次的低分辨率概览。Open tickets 不列在 body 中,而是通过 child-ticket query 获取。
50
50
 
51
51
  ```markdown
52
52
  ## Destination
@@ -56,7 +56,7 @@ Map body 是每个 session 只加载一次的低分辨率视图。Open tickets
56
56
  领域、每个 session 应调用的 skills、常驻约束和权限。
57
57
 
58
58
  ## Decisions so far
59
- - [已关闭 ticket 标题](link) — 一行 decision gist
59
+ - [已关闭 ticket 标题](link) — 一行决定摘要
60
60
 
61
61
  ## Not yet specified
62
62
  仍在 scope 内,但尚无法精确表述为问题的 fog。
@@ -87,7 +87,7 @@ Map body 是每个 session 只加载一次的低分辨率视图。Open tickets
87
87
 
88
88
  - **research**:AFK。当 decision 等待当前工作目录之外的一手知识时使用,读取并返回带来源的事实;普通 repo exploration 不建立 research ticket。
89
89
  - **prototype**:HITL。制作低成本 artifact,让人对具体形态或行为作出判断。
90
- - **grilling**:HITL。调用 `$grilling` 与 `$domain-modeling`,一次一个问题;这是不确定类型时的默认选择。
90
+ - **grilling**:HITL。调用 `$grilling` 与 `$domain-modeling`,以 rounds 询问当前 ticket 内 design tree 的全部 frontier;这是不确定类型时的默认选择。
91
91
  - **task**:HITL 或 AFK。完成一个必须先发生、但本身没有 decision 的动作,以解除后续阻塞。Resolution 要记录后续 tickets 依赖的事实,例如 credential location、URL、row count 或完成步骤。
92
92
 
93
93
  HITL ticket 必须让真人表达自己的判断;agent 不得代替用户回答访谈问题。
@@ -130,26 +130,26 @@ Out of scope 是经过确认的 scope boundary,不是尚未看清的 fog,永
130
130
 
131
131
  只有 destination 被重新定义时,才将相关内容作为新 effort 重新考虑。
132
132
 
133
- ## 调用模式一:Chart the map
133
+ ## 调用模式一:绘制地图(Chart the map
134
134
 
135
135
  用户以大型模糊想法调用:
136
136
 
137
- 1. **Name the destination**
137
+ 1. **命名目的地(Name the destination)**
138
138
  调用 `$grilling` 和 `$domain-modeling`,明确 map 最终要找到什么。它们返回 destination、scope 和统一术语。
139
139
 
140
- 2. **Breadth-first map the frontier**
140
+ 2. **广度优先绘制 frontier**
141
141
  再次访谈,但横向扫描整个空间,寻找当前可精确表达的 decisions 与仍在 fog 中的区域。不要过早深入单一分支。
142
142
 
143
143
  3. **检查是否真的需要 map**
144
144
  如果没有 fog,且全部工作可在一个 session 中解释清楚,停止建图,告诉用户应进入 `$to-spec` 或 `$implement`。
145
145
 
146
- 4. **Create the map**
146
+ 4. **创建地图**
147
147
  填写 Destination、Notes、空的 Decisions so far、Not yet specified 和 Out of scope。
148
148
 
149
- 5. **Create then wire tickets**
149
+ 5. **先创建票据,再连接依赖**
150
150
  先创建所有当前可定义的 child tickets,拿到真实标识符后,第二 pass 再建立 blocking。不能在创建前猜 id。
151
151
 
152
- 6. **Fire research tickets**
152
+ 6. **启动研究票据**
153
153
  research tickets 可以并行:
154
154
  - 为每票创建隔离 worktree/本地 branch;
155
155
  - 调用 `$research` 写带引用的 Markdown artifact;
@@ -159,14 +159,14 @@ Out of scope 是经过确认的 scope boundary,不是尚未看清的 fog,永
159
159
  - 关闭 research ticket并更新 map。
160
160
  不得自动 push branch。
161
161
 
162
- 7. **Stop**
162
+ 7. **停止**
163
163
  Charting session 不手工解决 grilling、prototype 或 task ticket。
164
164
 
165
- ## 调用模式二:Work through the map
165
+ ## 调用模式二:逐票推进地图(Work through the map
166
166
 
167
167
  用户提供 map URL、编号或本地路径。ticket 参数可选。
168
168
 
169
- 1. 加载 map 的低分辨率视图,不一次读取所有 ticket body。
169
+ 1. 加载 map 的低分辨率概览,不一次读取所有 ticket body。
170
170
  2. 用户指定 ticket 时使用它;否则选择第一个 frontier ticket。
171
171
  3. 在工作前 claim。
172
172
  4. 按 type 解决,并调用 map `Notes` 中点名的 skills;未指定且不确定时默认使用 `$grilling` + `$domain-modeling`:
@@ -174,11 +174,11 @@ Out of scope 是经过确认的 scope boundary,不是尚未看清的 fog,永
174
174
  - prototype → `$prototype`;
175
175
  - grilling → `$grilling` + `$domain-modeling`;
176
176
  - task → 完成解除 decision blocker 所需的最小动作。
177
- 5. 需要时再 zoom:按需读取相关 open/closed ticket 全文。
177
+ 5. 需要时再展开细节:按需读取相关 open/closed ticket 全文。
178
178
  6. 记录 resolution:
179
179
  - 写 resolution comment;
180
180
  - 关闭 ticket;
181
- - 在 Decisions so far 追加标题链接与一行 gist。
181
+ - 在 Decisions so far 追加标题链接与一行摘要。
182
182
  7. 更新地图:
183
183
  - create then wire 新 ticket;
184
184
  - 把已变得可精确表达的 fog 转为 ticket,并从 Not yet specified 删除;
@@ -0,0 +1,51 @@
1
+ ---
2
+ name: wizard
3
+ description: 为必须由用户完成的控制台操作、凭证录入或一次性迁移生成交互式 Bash 向导;仅在存在人工步骤时使用,agent 能自行完成的操作不转交给用户。生成脚本不等于执行脚本或授权外部写入。
4
+ ---
5
+
6
+ # Wizard
7
+
8
+ **Wizard(交互式向导)** 是分阶段引导人完成手工流程的 Bash 脚本:打开 URL,说明点击和复制位置,接收输入,把值写到明确目标,在必要动作前确认,并显示剩余阶段。它可以帮助配置第三方服务、执行一次性迁移,或从一个已知状态转到另一个状态。
9
+
10
+ [template.sh](template.sh) 已提供公共 library:阶段进度、清屏、确认、跨平台打开 URL(含 WSL)、隐藏秘密输入、`.env` 幂等 upsert、GitHub secret/variable 写入和结束摘要。**生成向导时,只确定流程并编写阶段,保持 `STAGES` 标记以上的 library 不变。**
11
+
12
+ 向导默认是一次性产物,保存在明确的 scratch 或 `scripts/` 路径。任务结束时说明哪些文件可清理;删除须有目标明确的授权。只有用户要求可重复运行的项目配置路径时才建议保留到仓库;commit、远程写入及不可逆动作分别遵守当前授权。
13
+
14
+ ## 1. 确定人工流程
15
+
16
+ 先读仓库,不把可以查明的事实交给用户:
17
+
18
+ - 配置任务:`.env.example`、`.env*` 的键名和格式、README、`docker-compose*`、框架配置、`.github/workflows/*` 中的每个 `secrets.*` / `vars.*` 引用。只识别所需值与去向,不把已有秘密读入对话或日志。
19
+ - 迁移任务:当前状态、目标状态、不可逆动作及哪些步骤可重复。配置 upsert 可重跑,不表示迁移命令也幂等。
20
+ - 执行环境:Bash 与必要系统工具;Windows 使用已安装的 Git Bash 或 WSL,不能把存在 `bash.exe` 当成可运行证明。没有可用 Bash 时说明限制,协商等价交付形式,不自动安装运行环境。
21
+
22
+ 向用户展示按顺序排列的阶段、每阶段产生的值和写入位置,等待确认;用户可增删或重排阶段。既有授权可复用,但只授权生成脚本时不运行它。需要 GitHub 写入时,明确 `[host/]owner/repo`,由阶段代码设置 `GH_REPO`,不从运行时工作目录猜目标。
23
+
24
+ 完成条件:每个阶段已命名并排序;每个值的来源、目标(`.env`、GitHub、两者或不保存)和是否为秘密都已明确;没有凭证的纯操作阶段也已标出。
25
+
26
+ ## 2. 描述每个阶段的路径
27
+
28
+ 写清楚打开哪个 URL、点击什么、在哪里取得哪个值、填入哪个变量,例如“Dashboard → Developers → API keys → Reveal test key → 复制”。不知道当前 UI 或精确命令时查一手文档,必要时向用户确认;保留界面实际显示的英文名称,说明用中文。
29
+
30
+ 完成条件:每个阶段都有陌生人也能照做的具体路径,尚未核实的步骤明确列为阻塞。
31
+
32
+ ## 3. 编写向导
33
+
34
+ 把模板复制到不覆盖既有文件的目标路径,替换示例,按依赖顺序每步一个 `stage`。复用 `stage`、`say` / `step`、`open_url`、`ask` / `ask_secret`、`write_env`、`set_secret` / `set_var`、`pause` / `confirm`;`TOTAL_STAGES` 与真实阶段数一致。示例中的服务只是演示,不自动成为用户的选择。
35
+
36
+ 先打开 URL,再询问该页面上的值;秘密使用 `ask_secret`,认证留在用户浏览器中,URL 不携带秘密。持久化 `.env` 值使用 `write_env`,CI 只接收实际引用的值。`set_secret` / `set_var` 会确认明确仓库;不可逆操作也必须置于实际控制流门禁后,例如 `confirm "执行已说明的不可逆动作?" || exit 1`,不能只打印提醒然后继续执行。
37
+
38
+ 每个阶段只承载一个聚焦任务,清屏后仍能看见该任务所需说明。界面只有人能操作的部分交给人;能够安全调用的 API、CLI 或本地检查由 agent 在已授权范围完成。
39
+
40
+ 模板只处理单行 `KEY=value` 的 dotenv 文件:保留空行、整行注释与其他键;支持可准确往返的普通单引号或双引号值。复杂转义、行尾注释、多行值、混合引号组合或符号链接目标会拒绝写入。遇到这些格式,使用项目已认可的配置工具或把该阶段改为明确的人工配置;不得丢弃字符来“修复”凭证,也不得 `source` 不可信 `.env`。写入会以 `mktemp` 文件替换目标,不保证保留原 owner、mode 或 ACL;需要其他服务用户读取的共享配置,应使用项目认可的权限管理工具。运行前核对执行用户与实际读取者的权限,并确保没有其他进程同时编辑该配置;模板不提供多文件事务或并发写入保证。
41
+
42
+ 完成条件:阶段顺序、计数和每个值的去向与已确认流程一致;每个不可逆动作和 GitHub 写入都受实际确认门禁控制;重新运行不会盲目重复已完成的非幂等动作。
43
+
44
+ ## 4. 验证并交接
45
+
46
+ - 执行 `bash -n <script>`;`shellcheck` 可用时运行,并如实记录缺失。
47
+ - POSIX 环境执行 `chmod +x <script>`;也可以交付明确的 `bash <script>` 命令。
48
+ - agent 不端到端运行生成的真实向导:它会打开浏览器、等待人输入并可能产生外部动作。静态追踪每个值是否到达步骤 1 指定的目标,每个 CI secret 名称是否精确对应 `secrets.*` 引用。
49
+ - 用户要求可重复使用时,按现有授权保存并在项目 README 链接;未授权 commit 时只留下可审查改动。
50
+
51
+ 完成条件:返回脚本绝对路径、执行命令、已执行检查及结果、未验证的人工步骤;有 skipped 或未确认写入时明确列出,不能声称目标状态已全部达成。用户执行后返回结束摘要与脱敏观察结果,调用方据此恢复原任务;不索要原始凭证。
@@ -0,0 +1,6 @@
1
+ interface:
2
+ display_name: "Wizard"
3
+ short_description: "生成供用户执行的分阶段人工操作向导,明确输入、写入目标和验证证据"
4
+ default_prompt: "请使用 $wizard 为必须由我操作的步骤生成可运行向导,并先列出阶段和数据去向。"
5
+ policy:
6
+ allow_implicit_invocation: true