frame-change

Frame Change

通过对话而非代码，将原始想法转化为达成共识的方案。明确待解决的问题后，相信产品判断；不要把访谈安排成按部就班的行程。

**所处阶段：**第一阶段。Tier 0 进入 test-first；Tier 1 进入 specify-behavior 中的迷你规格说明；Tier 2 完整走完三元流程。不要提前加载下游清单。对已发布、已有规格说明的功能进行小幅范围内修改，属于 amend-feature——将其交给该流程。

在运行此清单并明确说出仪式等级之前，不得编写任何代码、搭建任何框架，也不得调用任何实现技能。Tier 0 唯一允许的退出路径是 `test-first`，且只能在说出等级之后；Tier ≥1 则必须先编写并获批需求。此技能唯一可以修改的产物是笔记、术语表（CONTEXT.md）、ADR、路线图（`docs/roadmap/INDEX.md`，且只能在步骤 5 通过 `plan-milestones` 修改），以及通过其子技能产生的研究笔记、明确标记为一次性用途的运行验证，以及反向功能覆盖层。此规定适用于每一项请求，无论它看起来多么简单。

想法	实际情况
“这只是一行改动，设计它纯属多余”	判定它属于 Tier 0 本身就是设计步骤。说清楚，然后继续。
“我先写点代码理清思路”	这就是运行验证。必需的子技能：使用 run-spike，确保按约定将其作为一次性产物。
“搭个框架不算真正的实现”	仓库骨架属于技术栈决策，也属于实现。
“其他子功能不在范围内，所以算是范围外”	“范围外”用于记录拒绝事项。打算以后处理的工作应通过 plan-milestones 延后。
“我直接调用一下 /map-features”	/map-features 由用户调用——只需提及它。
“INDEX 很短——把全部 120 行都贴上”	目录采用先查询的方式；catalog-query.md 是唯一归档位置。

清单

先列待办——门槛要求。 在阅读 CONTEXT.md 或提问之前，将此技能的六个步骤列入醒目的清单（使用 harness 待办工具；否则在首条回复中列出清单）。下游阶段自行管理各自的清单。只有满足每一步的完成条件后，才将其勾选。

把握合适的规模。 步骤 1 之后：明确属于 Tier 0（拼写错误、重新着色、文案调整、不改变行为、不含未经确认的假设）→ 简要执行步骤 2，跳过步骤 3–4，然后执行步骤 5。其他情况 → 走完整流程。如果步骤 2 发现会改变行为，则升级处理。

1. 探索项目上下文

阅读 CONTEXT.md。不要将 docs/specs/INDEX.md 粘贴到上下文中。加载 load-subgraph 的 catalog-query.md 并运行它（模式、查询配方、上下文上限、精确 CODE 查找），包括任何有效的 OBS。

存在时，阅读 docs/agents/project.md 中的 Project posture。当存在 Project posture 或 ## Team 时，阅读本文件旁的 project-posture.md 并严格遵循。若 posture 缺失：继续操作，不进行适配。Band 绝不会改变 tier 规则或 Iron Laws。 当 docs/product/vision.md 存在时，说明这个想法是否属于产品范围。

当想法涉及用户、成功标准或产品原则时，阅读本文件旁的 product-context.md 并严格遵循。

为代码、文档和想法相关的近期提交派遣一个 scan 子 Agent → .skills/<CODE>/scan.md（确定 CODE 前使用 .skills/_pending-<slug>/scan.md）。 根据摘要开展工作。若没有子 Agent，则阅读少数相关文件。缺少 docs/agents/project.md → 说明这一点，建议使用 configure-repo，然后继续。

摘要 MUST 包含 Blindspot 部分：特定领域的陷阱、历史约束，以及新手不会想到要问的问题——且须以本仓库为依据。熟悉度低时，在步骤 2 的第一个偏好问题之前展示 Blindspot。

保证检查 — 在向用户提出安全相关用语之前，必须执行；用户请求中已有此类用语也算。 安全、原子、幂等、恰好一次、绝不重复、顺序、唯一——把请求中的说法当成已确定事实继承下来，同样属于默默提出这一主张。对每一项：指出它必须经受的故障，以及使其经受住该故障的 file:line；选择此代码路径能显现的故障（超时、写入过程中崩溃、重试、第二个调用者），并将其他故障标记为未经测试。没有行号 → 陈述时注明未经验证，并记录为已知未知。描述机制不等于检查。三个运行都引用了 catch 中的 idem.release(key)，该 catch 会在 PSP 超时时丢弃 key，却声称“绝不会重复退款”。

