@heihei0299/matt-skills 2.0.0 → 2.0.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/.agents/skills/ci-guard/SKILL.md +30 -74
- package/.agents/skills/diagnose-fix/SKILL.md +19 -42
- package/.agents/skills/grill-to-spec/SKILL.md +21 -58
- package/.agents/skills/scaffold-functional-test/SKILL.md +28 -42
- package/.agents/skills/scaffold-functional-test/references/schema.md +35 -0
- package/.agents/skills/show-me/SKILL.md +25 -2
- package/README.md +2 -2
- package/bin/cli.js +2 -1
- package/package.json +1 -1
- package/template/.agents/skills/ci-guard/SKILL.md +30 -74
- package/template/.agents/skills/diagnose-fix/SKILL.md +19 -42
- package/template/.agents/skills/grill-to-spec/SKILL.md +21 -58
- package/template/.agents/skills/scaffold-functional-test/SKILL.md +28 -42
- package/template/.agents/skills/scaffold-functional-test/references/schema.md +35 -0
- package/template/.agents/skills/show-me/SKILL.md +25 -2
|
@@ -1,94 +1,50 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: ci-guard
|
|
3
|
-
description: "
|
|
3
|
+
description: "保护本仓库 GitHub Actions CI/release pipeline：按发布、workflow 维护或发布后故障场景执行必要门禁。Use when CI is flaky/failing, when setting up or editing .github/workflows/ci.yml, or before tagging a release to npm."
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# CI Guard
|
|
7
7
|
|
|
8
|
-
|
|
8
|
+
本 skill 只编排当前仓库的 CI 与 npm 发布门禁。先读取 `.github/workflows/ci.yml`，以实际 workflow 的 job、input、condition 和权限为事实源；不要假设不存在的 job、input 或自动回滚行为。产品代码 bug 的诊断和修复交给 `diagnose-fix`，不在此重复通用诊断。
|
|
9
9
|
|
|
10
|
-
##
|
|
10
|
+
## 场景选择
|
|
11
11
|
|
|
12
|
-
-
|
|
13
|
-
-
|
|
14
|
-
-
|
|
12
|
+
- 用户请求发布、打 release tag 或发布 npm → **发布路径**；
|
|
13
|
+
- 用户修改 workflow，或报告 Actions 红/偶发红 → **workflow 维护路径**；
|
|
14
|
+
- tag 已发布但 registry、release 或 post-check 异常 → **发布后故障路径**。
|
|
15
15
|
|
|
16
|
-
|
|
16
|
+
只执行命中的路径；普通发布不运行与当前 workflow 无关的 lint、dry-run 或 dispatch。
|
|
17
17
|
|
|
18
|
-
|
|
19
|
-
① 编排 flows → ② 预发布 gate → ③ 发布后自纠
|
|
20
|
-
```
|
|
18
|
+
## 发布路径
|
|
21
19
|
|
|
22
|
-
|
|
20
|
+
1. 读取当前 package metadata 和 workflow；确认正式 tag 的 commit 可从 `main` 到达，目标 tag 尚不存在，版本与 tag 约定一致。
|
|
21
|
+
2. 运行项目规定的测试和 `npm pack --dry-run`，确认发布内容和实际结果。
|
|
22
|
+
3. 只有前两步通过后才创建并推送 `vX.Y.Z` tag；不从非 `main` commit 推送正式 tag。
|
|
23
|
+
4. 等待 tag workflow 完成，确认 `verify` 成功后才进入 `publish`，并记录 Actions run URL、job 结论和实际 npm tag。
|
|
24
|
+
5. 使用 `npm view <package>@<version> version` 或 registry API 回读，确认发布版本真实可见。
|
|
23
25
|
|
|
24
|
-
|
|
25
|
-
|
|
26
|
-
### ① 编排 flows —— 让工作流不可被绕过
|
|
27
|
-
|
|
28
|
-
**做**：
|
|
29
|
-
- `on`：`push.tags: ["v*"]` **必须**同时配 `push.branches: [main]`（或 `master`）+ `pull_request.branches: [main]` + `workflow_dispatch`。否则直推 `main` 的修复（如 `2d68f62`）无法被 CI 验证，tag 才暴露问题
|
|
30
|
-
- `jobs` 依赖：`publish.needs: [build, verify]`，**禁止** `needs: build` 单依赖。门禁失效的直接原因就是 `verify` 红仍发包
|
|
31
|
-
- `permissions` 最小化：`verify`/`build` 只需 `contents: read`，仅 `publish` 保留 `contents: write` + `packages: write`（或 `id-token: write` 若用 OIDC）
|
|
32
|
-
- `concurrency`：`group: ci-${{ github.ref }}` + `cancel-in-progress: true`，避免同分支并行互踩
|
|
33
|
-
|
|
34
|
-
**完成条件**：
|
|
35
|
-
- [ ] `git diff HEAD -- .github/workflows/ci.yml` 显示 `on.push.branches` 存在
|
|
36
|
-
- [ ] `publish.needs` 包含 `verify`
|
|
37
|
-
- [ ] `workflow_dispatch` 可手动触发全量
|
|
38
|
-
|
|
39
|
-
---
|
|
40
|
-
|
|
41
|
-
### ② 预发布 gate —— 测试 GitHub Action 流程
|
|
42
|
-
|
|
43
|
-
本段是**硬门槛**，顺序固定：`action lint → workflow dry-run → dispatch 验证`，任一步红即阻断 `publish`。
|
|
44
|
-
|
|
45
|
-
**action lint**：
|
|
46
|
-
- `actionlint` 校验 `.github/workflows/ci.yml` 语法与 `on/needs/permissions` 完整性
|
|
47
|
-
- `yamllint` 检查缩进与重复键
|
|
26
|
+
出口：tag、Actions 和 registry 的实际结果均已记录；任一失败都阻断“发布成功”结论。
|
|
48
27
|
|
|
49
|
-
|
|
50
|
-
- `act --dry-run` 或 `gh workflow view` 模拟 `verify/build/publish` 三 job 依赖与 `if` 条件
|
|
51
|
-
- 校验 `publish.needs` 含 `verify` 且 `workflow_dispatch` 可手动触发
|
|
28
|
+
## Workflow 维护路径
|
|
52
29
|
|
|
53
|
-
|
|
54
|
-
|
|
55
|
-
-
|
|
30
|
+
1. 读取当前 workflow，按实际内容检查触发器、`publish.needs`、job `if`、权限和 concurrency；不硬编码 job 名称。
|
|
31
|
+
2. 只有 workflow 在本次范围内发生变化，或故障需要时，才运行已安装的 `actionlint` / `yamllint`；工具不可用就记录 `unavailable`，不得伪报通过。
|
|
32
|
+
3. 需要 dry-run 或手动 dispatch 时，只使用 workflow 已声明的 input；不得传入未声明的 `dry_run` 等参数。若无安全的 dry-run input，改用静态依赖检查或一次不发布的验证运行。
|
|
33
|
+
4. 失败时区分 workflow wiring、项目测试、授权/registry 和 runner 环境；只修复当前请求范围内的问题。
|
|
56
34
|
|
|
57
|
-
|
|
58
|
-
- [ ] `actionlint` 0 error
|
|
59
|
-
- [ ] `act --dry-run` 三 job 依赖正确
|
|
60
|
-
- [ ] `workflow_dispatch` 试运行通过
|
|
61
|
-
|
|
62
|
-
---
|
|
63
|
-
|
|
64
|
-
### ③ 发布后自纠 —— 发出去的包自己负责
|
|
65
|
-
|
|
66
|
-
**发布时**：
|
|
67
|
-
- `npm publish --access public` 仅在 `if: startsWith(github.ref, 'refs/tags/v')` 且 `needs` 全绿时执行
|
|
68
|
-
- 发布前 `actions/download-artifact` 校验 `if-no-files-found: error`，发布后 `npm view <pkg>@<version> version` 回读确认
|
|
69
|
-
|
|
70
|
-
**自纠**：
|
|
71
|
-
- 失败即 **阻断**：`verify` 红 → `publish` 不执行（由 `needs` 保证）；`publish` 自身失败（`409 already exists` / `401`）→ 工作流整体 `failure`，不静默
|
|
72
|
-
- 发布后 30s 内 `curl https://registry.npmjs.org/<pkg>/<version>` 校验可用；失败则 `gh issue create --title "chore(release): vX.Y.Z 发布后自检失败" --body "run: ${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}"` 并 `gh release delete vX.Y.Z --yes`（或 `npm unpublish <pkg>@<version>` 在 72h 内）
|
|
73
|
-
- `workflow_dispatch` 支持 `inputs.rollback_version` 手动回滚
|
|
74
|
-
|
|
75
|
-
**完成条件**：
|
|
76
|
-
- [ ] `npm view` 回读与 tag 一致
|
|
77
|
-
- [ ] 失败路径有 issue/通知（非静默）
|
|
78
|
-
- [ ] `git tag` 与 `package.json version` 一致（`scripts/release.sh` 或 `npm version` 保证）
|
|
79
|
-
|
|
80
|
-
---
|
|
35
|
+
出口：实际 workflow 结构、检查命令和运行结果均有证据；未验证项明确列出。
|
|
81
36
|
|
|
82
|
-
##
|
|
37
|
+
## 发布后故障路径
|
|
83
38
|
|
|
84
|
-
|
|
85
|
-
|
|
86
|
-
|
|
87
|
-
- **`-A clippy::all`**：掩盖真实告警
|
|
39
|
+
1. 读取对应 Actions run、npm registry 和 Git tag 的实际状态，确认是未发布、发布延迟、重复版本、授权失败还是 post-check 失败。
|
|
40
|
+
2. 创建或补充带 run URL 的 issue，记录 registry 查询结果和失败分类。
|
|
41
|
+
3. 只按照当前 workflow 声明的人工回滚步骤操作；不自行声称删除 release、删除 tag 或 `npm unpublish` 已发生。
|
|
88
42
|
|
|
89
|
-
|
|
43
|
+
出口：故障分类、保留的远端对象和人工下一步均已明确。
|
|
90
44
|
|
|
91
|
-
|
|
92
|
-
- 修复：`2d68f62 fix(ci): gate publish on verify and serialize Rust tests`
|
|
93
|
-
- 关联技能：`diagnose-fix`（通用诊断）、`commit-check`（提交前门禁）、`tdd`（测试隔离后的回归）
|
|
45
|
+
## 不做什么
|
|
94
46
|
|
|
47
|
+
- 不把每次发布都扩展为完整 CI 工具链演练；
|
|
48
|
+
- 不引用不存在的 `build` job、`dry_run` input 或 `rollback_version` input；
|
|
49
|
+
- 不把历史事故描述当成当前仓库事实；
|
|
50
|
+
- 不自动删除 tag/release，不静默吞掉 publish 或 post-check 失败。
|
|
@@ -5,61 +5,38 @@ description: "Complete diagnosis→fix→regression channel for bugs: diagnose,
|
|
|
5
5
|
|
|
6
6
|
# Diagnose Fix
|
|
7
7
|
|
|
8
|
-
|
|
8
|
+
本 skill 只连接诊断、TDD 修复和回归三个阶段。诊断细节以 [`diagnosing-bugs`](.agents/skills/diagnosing-bugs/SKILL.md) 为事实源，红绿语义以 [`tdd`](.agents/skills/tdd/SKILL.md) 为事实源；不复制两个上游的完整步骤。
|
|
9
9
|
|
|
10
|
-
|
|
10
|
+
## 流程
|
|
11
11
|
|
|
12
|
-
|
|
12
|
+
### ① 诊断
|
|
13
13
|
|
|
14
|
-
|
|
15
|
-
① 诊断 → ② TDD 修复（硬门槛）→ ③ 回归验证
|
|
16
|
-
```
|
|
14
|
+
委托 `diagnosing-bugs` 完成 Phase 1–4：建立能捕捉用户症状的 tight feedback loop，实际复现并最小化，再形成可证伪的假设并按单变量探针验证。
|
|
17
15
|
|
|
18
|
-
|
|
16
|
+
出口：反馈回路已实际变红，且最小复现已确认；此阶段不写修复代码。
|
|
19
17
|
|
|
20
|
-
|
|
18
|
+
### ② TDD 修复
|
|
21
19
|
|
|
22
|
-
1.
|
|
23
|
-
2.
|
|
24
|
-
3.
|
|
25
|
-
4. **探针**（Phase 4）：一次只改一个变量，临时探针用 `[DEBUG-...]` 前缀标记。
|
|
20
|
+
1. 在正确的公共 seam 上提出回归测试边界，并遵循 `tdd` 要求获得用户确认；只确认本次 seam，不建立重型 seam ledger。
|
|
21
|
+
2. 加载 `tdd`，先把最小复现转成失败回归测试并实际看到 Red。
|
|
22
|
+
3. 只写让该测试 Green 的最小修复，并遵循 `tdd` 的红绿循环。
|
|
26
23
|
|
|
27
|
-
|
|
24
|
+
**硬门槛：**不存在已实际观察到的失败回归测试时，不得写任何修复代码。不存在正确 seam 时，本身就是 finding；记录架构阻塞，不绕过测试直接修改。
|
|
28
25
|
|
|
29
|
-
|
|
26
|
+
出口：回归测试先 Red，最小修复后 Green；不进入 `tdd-implement` 的长流程。
|
|
30
27
|
|
|
31
|
-
|
|
28
|
+
### ③ 回归收尾
|
|
32
29
|
|
|
33
|
-
|
|
30
|
+
按 `diagnosing-bugs` 的收尾要求重跑阶段 ① 的原始、未最小化反馈回路，确认用户症状消失；清理 `[DEBUG-...]` 探针和一次性 harness，并记录最终验证的假设。
|
|
34
31
|
|
|
35
|
-
|
|
36
|
-
- **轻量声明**：本技能不套用 tdd-implement 的重流程——不做逐 todo 的循环编排、不设 seams 确认步骤、无 typecheck/commit 前置门禁；单 seam 修复场景直走红-绿。
|
|
37
|
-
**出口条件**：回归测试先红 → 写最小修复 → 回归测试变绿。
|
|
32
|
+
出口：原始症状消失、回归测试 Green、临时诊断产物已清理。
|
|
38
33
|
|
|
39
|
-
##
|
|
34
|
+
## 回合连续性
|
|
40
35
|
|
|
41
|
-
|
|
42
|
-
2. 清理：删除所有 `[DEBUG-...]` 标记的临时探针与一次性 harness（`grep` 前缀确认无残留）。
|
|
43
|
-
3. 在 commit / PR 消息中写明**验证正确的假设**（诊断阶段哪个假设被证实），让下一个调试者受益。
|
|
44
|
-
|
|
45
|
-
**出口条件**：原始症状消失 + 回归测试绿 + 临时探针清理完成。
|
|
46
|
-
|
|
47
|
-
## 反模式（不做什么）
|
|
48
|
-
|
|
49
|
-
完整反模式清单见 [references/anti-patterns.md](references/anti-patterns.md)——正文各阶段规则是正面约束，反模式清单是负向边界；细节只在一处存在，本文件不重复。
|
|
50
|
-
|
|
51
|
-
## 回合连续性规则
|
|
52
|
-
|
|
53
|
-
诊断 → 修复 → 回归**在一个回合内串行完成**，不等用户"继续"：构建回路 → 复现 → 假设 → 探针 → 失败测试 → 修复 → 回归 → 清理整条链一气呵成，中途不停顿。
|
|
54
|
-
|
|
55
|
-
输出只允许发生在以下三种情况：
|
|
56
|
-
- **合规交互点**：技能要求的用户确认——阶段①假设清单展示、阶段②无 seam finding 上报或 seam 决策请求
|
|
57
|
-
- **外部阻塞**：权限拒绝、缺失授权、依赖不可用——明确说明所需授权或替代路径，不静默停止
|
|
58
|
-
- **阶段出口**：整个阶段的出口条件满足（阶段①回路已红 + 复现最小化；阶段②失败测试已红 → 修复变绿；阶段③症状消失 + 回归绿 + 清理完成）
|
|
59
|
-
|
|
60
|
-
预告下一步后立即执行该步骤，回合终点仅为合规交互点、外部阻塞或阶段出口条件满足。进度输出本身不结束回合——输出后继续执行，直到三类终点之一达成。
|
|
36
|
+
诊断 → seam 确认 → Red → 修复 → Green → 原始回路 → 清理在一个回合内连续推进。只在用户必须确认 seam、发现无 seam finding、外部环境阻塞或整个阶段出口时暂停；预告下一步后立即执行。
|
|
61
37
|
|
|
62
38
|
## 引用
|
|
63
39
|
|
|
64
|
-
- 诊断：[diagnosing-bugs](.agents/skills/diagnosing-bugs/SKILL.md)
|
|
65
|
-
-
|
|
40
|
+
- 诊断：[`diagnosing-bugs`](.agents/skills/diagnosing-bugs/SKILL.md)
|
|
41
|
+
- 修复：[`tdd`](.agents/skills/tdd/SKILL.md)
|
|
42
|
+
- 负向边界：[`references/anti-patterns.md`](references/anti-patterns.md)
|
|
@@ -6,75 +6,38 @@ disable-model-invocation: true
|
|
|
6
6
|
|
|
7
7
|
# Grill to Spec
|
|
8
8
|
|
|
9
|
-
|
|
10
|
-
|
|
11
|
-
## 职责
|
|
12
|
-
|
|
13
|
-
| 做 | 不做 |
|
|
14
|
-
|----|------|
|
|
15
|
-
| 编排 `grill-with-docs` → `to-spec` 完整通道 | 不编写代码、不修改任何源码（含测试） |
|
|
16
|
-
| 引导用户从模糊想法 → 结构化 spec | 不拆 tickets（`/to-tickets` 职责） |
|
|
17
|
-
| grilling 逐问挑战、打磨设计 | 不调用 `/code-review` |
|
|
18
|
-
| 同步产出领域文档（glossary inline；ADR 草稿经用户确认后落盘） | 阶段②仅综合，不新增采访 |
|
|
19
|
-
| 综合对话为可执行的 spec 文档并发布 | 不维护已发布的 spec |
|
|
20
|
-
| 产出物仅限领域文档与 spec | 实现与修复交给实现类 skill（如 `/tdd-implement`） |
|
|
9
|
+
只做两个上游 skill 的编排：先把想法打磨成共识，再把共识发布成 spec。本 skill 不写代码、不修改源码或测试。
|
|
21
10
|
|
|
22
11
|
## 流程
|
|
23
12
|
|
|
24
|
-
|
|
25
|
-
① Grill with docs → ② Synthesize to spec
|
|
26
|
-
```
|
|
27
|
-
|
|
28
|
-
① 加载 `/grill-with-docs`：grilling 采访（一次一问、等反馈；决策逐条交由用户定夺）+ domain-modeling 产出 glossary/ADR。出口：用户确认共识达成。
|
|
29
|
-
|
|
30
|
-
① 内 ADR 子流转（与 glossary 的 inline 更新严格区分）：
|
|
31
|
-
1. 触发：仅当 domain-modeling 三条件全满足（难逆转 / 无上下文费解 / 真实权衡）才提议 ADR
|
|
32
|
-
2. 草稿：按 ADR-FORMAT 把完整标题+正文展示给用户审阅，等待反馈
|
|
33
|
-
3. 确认：用户显式说「确认/写入」才落盘；用户拒绝则不写、继续访谈；用户要求修改则改草稿重新确认
|
|
34
|
-
4. 未确认前不得创建或写入 `docs/adr/` 下的任何文件
|
|
35
|
-
|
|
36
|
-
② 加载 `/to-spec`：探索代码（glossary 词汇贯穿 spec、尊重相关 ADR）→ 确认 seams（既有优先、最高 seam、理想一个）→ 编写 spec 草稿 → 展示给用户确认（只展示等决定，不新增采访提问）→ 发布到 `.scratch/<feature-slug>/spec.md` 并标 `ready-for-agent`。出口：spec 已发布。
|
|
37
|
-
|
|
38
|
-
## 产出物（格式严格对齐下游技能）
|
|
39
|
-
|
|
40
|
-
本技能产出物仅以下三种，格式以各技能文件为唯一事实源，不在本技能重写：
|
|
41
|
-
|
|
42
|
-
| 产出物 | 位置 | 格式来源 |
|
|
43
|
-
|--------|------|----------|
|
|
44
|
-
| Glossary | `CONTEXT.md`（多上下文：`CONTEXT-MAP.md` + 各上下文 `CONTEXT.md`） | [CONTEXT-FORMAT.md](.agents/skills/domain-modeling/CONTEXT-FORMAT.md) |
|
|
45
|
-
| ADR | `docs/adr/NNNN-slug.md`（多上下文：系统级在根，上下文级在 `src/<ctx>/docs/adr/`） | [ADR-FORMAT.md](.agents/skills/domain-modeling/ADR-FORMAT.md) |
|
|
46
|
-
| Spec | 发布到 issue tracker：`.scratch/<feature-slug>/spec.md` | [to-spec 七节模板](.agents/skills/to-spec/SKILL.md) |
|
|
13
|
+
### ① 形成共识
|
|
47
14
|
|
|
48
|
-
|
|
15
|
+
调用 [`grill-with-docs`](.agents/skills/grill-with-docs/SKILL.md)，由 `grilling` 与 `domain-modeling` 完成采访、术语和设计决策。
|
|
49
16
|
|
|
50
|
-
|
|
17
|
+
- glossary 按上游规则 inline 更新；
|
|
18
|
+
- 只有确需 ADR 时才创建 ADR 草稿；
|
|
19
|
+
- ADR 必须先展示完整草稿，用户明确确认后才写入，未确认不得落盘。
|
|
51
20
|
|
|
52
|
-
|
|
53
|
-
- **ADR 与 glossary 不对称**：`CONTEXT.md` 术语可随访谈 inline 更新（domain-modeling 规则），ADR 必须先审草稿、用户确认后才落盘——禁止把 inline 逻辑套用到 ADR
|
|
21
|
+
出口：用户确认共识已达成，且所有 ADR 草稿都已获得单独确认或明确不写入。
|
|
54
22
|
|
|
55
|
-
|
|
23
|
+
### ② 发布 spec
|
|
56
24
|
|
|
57
|
-
|
|
58
|
-
|--------|------|------|
|
|
59
|
-
| ② seam 确认 | 用户不同意 seams | → ① 补充 |
|
|
60
|
-
| ② 发布后 | spec 有问题 | → ① 重新循环 |
|
|
25
|
+
将已确认的共识交给 [`to-spec`](.agents/skills/to-spec/SKILL.md)，完成代码库理解、seam 提案和 spec 组装。
|
|
61
26
|
|
|
62
|
-
|
|
27
|
+
- 将 seam 提案并入最终 spec 草稿，不单独制造一次重复确认；
|
|
28
|
+
- 发布前展示完整 spec 草稿，用户一次明确确认后才写入 `.scratch/<feature-slug>/spec.md`；
|
|
29
|
+
- 发布时使用 `ready-for-agent`，格式细则只读取 [`references/rules.md`](references/rules.md)。
|
|
63
30
|
|
|
64
|
-
|
|
65
|
-
|------|------|
|
|
66
|
-
| 用户中途放弃 / 无主题 | 终止 |
|
|
67
|
-
| tracker 未配置 | 提示 `/setup-matt-pocock-skills`，终止 |
|
|
68
|
-
| ① 超过 5 轮无进展 | 建议暂停或缩小范围 |
|
|
31
|
+
出口：spec 已发布，路径、状态和未纳入范围已报告。
|
|
69
32
|
|
|
70
|
-
##
|
|
33
|
+
## 本 skill 独有门禁
|
|
71
34
|
|
|
72
|
-
-
|
|
73
|
-
-
|
|
35
|
+
- ADR：草稿 → 用户确认 → 落盘，任何情况不例外；
|
|
36
|
+
- spec：共识与 seam 合并为一个最终草稿，只设置一次发布前确认；
|
|
37
|
+
- 全程不写代码、不修改测试、不执行实现。
|
|
74
38
|
|
|
75
|
-
##
|
|
39
|
+
## 异常
|
|
76
40
|
|
|
77
|
-
-
|
|
78
|
-
-
|
|
79
|
-
-
|
|
80
|
-
- [to-spec](.agents/skills/to-spec/SKILL.md)
|
|
41
|
+
- 用户放弃或没有可形成 spec 的主题时终止；
|
|
42
|
+
- issue tracker 未配置时报告配置阻塞，不绕过发布；
|
|
43
|
+
- 用户改变已确认的设计时回到 ①，不在 ② 静默扩大范围。
|
|
@@ -1,75 +1,61 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: scaffold-functional-test
|
|
3
3
|
disable-model-invocation: false
|
|
4
|
-
description: "Scaffold a repo-specific functional-test skill from spec — use when the user wants to generate a customized functional-test suite/skill from a spec/README/help; not for
|
|
4
|
+
description: "Scaffold a repo-specific functional-test skill from spec — use when the user wants to generate a customized functional-test suite/skill from a spec/README/help; not for regular instance execution (use the generated instance-test skill) nor for TDD (use tdd-implement)"
|
|
5
5
|
---
|
|
6
6
|
|
|
7
7
|
# Scaffold Functional Test
|
|
8
8
|
|
|
9
|
-
|
|
9
|
+
从仓库 spec 生成仓库专属的功能测试 skill。它是一次性 scaffold，不负责常规实例执行，也不进入 TDD 红绿循环。
|
|
10
10
|
|
|
11
|
-
|
|
11
|
+
生成物：`.agents/skills/<repo>-functional-test/`，至少包含 `SKILL.md` 与 `references/instances.md`；可按需要包含 runner。实例字段、溯源、指纹和保护段统一遵循 [`references/schema.md`](references/schema.md)。生成物纳入 git，但不复制到 `template/`。
|
|
12
12
|
|
|
13
|
-
|
|
14
|
-
- 指纹：`spec hash` + `generatedAt` 写入生成物头部，用于后续执行前校验
|
|
15
|
-
- 保护：`<!-- manual -->` 标记段不被覆盖
|
|
13
|
+
## 流程
|
|
16
14
|
|
|
17
|
-
|
|
15
|
+
### ① 采集行为
|
|
18
16
|
|
|
19
|
-
|
|
17
|
+
读取用户指定的 spec，默认 `.scratch/<feature>/spec.md`；同时读取相关 `CONTEXT.md` 与 ADR。以 Acceptance Criteria 固定待覆盖行为清单。
|
|
20
18
|
|
|
21
|
-
|
|
19
|
+
spec 不存在时可从 README 与 `--help` 建立候选清单，但必须把它标为候选并进入下一步确认，不得把推断当成需求。
|
|
22
20
|
|
|
23
|
-
|
|
21
|
+
出口：行为清单的来源、范围和未覆盖项已明确。
|
|
24
22
|
|
|
25
|
-
|
|
26
|
-
- 若 spec 不存在：回退到 `README` + `--help` 输出倒推行为清单，但必须进入 Step ② 的清单确认关卡，不静默臆测。
|
|
23
|
+
### ② 推导并确认实例
|
|
27
24
|
|
|
28
|
-
|
|
25
|
+
按 [`references/schema.md`](references/schema.md) 为每个行为生成实例草案：每个实例必须有溯源，不能用无来源的隐含行为扩张范围。向用户展示实例清单并等待一次确认；确认前不落盘。
|
|
29
26
|
|
|
30
|
-
|
|
27
|
+
出口：实例清单已确认，每个实例字段完整且可追溯。
|
|
31
28
|
|
|
32
|
-
|
|
29
|
+
### ③ 生成或更新
|
|
33
30
|
|
|
34
|
-
|
|
35
|
-
- 每实例声明**受控扩展模型**：必选 `prompt/command/expected files/content/expected stdout phrases/expected exit code`，可选 `setup/env/timeout/type/teardown`，默认 `type: cli`。
|
|
36
|
-
- **强制门禁**：实例清单必须与用户确认后才进入 Step ③；无确认不落盘。
|
|
31
|
+
写入定制 skill 和实例 reference：
|
|
37
32
|
|
|
38
|
-
|
|
33
|
+
- 写入 spec 的 SHA-256 `spec hash` 与 ISO `generatedAt`；
|
|
34
|
+
- 保留 `<!-- manual -->` 保护段；
|
|
35
|
+
- 新建直接生成；更新已有生成物时先展示 diff，用户确认后才覆盖；
|
|
36
|
+
- 不把本次生成物写入 `template/`。
|
|
39
37
|
|
|
40
|
-
|
|
38
|
+
出口：文件结构、指纹和人工段均符合 schema。
|
|
41
39
|
|
|
42
|
-
|
|
40
|
+
### ④ 结构验证
|
|
43
41
|
|
|
44
|
-
|
|
45
|
-
- `references/instances.md`：实例集（含溯源、必选+可选字段、头部 `spec hash` + `generatedAt`）
|
|
46
|
-
- 不覆盖 `<!-- manual -->` 保护段；覆盖式更新需经用户确认；重生成时先给出 diff 建议，用户确认后才应用。
|
|
42
|
+
生成后立即做快速、确定性的结构验证：文件存在、schema 字段、实例溯源、spec hash、`generatedAt`、manual 段保护和内部链接均通过后再报告成功。不默认执行完整实例集，不启动服务，不产生功能测试副作用。
|
|
47
43
|
|
|
48
|
-
|
|
44
|
+
出口：结构验证结果为 `PASS`，失败则报告具体 gap，不回滚生成物。
|
|
49
45
|
|
|
50
|
-
|
|
46
|
+
## 可选行为验证
|
|
51
47
|
|
|
52
|
-
|
|
53
|
-
|
|
54
|
-
- `mktemp -d` 隔离（或项目支持的 `git worktree` / `--dest`），单线程串行，不并行。
|
|
55
|
-
- 每实例捕获 stdout/stderr 与 exit code，按 `test -f`/`grep -q`/`diff` 对比判定 `PASS`/`FAIL`，单 FAIL 不阻断后续。
|
|
56
|
-
- 对话内输出 `PASS m/n` + per-instance evidence（`expected vs actual diff` + `run dir`），失败不回滚生成物但给出 gap 供迭代 `regenerate`。
|
|
57
|
-
- 成功默认清理临时目录、失败默认保留（`--keep` 保留全部）；`--report` 显式开启才落盘报告文件。
|
|
58
|
-
|
|
59
|
-
完成：自验证已执行，对话内汇总完成，证据可复现。
|
|
60
|
-
|
|
61
|
-
## 执行语义（生成物复用）
|
|
62
|
-
|
|
63
|
-
生成物本身的执行语义与 `instance-test` 一致：`mktemp -d` 串行、`PASS m/n` 汇总、证据含 `expected vs actual diff` + `run dir`。执行前校验 `spec hash` 指纹：若当前 spec 已变更，提示「spec 已变更，建议重跑 scaffold-functional-test」但不自动覆盖，需用户显式确认才 regenerate。
|
|
48
|
+
仅当用户明确要求运行实例集时，才调用生成的功能测试 skill 执行隔离、串行的实例验证；届时按实例捕获 stdout/stderr、exit code 和 expected-vs-actual evidence，并由执行 skill 报告 `PASS m/n`。这不是 scaffold 的默认步骤。
|
|
64
49
|
|
|
65
50
|
## 不做什么
|
|
66
51
|
|
|
67
|
-
-
|
|
68
|
-
-
|
|
52
|
+
- 不替代生成后的功能测试 skill；
|
|
53
|
+
- 不替代 `tdd`、`tdd-implement` 或 `commit-check`；
|
|
54
|
+
- 不覆盖 `<!-- manual -->` 段，不静默重生成，不把 README/`--help` 推断写成无溯源实例。
|
|
69
55
|
|
|
70
56
|
## 引用
|
|
71
57
|
|
|
58
|
+
- 实例 schema：[`references/schema.md`](references/schema.md)
|
|
72
59
|
- 领域术语：`CONTEXT.md`
|
|
73
60
|
- 技能设计规则：`docs/agents/skill-design.md`
|
|
74
|
-
- 示范产物：`.agents/skills/instance-test
|
|
75
|
-
- Issue tracker：`docs/agents/issue-tracker.md`
|
|
61
|
+
- 示范产物：`.agents/skills/instance-test/`
|
|
@@ -0,0 +1,35 @@
|
|
|
1
|
+
# Functional-test instance schema
|
|
2
|
+
|
|
3
|
+
`scaffold-functional-test` 生成的实例清单以本文件为唯一字段契约。实例是声明式输入，不把执行逻辑散落在生成器正文中。
|
|
4
|
+
|
|
5
|
+
## Required fields
|
|
6
|
+
|
|
7
|
+
每个实例必须包含：
|
|
8
|
+
|
|
9
|
+
- `prompt`：实例要覆盖的用户行为；
|
|
10
|
+
- `command`：实际执行的命令或入口；
|
|
11
|
+
- `expected files/content`：预期文件、副作用或内容；无文件副作用时明确写 `none`；
|
|
12
|
+
- `expected stdout phrases`：预期 stdout/stderr 短语；无要求时明确写 `none`；
|
|
13
|
+
- `expected exit code`：预期退出码；
|
|
14
|
+
- `source`：spec 章节/行号，或 README / `--help` 的明确来源。
|
|
15
|
+
|
|
16
|
+
## Optional fields
|
|
17
|
+
|
|
18
|
+
可按实例需要增加：
|
|
19
|
+
|
|
20
|
+
- `setup`、`env`、`timeout`、`type`、`teardown`；
|
|
21
|
+
- `type` 缺省为 `cli`；
|
|
22
|
+
- 需要展示多个文件或短语时使用列表，不把不可验证的自然语言目标当作断言。
|
|
23
|
+
|
|
24
|
+
## Fingerprint
|
|
25
|
+
|
|
26
|
+
实例 reference 头部必须包含：
|
|
27
|
+
|
|
28
|
+
- `spec hash`：源 spec 文件字节的 SHA-256；
|
|
29
|
+
- `generatedAt`：生成时的 ISO 8601 时间戳。
|
|
30
|
+
|
|
31
|
+
执行或更新前发现 hash 不一致时，报告 spec 已变更并给出 regenerate 建议；未经用户确认不覆盖实例清单。
|
|
32
|
+
|
|
33
|
+
## Protected content
|
|
34
|
+
|
|
35
|
+
`<!-- manual -->` 与其保护段属于人工维护内容。更新生成物时保留原文；需要改变人工段时先展示 diff 并获得用户确认。
|
|
@@ -1,5 +1,28 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: show-me
|
|
3
|
-
description: Show the current
|
|
3
|
+
description: Show the current implementation or state for the user to review, using real observable evidence when an existing run entrypoint is available.
|
|
4
4
|
---
|
|
5
|
-
|
|
5
|
+
|
|
6
|
+
# Show Me
|
|
7
|
+
|
|
8
|
+
只读展示当前 implementation 或状态供用户 review。不要修改源码、测试或配置；不要为了演示臆造新的入口。
|
|
9
|
+
|
|
10
|
+
## Steps
|
|
11
|
+
|
|
12
|
+
1. **Identify**：查找项目已有的运行脚本、CLI、dev server、browser 入口或现有产物，选择最接近用户可观察行为的入口。
|
|
13
|
+
2. **Run**：优先实际运行并捕获可见结果；UI 使用已有 browser/Playwright 入口，CLI 使用已有命令。没有安全、明确的运行入口时，回退到 `git status`、相关 diff、静态配置或已有产物，并明确未完成真实运行验证。
|
|
14
|
+
3. **Report**：按以下固定格式在对话中汇报，不默认写报告文件：
|
|
15
|
+
|
|
16
|
+
```text
|
|
17
|
+
展示方式：
|
|
18
|
+
实际执行的命令/入口：
|
|
19
|
+
实际可见结果：
|
|
20
|
+
产物或 URL：
|
|
21
|
+
未验证项与限制：
|
|
22
|
+
```
|
|
23
|
+
|
|
24
|
+
需要启动临时进程或目录时使用项目已有的隔离和清理方式；展示结束后清理本次创建的资源。
|
|
25
|
+
|
|
26
|
+
## 出口
|
|
27
|
+
|
|
28
|
+
用户获得可复核的实际结果，或获得明确的静态证据与“未真实运行”的限制说明；不以“构建成功”或推测结果代替展示。
|
package/README.md
CHANGED
|
@@ -33,9 +33,9 @@ npx @heihei0299/matt-skills init # 默认编程相关 26（engineer
|
|
|
33
33
|
npx @heihei0299/matt-skills init --all # 安装全量 33（含 productivity）
|
|
34
34
|
```
|
|
35
35
|
|
|
36
|
-
`init`
|
|
36
|
+
`init` 默认只在目标没有 `AGENTS.md` 时初始化；已有项目默认跳过以保护定制，显式 `init --all` 会刷新模板并安装/覆盖全量 33 个 skill。模板全量 33，默认仅安装默认范围 26（engineering 18 + 独有所需 4 + 核心独有 4，见 config/engineering.json 与 config/required.json），无需二次拉取上游。
|
|
37
37
|
|
|
38
|
-
选项：`--dest <path>` 指定目标目录（默认当前目录）；`--all` 包含非编程技能（productivity，默认编程 26：engineering 18 + 独有所需 4 + 核心独有 4
|
|
38
|
+
选项：`--dest <path>` 指定目标目录（默认当前目录）；`--all` 包含非编程技能（productivity，默认编程 26：engineering 18 + 独有所需 4 + 核心独有 4）；已有目标使用 `init --all` 刷新，普通 `init` 跳过。
|
|
39
39
|
**增量同步（已有项目）**：已有项目更新到最新模板与技能：
|
|
40
40
|
|
|
41
41
|
```sh
|
package/bin/cli.js
CHANGED
|
@@ -66,6 +66,7 @@ Init options:
|
|
|
66
66
|
--dest <path> Target directory (default: current directory)
|
|
67
67
|
--all Include non-programming skills (productivity) and optional proprietary; default only core programming (engineering 18 + required 4 + default proprietary 4 → 26)
|
|
68
68
|
--help, -h Show this help
|
|
69
|
+
提示：已有 AGENTS.md 时普通 init 跳过；显式 init --all 刷新模板并覆盖全量 skills。
|
|
69
70
|
|
|
70
71
|
提示：matt-skills --help 查看全量
|
|
71
72
|
`;
|
|
@@ -283,7 +284,7 @@ async function initCommand({ dest, all }) {
|
|
|
283
284
|
const target = dest ? path.resolve(process.cwd(), dest) : process.cwd();
|
|
284
285
|
const marker = path.join(target, 'AGENTS.md');
|
|
285
286
|
const onlyProgramming = !all;
|
|
286
|
-
if (await pathExists(marker)) {
|
|
287
|
+
if (await pathExists(marker) && !all) {
|
|
287
288
|
process.stdout.write('模板已存在（AGENTS.md），跳过\n');
|
|
288
289
|
} else {
|
|
289
290
|
await cp(TEMPLATE_DIR, target, { recursive: true, force: true });
|
package/package.json
CHANGED
|
@@ -1,94 +1,50 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: ci-guard
|
|
3
|
-
description: "
|
|
3
|
+
description: "保护本仓库 GitHub Actions CI/release pipeline：按发布、workflow 维护或发布后故障场景执行必要门禁。Use when CI is flaky/failing, when setting up or editing .github/workflows/ci.yml, or before tagging a release to npm."
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# CI Guard
|
|
7
7
|
|
|
8
|
-
|
|
8
|
+
本 skill 只编排当前仓库的 CI 与 npm 发布门禁。先读取 `.github/workflows/ci.yml`，以实际 workflow 的 job、input、condition 和权限为事实源；不要假设不存在的 job、input 或自动回滚行为。产品代码 bug 的诊断和修复交给 `diagnose-fix`，不在此重复通用诊断。
|
|
9
9
|
|
|
10
|
-
##
|
|
10
|
+
## 场景选择
|
|
11
11
|
|
|
12
|
-
-
|
|
13
|
-
-
|
|
14
|
-
-
|
|
12
|
+
- 用户请求发布、打 release tag 或发布 npm → **发布路径**；
|
|
13
|
+
- 用户修改 workflow，或报告 Actions 红/偶发红 → **workflow 维护路径**；
|
|
14
|
+
- tag 已发布但 registry、release 或 post-check 异常 → **发布后故障路径**。
|
|
15
15
|
|
|
16
|
-
|
|
16
|
+
只执行命中的路径；普通发布不运行与当前 workflow 无关的 lint、dry-run 或 dispatch。
|
|
17
17
|
|
|
18
|
-
|
|
19
|
-
① 编排 flows → ② 预发布 gate → ③ 发布后自纠
|
|
20
|
-
```
|
|
18
|
+
## 发布路径
|
|
21
19
|
|
|
22
|
-
|
|
20
|
+
1. 读取当前 package metadata 和 workflow；确认正式 tag 的 commit 可从 `main` 到达，目标 tag 尚不存在，版本与 tag 约定一致。
|
|
21
|
+
2. 运行项目规定的测试和 `npm pack --dry-run`，确认发布内容和实际结果。
|
|
22
|
+
3. 只有前两步通过后才创建并推送 `vX.Y.Z` tag；不从非 `main` commit 推送正式 tag。
|
|
23
|
+
4. 等待 tag workflow 完成，确认 `verify` 成功后才进入 `publish`，并记录 Actions run URL、job 结论和实际 npm tag。
|
|
24
|
+
5. 使用 `npm view <package>@<version> version` 或 registry API 回读，确认发布版本真实可见。
|
|
23
25
|
|
|
24
|
-
|
|
25
|
-
|
|
26
|
-
### ① 编排 flows —— 让工作流不可被绕过
|
|
27
|
-
|
|
28
|
-
**做**：
|
|
29
|
-
- `on`：`push.tags: ["v*"]` **必须**同时配 `push.branches: [main]`（或 `master`）+ `pull_request.branches: [main]` + `workflow_dispatch`。否则直推 `main` 的修复（如 `2d68f62`）无法被 CI 验证，tag 才暴露问题
|
|
30
|
-
- `jobs` 依赖：`publish.needs: [build, verify]`，**禁止** `needs: build` 单依赖。门禁失效的直接原因就是 `verify` 红仍发包
|
|
31
|
-
- `permissions` 最小化：`verify`/`build` 只需 `contents: read`，仅 `publish` 保留 `contents: write` + `packages: write`（或 `id-token: write` 若用 OIDC）
|
|
32
|
-
- `concurrency`：`group: ci-${{ github.ref }}` + `cancel-in-progress: true`，避免同分支并行互踩
|
|
33
|
-
|
|
34
|
-
**完成条件**：
|
|
35
|
-
- [ ] `git diff HEAD -- .github/workflows/ci.yml` 显示 `on.push.branches` 存在
|
|
36
|
-
- [ ] `publish.needs` 包含 `verify`
|
|
37
|
-
- [ ] `workflow_dispatch` 可手动触发全量
|
|
38
|
-
|
|
39
|
-
---
|
|
40
|
-
|
|
41
|
-
### ② 预发布 gate —— 测试 GitHub Action 流程
|
|
42
|
-
|
|
43
|
-
本段是**硬门槛**，顺序固定：`action lint → workflow dry-run → dispatch 验证`，任一步红即阻断 `publish`。
|
|
44
|
-
|
|
45
|
-
**action lint**：
|
|
46
|
-
- `actionlint` 校验 `.github/workflows/ci.yml` 语法与 `on/needs/permissions` 完整性
|
|
47
|
-
- `yamllint` 检查缩进与重复键
|
|
26
|
+
出口：tag、Actions 和 registry 的实际结果均已记录；任一失败都阻断“发布成功”结论。
|
|
48
27
|
|
|
49
|
-
|
|
50
|
-
- `act --dry-run` 或 `gh workflow view` 模拟 `verify/build/publish` 三 job 依赖与 `if` 条件
|
|
51
|
-
- 校验 `publish.needs` 含 `verify` 且 `workflow_dispatch` 可手动触发
|
|
28
|
+
## Workflow 维护路径
|
|
52
29
|
|
|
53
|
-
|
|
54
|
-
|
|
55
|
-
-
|
|
30
|
+
1. 读取当前 workflow，按实际内容检查触发器、`publish.needs`、job `if`、权限和 concurrency；不硬编码 job 名称。
|
|
31
|
+
2. 只有 workflow 在本次范围内发生变化，或故障需要时，才运行已安装的 `actionlint` / `yamllint`；工具不可用就记录 `unavailable`，不得伪报通过。
|
|
32
|
+
3. 需要 dry-run 或手动 dispatch 时，只使用 workflow 已声明的 input；不得传入未声明的 `dry_run` 等参数。若无安全的 dry-run input，改用静态依赖检查或一次不发布的验证运行。
|
|
33
|
+
4. 失败时区分 workflow wiring、项目测试、授权/registry 和 runner 环境；只修复当前请求范围内的问题。
|
|
56
34
|
|
|
57
|
-
|
|
58
|
-
- [ ] `actionlint` 0 error
|
|
59
|
-
- [ ] `act --dry-run` 三 job 依赖正确
|
|
60
|
-
- [ ] `workflow_dispatch` 试运行通过
|
|
61
|
-
|
|
62
|
-
---
|
|
63
|
-
|
|
64
|
-
### ③ 发布后自纠 —— 发出去的包自己负责
|
|
65
|
-
|
|
66
|
-
**发布时**：
|
|
67
|
-
- `npm publish --access public` 仅在 `if: startsWith(github.ref, 'refs/tags/v')` 且 `needs` 全绿时执行
|
|
68
|
-
- 发布前 `actions/download-artifact` 校验 `if-no-files-found: error`，发布后 `npm view <pkg>@<version> version` 回读确认
|
|
69
|
-
|
|
70
|
-
**自纠**：
|
|
71
|
-
- 失败即 **阻断**：`verify` 红 → `publish` 不执行（由 `needs` 保证）；`publish` 自身失败（`409 already exists` / `401`）→ 工作流整体 `failure`，不静默
|
|
72
|
-
- 发布后 30s 内 `curl https://registry.npmjs.org/<pkg>/<version>` 校验可用；失败则 `gh issue create --title "chore(release): vX.Y.Z 发布后自检失败" --body "run: ${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}"` 并 `gh release delete vX.Y.Z --yes`（或 `npm unpublish <pkg>@<version>` 在 72h 内）
|
|
73
|
-
- `workflow_dispatch` 支持 `inputs.rollback_version` 手动回滚
|
|
74
|
-
|
|
75
|
-
**完成条件**：
|
|
76
|
-
- [ ] `npm view` 回读与 tag 一致
|
|
77
|
-
- [ ] 失败路径有 issue/通知（非静默）
|
|
78
|
-
- [ ] `git tag` 与 `package.json version` 一致（`scripts/release.sh` 或 `npm version` 保证）
|
|
79
|
-
|
|
80
|
-
---
|
|
35
|
+
出口：实际 workflow 结构、检查命令和运行结果均有证据；未验证项明确列出。
|
|
81
36
|
|
|
82
|
-
##
|
|
37
|
+
## 发布后故障路径
|
|
83
38
|
|
|
84
|
-
|
|
85
|
-
|
|
86
|
-
|
|
87
|
-
- **`-A clippy::all`**：掩盖真实告警
|
|
39
|
+
1. 读取对应 Actions run、npm registry 和 Git tag 的实际状态，确认是未发布、发布延迟、重复版本、授权失败还是 post-check 失败。
|
|
40
|
+
2. 创建或补充带 run URL 的 issue，记录 registry 查询结果和失败分类。
|
|
41
|
+
3. 只按照当前 workflow 声明的人工回滚步骤操作；不自行声称删除 release、删除 tag 或 `npm unpublish` 已发生。
|
|
88
42
|
|
|
89
|
-
|
|
43
|
+
出口：故障分类、保留的远端对象和人工下一步均已明确。
|
|
90
44
|
|
|
91
|
-
|
|
92
|
-
- 修复：`2d68f62 fix(ci): gate publish on verify and serialize Rust tests`
|
|
93
|
-
- 关联技能：`diagnose-fix`（通用诊断）、`commit-check`（提交前门禁）、`tdd`（测试隔离后的回归）
|
|
45
|
+
## 不做什么
|
|
94
46
|
|
|
47
|
+
- 不把每次发布都扩展为完整 CI 工具链演练；
|
|
48
|
+
- 不引用不存在的 `build` job、`dry_run` input 或 `rollback_version` input；
|
|
49
|
+
- 不把历史事故描述当成当前仓库事实；
|
|
50
|
+
- 不自动删除 tag/release，不静默吞掉 publish 或 post-check 失败。
|
|
@@ -5,61 +5,38 @@ description: "Complete diagnosis→fix→regression channel for bugs: diagnose,
|
|
|
5
5
|
|
|
6
6
|
# Diagnose Fix
|
|
7
7
|
|
|
8
|
-
|
|
8
|
+
本 skill 只连接诊断、TDD 修复和回归三个阶段。诊断细节以 [`diagnosing-bugs`](.agents/skills/diagnosing-bugs/SKILL.md) 为事实源，红绿语义以 [`tdd`](.agents/skills/tdd/SKILL.md) 为事实源；不复制两个上游的完整步骤。
|
|
9
9
|
|
|
10
|
-
|
|
10
|
+
## 流程
|
|
11
11
|
|
|
12
|
-
|
|
12
|
+
### ① 诊断
|
|
13
13
|
|
|
14
|
-
|
|
15
|
-
① 诊断 → ② TDD 修复（硬门槛）→ ③ 回归验证
|
|
16
|
-
```
|
|
14
|
+
委托 `diagnosing-bugs` 完成 Phase 1–4：建立能捕捉用户症状的 tight feedback loop，实际复现并最小化，再形成可证伪的假设并按单变量探针验证。
|
|
17
15
|
|
|
18
|
-
|
|
16
|
+
出口：反馈回路已实际变红，且最小复现已确认；此阶段不写修复代码。
|
|
19
17
|
|
|
20
|
-
|
|
18
|
+
### ② TDD 修复
|
|
21
19
|
|
|
22
|
-
1.
|
|
23
|
-
2.
|
|
24
|
-
3.
|
|
25
|
-
4. **探针**（Phase 4）：一次只改一个变量，临时探针用 `[DEBUG-...]` 前缀标记。
|
|
20
|
+
1. 在正确的公共 seam 上提出回归测试边界，并遵循 `tdd` 要求获得用户确认；只确认本次 seam，不建立重型 seam ledger。
|
|
21
|
+
2. 加载 `tdd`，先把最小复现转成失败回归测试并实际看到 Red。
|
|
22
|
+
3. 只写让该测试 Green 的最小修复，并遵循 `tdd` 的红绿循环。
|
|
26
23
|
|
|
27
|
-
|
|
24
|
+
**硬门槛：**不存在已实际观察到的失败回归测试时，不得写任何修复代码。不存在正确 seam 时，本身就是 finding；记录架构阻塞，不绕过测试直接修改。
|
|
28
25
|
|
|
29
|
-
|
|
26
|
+
出口：回归测试先 Red，最小修复后 Green；不进入 `tdd-implement` 的长流程。
|
|
30
27
|
|
|
31
|
-
|
|
28
|
+
### ③ 回归收尾
|
|
32
29
|
|
|
33
|
-
|
|
30
|
+
按 `diagnosing-bugs` 的收尾要求重跑阶段 ① 的原始、未最小化反馈回路，确认用户症状消失；清理 `[DEBUG-...]` 探针和一次性 harness，并记录最终验证的假设。
|
|
34
31
|
|
|
35
|
-
|
|
36
|
-
- **轻量声明**：本技能不套用 tdd-implement 的重流程——不做逐 todo 的循环编排、不设 seams 确认步骤、无 typecheck/commit 前置门禁；单 seam 修复场景直走红-绿。
|
|
37
|
-
**出口条件**：回归测试先红 → 写最小修复 → 回归测试变绿。
|
|
32
|
+
出口：原始症状消失、回归测试 Green、临时诊断产物已清理。
|
|
38
33
|
|
|
39
|
-
##
|
|
34
|
+
## 回合连续性
|
|
40
35
|
|
|
41
|
-
|
|
42
|
-
2. 清理：删除所有 `[DEBUG-...]` 标记的临时探针与一次性 harness（`grep` 前缀确认无残留）。
|
|
43
|
-
3. 在 commit / PR 消息中写明**验证正确的假设**（诊断阶段哪个假设被证实），让下一个调试者受益。
|
|
44
|
-
|
|
45
|
-
**出口条件**：原始症状消失 + 回归测试绿 + 临时探针清理完成。
|
|
46
|
-
|
|
47
|
-
## 反模式（不做什么）
|
|
48
|
-
|
|
49
|
-
完整反模式清单见 [references/anti-patterns.md](references/anti-patterns.md)——正文各阶段规则是正面约束，反模式清单是负向边界；细节只在一处存在，本文件不重复。
|
|
50
|
-
|
|
51
|
-
## 回合连续性规则
|
|
52
|
-
|
|
53
|
-
诊断 → 修复 → 回归**在一个回合内串行完成**，不等用户"继续"：构建回路 → 复现 → 假设 → 探针 → 失败测试 → 修复 → 回归 → 清理整条链一气呵成，中途不停顿。
|
|
54
|
-
|
|
55
|
-
输出只允许发生在以下三种情况：
|
|
56
|
-
- **合规交互点**：技能要求的用户确认——阶段①假设清单展示、阶段②无 seam finding 上报或 seam 决策请求
|
|
57
|
-
- **外部阻塞**：权限拒绝、缺失授权、依赖不可用——明确说明所需授权或替代路径，不静默停止
|
|
58
|
-
- **阶段出口**：整个阶段的出口条件满足（阶段①回路已红 + 复现最小化；阶段②失败测试已红 → 修复变绿；阶段③症状消失 + 回归绿 + 清理完成）
|
|
59
|
-
|
|
60
|
-
预告下一步后立即执行该步骤，回合终点仅为合规交互点、外部阻塞或阶段出口条件满足。进度输出本身不结束回合——输出后继续执行，直到三类终点之一达成。
|
|
36
|
+
诊断 → seam 确认 → Red → 修复 → Green → 原始回路 → 清理在一个回合内连续推进。只在用户必须确认 seam、发现无 seam finding、外部环境阻塞或整个阶段出口时暂停；预告下一步后立即执行。
|
|
61
37
|
|
|
62
38
|
## 引用
|
|
63
39
|
|
|
64
|
-
- 诊断：[diagnosing-bugs](.agents/skills/diagnosing-bugs/SKILL.md)
|
|
65
|
-
-
|
|
40
|
+
- 诊断：[`diagnosing-bugs`](.agents/skills/diagnosing-bugs/SKILL.md)
|
|
41
|
+
- 修复：[`tdd`](.agents/skills/tdd/SKILL.md)
|
|
42
|
+
- 负向边界：[`references/anti-patterns.md`](references/anti-patterns.md)
|
|
@@ -6,75 +6,38 @@ disable-model-invocation: true
|
|
|
6
6
|
|
|
7
7
|
# Grill to Spec
|
|
8
8
|
|
|
9
|
-
|
|
10
|
-
|
|
11
|
-
## 职责
|
|
12
|
-
|
|
13
|
-
| 做 | 不做 |
|
|
14
|
-
|----|------|
|
|
15
|
-
| 编排 `grill-with-docs` → `to-spec` 完整通道 | 不编写代码、不修改任何源码（含测试） |
|
|
16
|
-
| 引导用户从模糊想法 → 结构化 spec | 不拆 tickets（`/to-tickets` 职责） |
|
|
17
|
-
| grilling 逐问挑战、打磨设计 | 不调用 `/code-review` |
|
|
18
|
-
| 同步产出领域文档（glossary inline；ADR 草稿经用户确认后落盘） | 阶段②仅综合，不新增采访 |
|
|
19
|
-
| 综合对话为可执行的 spec 文档并发布 | 不维护已发布的 spec |
|
|
20
|
-
| 产出物仅限领域文档与 spec | 实现与修复交给实现类 skill（如 `/tdd-implement`） |
|
|
9
|
+
只做两个上游 skill 的编排：先把想法打磨成共识，再把共识发布成 spec。本 skill 不写代码、不修改源码或测试。
|
|
21
10
|
|
|
22
11
|
## 流程
|
|
23
12
|
|
|
24
|
-
|
|
25
|
-
① Grill with docs → ② Synthesize to spec
|
|
26
|
-
```
|
|
27
|
-
|
|
28
|
-
① 加载 `/grill-with-docs`：grilling 采访（一次一问、等反馈；决策逐条交由用户定夺）+ domain-modeling 产出 glossary/ADR。出口：用户确认共识达成。
|
|
29
|
-
|
|
30
|
-
① 内 ADR 子流转（与 glossary 的 inline 更新严格区分）：
|
|
31
|
-
1. 触发：仅当 domain-modeling 三条件全满足（难逆转 / 无上下文费解 / 真实权衡）才提议 ADR
|
|
32
|
-
2. 草稿：按 ADR-FORMAT 把完整标题+正文展示给用户审阅，等待反馈
|
|
33
|
-
3. 确认：用户显式说「确认/写入」才落盘；用户拒绝则不写、继续访谈；用户要求修改则改草稿重新确认
|
|
34
|
-
4. 未确认前不得创建或写入 `docs/adr/` 下的任何文件
|
|
35
|
-
|
|
36
|
-
② 加载 `/to-spec`：探索代码（glossary 词汇贯穿 spec、尊重相关 ADR）→ 确认 seams（既有优先、最高 seam、理想一个）→ 编写 spec 草稿 → 展示给用户确认（只展示等决定，不新增采访提问）→ 发布到 `.scratch/<feature-slug>/spec.md` 并标 `ready-for-agent`。出口：spec 已发布。
|
|
37
|
-
|
|
38
|
-
## 产出物（格式严格对齐下游技能）
|
|
39
|
-
|
|
40
|
-
本技能产出物仅以下三种，格式以各技能文件为唯一事实源，不在本技能重写：
|
|
41
|
-
|
|
42
|
-
| 产出物 | 位置 | 格式来源 |
|
|
43
|
-
|--------|------|----------|
|
|
44
|
-
| Glossary | `CONTEXT.md`（多上下文：`CONTEXT-MAP.md` + 各上下文 `CONTEXT.md`） | [CONTEXT-FORMAT.md](.agents/skills/domain-modeling/CONTEXT-FORMAT.md) |
|
|
45
|
-
| ADR | `docs/adr/NNNN-slug.md`（多上下文：系统级在根，上下文级在 `src/<ctx>/docs/adr/`） | [ADR-FORMAT.md](.agents/skills/domain-modeling/ADR-FORMAT.md) |
|
|
46
|
-
| Spec | 发布到 issue tracker：`.scratch/<feature-slug>/spec.md` | [to-spec 七节模板](.agents/skills/to-spec/SKILL.md) |
|
|
13
|
+
### ① 形成共识
|
|
47
14
|
|
|
48
|
-
|
|
15
|
+
调用 [`grill-with-docs`](.agents/skills/grill-with-docs/SKILL.md)，由 `grilling` 与 `domain-modeling` 完成采访、术语和设计决策。
|
|
49
16
|
|
|
50
|
-
|
|
17
|
+
- glossary 按上游规则 inline 更新；
|
|
18
|
+
- 只有确需 ADR 时才创建 ADR 草稿；
|
|
19
|
+
- ADR 必须先展示完整草稿，用户明确确认后才写入，未确认不得落盘。
|
|
51
20
|
|
|
52
|
-
|
|
53
|
-
- **ADR 与 glossary 不对称**：`CONTEXT.md` 术语可随访谈 inline 更新（domain-modeling 规则），ADR 必须先审草稿、用户确认后才落盘——禁止把 inline 逻辑套用到 ADR
|
|
21
|
+
出口：用户确认共识已达成，且所有 ADR 草稿都已获得单独确认或明确不写入。
|
|
54
22
|
|
|
55
|
-
|
|
23
|
+
### ② 发布 spec
|
|
56
24
|
|
|
57
|
-
|
|
58
|
-
|--------|------|------|
|
|
59
|
-
| ② seam 确认 | 用户不同意 seams | → ① 补充 |
|
|
60
|
-
| ② 发布后 | spec 有问题 | → ① 重新循环 |
|
|
25
|
+
将已确认的共识交给 [`to-spec`](.agents/skills/to-spec/SKILL.md)，完成代码库理解、seam 提案和 spec 组装。
|
|
61
26
|
|
|
62
|
-
|
|
27
|
+
- 将 seam 提案并入最终 spec 草稿，不单独制造一次重复确认；
|
|
28
|
+
- 发布前展示完整 spec 草稿，用户一次明确确认后才写入 `.scratch/<feature-slug>/spec.md`；
|
|
29
|
+
- 发布时使用 `ready-for-agent`，格式细则只读取 [`references/rules.md`](references/rules.md)。
|
|
63
30
|
|
|
64
|
-
|
|
65
|
-
|------|------|
|
|
66
|
-
| 用户中途放弃 / 无主题 | 终止 |
|
|
67
|
-
| tracker 未配置 | 提示 `/setup-matt-pocock-skills`，终止 |
|
|
68
|
-
| ① 超过 5 轮无进展 | 建议暂停或缩小范围 |
|
|
31
|
+
出口：spec 已发布，路径、状态和未纳入范围已报告。
|
|
69
32
|
|
|
70
|
-
##
|
|
33
|
+
## 本 skill 独有门禁
|
|
71
34
|
|
|
72
|
-
-
|
|
73
|
-
-
|
|
35
|
+
- ADR：草稿 → 用户确认 → 落盘，任何情况不例外；
|
|
36
|
+
- spec：共识与 seam 合并为一个最终草稿，只设置一次发布前确认；
|
|
37
|
+
- 全程不写代码、不修改测试、不执行实现。
|
|
74
38
|
|
|
75
|
-
##
|
|
39
|
+
## 异常
|
|
76
40
|
|
|
77
|
-
-
|
|
78
|
-
-
|
|
79
|
-
-
|
|
80
|
-
- [to-spec](.agents/skills/to-spec/SKILL.md)
|
|
41
|
+
- 用户放弃或没有可形成 spec 的主题时终止；
|
|
42
|
+
- issue tracker 未配置时报告配置阻塞，不绕过发布；
|
|
43
|
+
- 用户改变已确认的设计时回到 ①，不在 ② 静默扩大范围。
|
|
@@ -1,75 +1,61 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: scaffold-functional-test
|
|
3
3
|
disable-model-invocation: false
|
|
4
|
-
description: "Scaffold a repo-specific functional-test skill from spec — use when the user wants to generate a customized functional-test suite/skill from a spec/README/help; not for
|
|
4
|
+
description: "Scaffold a repo-specific functional-test skill from spec — use when the user wants to generate a customized functional-test suite/skill from a spec/README/help; not for regular instance execution (use the generated instance-test skill) nor for TDD (use tdd-implement)"
|
|
5
5
|
---
|
|
6
6
|
|
|
7
7
|
# Scaffold Functional Test
|
|
8
8
|
|
|
9
|
-
|
|
9
|
+
从仓库 spec 生成仓库专属的功能测试 skill。它是一次性 scaffold，不负责常规实例执行，也不进入 TDD 红绿循环。
|
|
10
10
|
|
|
11
|
-
|
|
11
|
+
生成物：`.agents/skills/<repo>-functional-test/`，至少包含 `SKILL.md` 与 `references/instances.md`；可按需要包含 runner。实例字段、溯源、指纹和保护段统一遵循 [`references/schema.md`](references/schema.md)。生成物纳入 git，但不复制到 `template/`。
|
|
12
12
|
|
|
13
|
-
|
|
14
|
-
- 指纹：`spec hash` + `generatedAt` 写入生成物头部，用于后续执行前校验
|
|
15
|
-
- 保护：`<!-- manual -->` 标记段不被覆盖
|
|
13
|
+
## 流程
|
|
16
14
|
|
|
17
|
-
|
|
15
|
+
### ① 采集行为
|
|
18
16
|
|
|
19
|
-
|
|
17
|
+
读取用户指定的 spec，默认 `.scratch/<feature>/spec.md`；同时读取相关 `CONTEXT.md` 与 ADR。以 Acceptance Criteria 固定待覆盖行为清单。
|
|
20
18
|
|
|
21
|
-
|
|
19
|
+
spec 不存在时可从 README 与 `--help` 建立候选清单，但必须把它标为候选并进入下一步确认，不得把推断当成需求。
|
|
22
20
|
|
|
23
|
-
|
|
21
|
+
出口：行为清单的来源、范围和未覆盖项已明确。
|
|
24
22
|
|
|
25
|
-
|
|
26
|
-
- 若 spec 不存在：回退到 `README` + `--help` 输出倒推行为清单，但必须进入 Step ② 的清单确认关卡，不静默臆测。
|
|
23
|
+
### ② 推导并确认实例
|
|
27
24
|
|
|
28
|
-
|
|
25
|
+
按 [`references/schema.md`](references/schema.md) 为每个行为生成实例草案：每个实例必须有溯源，不能用无来源的隐含行为扩张范围。向用户展示实例清单并等待一次确认；确认前不落盘。
|
|
29
26
|
|
|
30
|
-
|
|
27
|
+
出口：实例清单已确认，每个实例字段完整且可追溯。
|
|
31
28
|
|
|
32
|
-
|
|
29
|
+
### ③ 生成或更新
|
|
33
30
|
|
|
34
|
-
|
|
35
|
-
- 每实例声明**受控扩展模型**：必选 `prompt/command/expected files/content/expected stdout phrases/expected exit code`，可选 `setup/env/timeout/type/teardown`，默认 `type: cli`。
|
|
36
|
-
- **强制门禁**：实例清单必须与用户确认后才进入 Step ③；无确认不落盘。
|
|
31
|
+
写入定制 skill 和实例 reference：
|
|
37
32
|
|
|
38
|
-
|
|
33
|
+
- 写入 spec 的 SHA-256 `spec hash` 与 ISO `generatedAt`；
|
|
34
|
+
- 保留 `<!-- manual -->` 保护段；
|
|
35
|
+
- 新建直接生成；更新已有生成物时先展示 diff，用户确认后才覆盖；
|
|
36
|
+
- 不把本次生成物写入 `template/`。
|
|
39
37
|
|
|
40
|
-
|
|
38
|
+
出口：文件结构、指纹和人工段均符合 schema。
|
|
41
39
|
|
|
42
|
-
|
|
40
|
+
### ④ 结构验证
|
|
43
41
|
|
|
44
|
-
|
|
45
|
-
- `references/instances.md`：实例集（含溯源、必选+可选字段、头部 `spec hash` + `generatedAt`）
|
|
46
|
-
- 不覆盖 `<!-- manual -->` 保护段；覆盖式更新需经用户确认；重生成时先给出 diff 建议，用户确认后才应用。
|
|
42
|
+
生成后立即做快速、确定性的结构验证：文件存在、schema 字段、实例溯源、spec hash、`generatedAt`、manual 段保护和内部链接均通过后再报告成功。不默认执行完整实例集，不启动服务，不产生功能测试副作用。
|
|
47
43
|
|
|
48
|
-
|
|
44
|
+
出口：结构验证结果为 `PASS`，失败则报告具体 gap，不回滚生成物。
|
|
49
45
|
|
|
50
|
-
|
|
46
|
+
## 可选行为验证
|
|
51
47
|
|
|
52
|
-
|
|
53
|
-
|
|
54
|
-
- `mktemp -d` 隔离（或项目支持的 `git worktree` / `--dest`），单线程串行，不并行。
|
|
55
|
-
- 每实例捕获 stdout/stderr 与 exit code，按 `test -f`/`grep -q`/`diff` 对比判定 `PASS`/`FAIL`，单 FAIL 不阻断后续。
|
|
56
|
-
- 对话内输出 `PASS m/n` + per-instance evidence（`expected vs actual diff` + `run dir`），失败不回滚生成物但给出 gap 供迭代 `regenerate`。
|
|
57
|
-
- 成功默认清理临时目录、失败默认保留（`--keep` 保留全部）；`--report` 显式开启才落盘报告文件。
|
|
58
|
-
|
|
59
|
-
完成：自验证已执行，对话内汇总完成，证据可复现。
|
|
60
|
-
|
|
61
|
-
## 执行语义（生成物复用）
|
|
62
|
-
|
|
63
|
-
生成物本身的执行语义与 `instance-test` 一致：`mktemp -d` 串行、`PASS m/n` 汇总、证据含 `expected vs actual diff` + `run dir`。执行前校验 `spec hash` 指纹：若当前 spec 已变更，提示「spec 已变更，建议重跑 scaffold-functional-test」但不自动覆盖，需用户显式确认才 regenerate。
|
|
48
|
+
仅当用户明确要求运行实例集时，才调用生成的功能测试 skill 执行隔离、串行的实例验证；届时按实例捕获 stdout/stderr、exit code 和 expected-vs-actual evidence，并由执行 skill 报告 `PASS m/n`。这不是 scaffold 的默认步骤。
|
|
64
49
|
|
|
65
50
|
## 不做什么
|
|
66
51
|
|
|
67
|
-
-
|
|
68
|
-
-
|
|
52
|
+
- 不替代生成后的功能测试 skill；
|
|
53
|
+
- 不替代 `tdd`、`tdd-implement` 或 `commit-check`；
|
|
54
|
+
- 不覆盖 `<!-- manual -->` 段，不静默重生成，不把 README/`--help` 推断写成无溯源实例。
|
|
69
55
|
|
|
70
56
|
## 引用
|
|
71
57
|
|
|
58
|
+
- 实例 schema：[`references/schema.md`](references/schema.md)
|
|
72
59
|
- 领域术语：`CONTEXT.md`
|
|
73
60
|
- 技能设计规则：`docs/agents/skill-design.md`
|
|
74
|
-
- 示范产物：`.agents/skills/instance-test
|
|
75
|
-
- Issue tracker：`docs/agents/issue-tracker.md`
|
|
61
|
+
- 示范产物：`.agents/skills/instance-test/`
|
|
@@ -0,0 +1,35 @@
|
|
|
1
|
+
# Functional-test instance schema
|
|
2
|
+
|
|
3
|
+
`scaffold-functional-test` 生成的实例清单以本文件为唯一字段契约。实例是声明式输入，不把执行逻辑散落在生成器正文中。
|
|
4
|
+
|
|
5
|
+
## Required fields
|
|
6
|
+
|
|
7
|
+
每个实例必须包含：
|
|
8
|
+
|
|
9
|
+
- `prompt`：实例要覆盖的用户行为；
|
|
10
|
+
- `command`：实际执行的命令或入口；
|
|
11
|
+
- `expected files/content`：预期文件、副作用或内容；无文件副作用时明确写 `none`；
|
|
12
|
+
- `expected stdout phrases`：预期 stdout/stderr 短语；无要求时明确写 `none`；
|
|
13
|
+
- `expected exit code`：预期退出码；
|
|
14
|
+
- `source`：spec 章节/行号，或 README / `--help` 的明确来源。
|
|
15
|
+
|
|
16
|
+
## Optional fields
|
|
17
|
+
|
|
18
|
+
可按实例需要增加：
|
|
19
|
+
|
|
20
|
+
- `setup`、`env`、`timeout`、`type`、`teardown`；
|
|
21
|
+
- `type` 缺省为 `cli`；
|
|
22
|
+
- 需要展示多个文件或短语时使用列表，不把不可验证的自然语言目标当作断言。
|
|
23
|
+
|
|
24
|
+
## Fingerprint
|
|
25
|
+
|
|
26
|
+
实例 reference 头部必须包含：
|
|
27
|
+
|
|
28
|
+
- `spec hash`：源 spec 文件字节的 SHA-256；
|
|
29
|
+
- `generatedAt`：生成时的 ISO 8601 时间戳。
|
|
30
|
+
|
|
31
|
+
执行或更新前发现 hash 不一致时，报告 spec 已变更并给出 regenerate 建议；未经用户确认不覆盖实例清单。
|
|
32
|
+
|
|
33
|
+
## Protected content
|
|
34
|
+
|
|
35
|
+
`<!-- manual -->` 与其保护段属于人工维护内容。更新生成物时保留原文；需要改变人工段时先展示 diff 并获得用户确认。
|
|
@@ -1,5 +1,28 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: show-me
|
|
3
|
-
description: Show the current
|
|
3
|
+
description: Show the current implementation or state for the user to review, using real observable evidence when an existing run entrypoint is available.
|
|
4
4
|
---
|
|
5
|
-
|
|
5
|
+
|
|
6
|
+
# Show Me
|
|
7
|
+
|
|
8
|
+
只读展示当前 implementation 或状态供用户 review。不要修改源码、测试或配置；不要为了演示臆造新的入口。
|
|
9
|
+
|
|
10
|
+
## Steps
|
|
11
|
+
|
|
12
|
+
1. **Identify**：查找项目已有的运行脚本、CLI、dev server、browser 入口或现有产物，选择最接近用户可观察行为的入口。
|
|
13
|
+
2. **Run**：优先实际运行并捕获可见结果；UI 使用已有 browser/Playwright 入口，CLI 使用已有命令。没有安全、明确的运行入口时，回退到 `git status`、相关 diff、静态配置或已有产物，并明确未完成真实运行验证。
|
|
14
|
+
3. **Report**：按以下固定格式在对话中汇报，不默认写报告文件：
|
|
15
|
+
|
|
16
|
+
```text
|
|
17
|
+
展示方式：
|
|
18
|
+
实际执行的命令/入口：
|
|
19
|
+
实际可见结果：
|
|
20
|
+
产物或 URL：
|
|
21
|
+
未验证项与限制：
|
|
22
|
+
```
|
|
23
|
+
|
|
24
|
+
需要启动临时进程或目录时使用项目已有的隔离和清理方式；展示结束后清理本次创建的资源。
|
|
25
|
+
|
|
26
|
+
## 出口
|
|
27
|
+
|
|
28
|
+
用户获得可复核的实际结果，或获得明确的静态证据与“未真实运行”的限制说明；不以“构建成功”或推测结果代替展示。
|