Capability Map: [Initiative Name]

Module id	Responsibility	Depends on
identity	Accounts, sessions, SSO	—
billing	Plans, invoices, payments	identity
notifications	Email and webhook fan-out	identity
reporting	Usage dashboards	billing, notifications

Build order: identity → billing, notifications → reporting

把简报的五条约束翻译成这张表:

- 简报第 5–6 行(登录、SSO、账户管理)→ `identity` 模块,无上游依赖,是拓扑序起点;
- 约束"billing depends on account data"→ `billing` 依赖 `identity`;
- 约束"notifications fire on billing and account events"→ `notifications` 依赖 `identity`(事件源包含账户事件;技能示例中将其依赖记为 `identity`,而仪表盘的"通知投递记录"依赖则挂在 `reporting` 一侧);
- 约束"dashboard reads from billing and notification delivery records"→ `reporting` 同时依赖 `billing` 与 `notifications`,因此它必须排在构建顺序的末端;
- 约束"finance wants to sign off on billing without waiting for the dashboard"→ 由单向依赖保证:`billing` 不依赖 `reporting`,财务可以在仪表盘动工前完成计费签核,这正是拓扑构建顺序带来的组织收益。

技能对地图本身还有三条硬性纪律,与简报的组织约束一一对应:

1. **稳定模块 id**(kebab-case,一次选定、 initiative 期间不改名)——`identity`、`billing`、`notifications`、`reporting` 将作为后续规格、计划和下游命令引用工作的索引;
2. **依赖方向单向、无环**——"如果两个模块互相需要,那它们本就是一个模块"。简报中没有任何两条约束构成环,因此四个模块的划分是自洽的;
3. **接口契约位于边界,且归属提供方**——例如 `billing` 对 `identity` 的依赖,其契约写在 `identity` 的规格里,而不是写在消费方。

构建顺序 `identity → billing, notifications → reporting` 同时是评审顺序:平台团队先评审 `identity` 规格,财务随后即可评审 `billing` 规格,增长团队评审 `notifications` 与 `reporting`——四个 reviewer 的并行窗口由依赖图自然切出。

## 门控审批与按模块递归:地图批准前不得写任何规格

能力地图与其他阶段一样被门控:**任何模块规格动笔之前,人类必须先评审模块边界、依赖方向与构建顺序**。技能对此的论证是"地图错了代价很高,评审十行代价极低"([SKILL.md](https://gitcode.com/GitHub_Trending/agentskill/agent-skills/blob/020ec10a788f5703108d093a4bd3d9a7c3847d36/skills/spec-driven-development/SKILL.md?utm_source=gitcode_repo_files#L63))。

地图获批后,流程按模块递归执行 `Specify → Plan → Tasks → Implement`,顺序遵循依赖拓扑:

- 每个模块拥有独立规格,只覆盖该模块的目标、边界与成功标准;
- 获批的地图保存在项目根目录,每个模块的规格与其并列存放,以模块 id 命名:`SPEC-identity.md`、`SPEC-billing.md` 等——"地图,而不是文件名猜测,才是现有什么的索引"(见 [SKILL.md](https://gitcode.com/GitHub_Trending/agentskill/agent-skills/blob/020ec10a788f5703108d093a4bd3d9a7c3847d36/skills/spec-driven-development/SKILL.md?utm_source=gitcode_repo_files#L65));
- 每个模块规格必须能追溯到获批地图中的某个模块 id,而不是把整个 initiative 重新复述一遍。

这份"按模块限定范围"的要求直接体现在评估的期望断言里(下文详述)。

## 评估如何验证:五条 expectations 与执行机制

[评估用例](https://gitcode.com/GitHub_Trending/agentskill/agent-skills/blob/020ec10a788f5703108d093a4bd3d9a7c3847d36/evals/cases/spec-driven-development.json?utm_source=gitcode_repo_files#L56-L70) 的 eval id 2 声明了五条例行验证的期望,构成对分解产物的完整验收面:

1. 在写任何完整规格之前,先提出带模块 id 与依赖关系的能力地图;
2. 依赖方向单向(无环),并驱动所提出的构建顺序;
3. 在起草各模块规格之前请求对地图的审批;
4. 产出的任何模块规格都限定在单个模块内,而不是复述整个 initiative;
5. 不写任何实现代码。

这五条断言逐条对应简报中的证据:地图先行与单向依赖来自五条约束;审批门控来自"不同评审方分治"的约束;模块范围限定来自"finance 不想等 dashboard";无代码则由技能总原则"写规格前不写代码"约束。

执行链路在 [scripts/run-evals.js](https://gitcode.com/GitHub_Trending/agentskill/agent-skills/blob/020ec10a788f5703108d093a4bd3d9a7c3847d36/scripts/run-evals.js?utm_source=gitcode_repo_files) 中是确定性的:

- `materializeWorkspace` 把 `evals/fixtures/spec-driven-development-decomposition/` 下的简报物化到一次性 git 工作区并作为基线提交,Agent 因此可以真实地 `Read` 这份文件、把能力地图与 `SPEC-*.md` 写入仓库、查看 diff;
- 执行器以 `--permission-mode acceptEdits` 加预批工具列表运行,把完整技能文本通过 `--append-system-prompt` 注入,捕获 `stream-json` 全量执行轨迹;
- 评分器把轨迹作为不可信数据围栏包裹,按 `expectations[]` 逐条判定,输出 JSON 形状的 `grading.json` 写入 `evals/results/`(gitignored)。

运行方式(见 [evals/README.md](https://gitcode.com/GitHub_Trending/agentskill/agent-skills/blob/020ec10a788f5703108d093a4bd3d9a7c3847d36/evals/README.md?utm_source=gitcode_repo_files)):

```bash
# Tier 2 — 确定性检查,可在 CI 运行,验证夹具存在性与触发路由
node scripts/run-evals.js

# Tier 3 — 行为评估,在一次性工作区跑完整个评估再评分(消耗 tokens)
node scripts/run-evals.js --behavioral spec-driven-development
node scripts/run-evals.js --behavioral spec-driven-development --dry-run