然后检查这个想法是否已经存在。必需子技能：使用 load-subgraph，查询该想法的关键术语和任何 scan 候选路径。 展示符合 schema 1.1 的相邻卡片；指出 owns_coverage。有依据的主张：遵循 skills/execution/load-subgraph/references/grounded-claims.md。 为嵌套的 clarify-decisions 保留有效的检索包。 完成标准：说明相邻卡片和 OWNS 覆盖范围，或根据 grounded-claims.md 明确说明“无重叠”以及空结果/覆盖情况。

已知事项清单（步骤 2 前必须完成）。 四条简短项目（可在聊天中列出；也可选存入 .skills/<CODE>/knowns.md）：

• 已知的已知事项／锁定项 — 已确定的约束和必须保留的行为。
• 已知的未知事项 — 需要研究、运行 spike 或由用户决定的开放问题。
• 未知的已知事项 — 用户能够辨认、但尚无法具体说明的偏好。
• 假设（非锁定项） — 用户提出的解决方案形态。切勿在被选定为锁定项之前，将假设提升为 SHALL 要求。

完成标准： 用一段话说明项目是什么、想法相关的现有内容、适用哪些术语表词条、哪些功能共用这一界面（或没有）——并且已知事项清单和 Blindspot 列表均已存在。

2. 访谈

严格遵循此清单。对单一提问渠道应用 clarify-decisions 协议。不要自行编造缩水版访谈。

必需子技能：使用 clarify-decisions。将 define-domain 作为被动副作用保留（必需子技能：使用 define-domain）。

临时判定为 tier 0？将嵌套访谈标记为 brief / tier-0，以保持 coverage 关闭。确认问题、一个约束和必须持续有效的事项；若未出现新情况，则转到步骤 5。

如果请求涉及多个相互独立的子系统，则停止细化，并在步骤 5 进行拆分。

完成标准： 开放项中不再存在高影响的判断事项，并且已确认 clarify-decisions 的结束包。

3. 遇到需要证据的问题时，进行绕行

仅适用于完整流程；tier 0 跳过此步骤。

• 涉及外部事实、API、库、标准，或已发布产品如何实现当前讨论的功能 → 必须使用子技能：使用 research（通过 Context7 MCP 获取最新的库文档）。
• “这个模型／流程实际用起来合适吗？”→ 必须使用子技能：使用 run-spike。

带着证据返回，并把决定交还给用户。 **完成条件：**没有任何待解决问题是靠猜测回答的。

4. 提出方案

仅适用于完整流程；tier 0 跳过此步骤。 提出 2–3 个真正不同的方案，并说明权衡。先给出推荐方案。按 YAGNI 原则精简。由用户选择。 如果这是已发布产品已有的功能，第一个方案应是实现该功能的产品方案——通过 research 确认，或标记为凭记忆回忆、未经核实——并列出该产品包含的每个组成部分，以及本仓库不需要的组成部分，每项说明一个删去理由。从零开始设计才是过度设计的根源。 **完成条件：**用户已选定方案（也可以是混合方案）。

5. 明确说明流程等级

等级	适用情况	后续步骤
0	仅拼写错误级别，不改变行为	不写规格——test-first
1	行为变更不超过约半天	迷你规格：修复 REQ + SHALL-CONTINUE-TO 防护
2	多任务功能	完整的需求 → 设计 → 计划三件套

如果工作涉及多个独立子系统，在此处拆分。两个或更多子功能：必须使用子技能：使用 plan-milestones，确保每个子功能都对应一个 ROAD-N。延期处理，不予拒绝。

**完成条件：**你已说明“这是等级 N，因为……”，并且如果进行了拆分，每个子功能都对应一个 ROAD-N，且你已指出哪个先做。

6. 终止状态

• **等级 ≥ 1：**必须使用子技能：使用 specify-behavior。这是唯一的退出方式。
• **等级 0：**说明等级，然后必须使用子技能：使用 test-first。

**完成条件：**已调用 specify-behavior（等级 ≥ 1），或已说明等级 0 的交接内容。