从 AI 写代码
到 AI 工作流

1. 收礼、送礼礼物墙的可见范围分别设置，档位为：全部展示（默认）、
   仅近 1 年、仅近半年、仅近 3 个月、不展示。
2. 本人查看自己的礼物墙时始终看到完整数据，被隐藏的部分用分界线
   和锁头标记出来；他人视角任何情况下都不出现锁头。
3. 他人查看时只能获得可见范围内的礼物；范围外数据不进入接口响应。
   注意：数量和冠名按累计值展示，不受时间范围过滤影响。
4. 该设置是付费权益，不满足等级的用户没有设置入口，操作时引导开通。
5. 旧版本终端无法隐藏等级行时，降级展示：等级图标换成缺省图，
   名称固定显示"礼物墙"，点亮数量显示"未点亮"。

一个最小 Skill：grilling

Matt Pocock 的 grilling 把整个 Brainstorm 阶段压到了 12 行。下面按逻辑段给出原文和译文，逐段看它为什么长这样。

frontmatter

---
name: grilling
description: Grill the user relentlessly about a plan or design. Use when the user wants to stress-test a plan before building, or uses any 'grill' trigger phrases.
---

description 写给谁看？写给 Skill 路由器。它声明了触发条件——用户想压测计划时调用——这决定了这个 Skill 会在正确的时机被捡起，而不是在用户随口聊天时插嘴。

第一段：访谈怎么走

Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.

两个设计点。"Walk down each branch of the design tree" 规定访谈沿着决策树走，不是漫聊——防的是聊了一小时、关键分支没碰到的"伪对齐"；"provide your recommended answer" 要求 AI 带建议提问，人只需确认或否决，认知负担小得多。放在直播案例里，就是"可见范围给哪几档？我建议全部/近 1 年/近半年/近 3 个月/不展示，理由是覆盖主播隐藏历史礼物的诉求"这种问法，而不是一句空泛的"你有什么想法"。

第二段：一次一问

Ask the questions one at a time, waiting for feedback on each question before continuing. Asking multiple questions at once is bewildering.

一次抛五个问题，人往往只答最后两个，前面三个就被默认过去了——开场版本 A 里那些假设，正是这样被悄悄补全的。这条把"没回答"变成一个显式状态：没等到答案，流程就停在原地。

第三段：事实与决策的分工

If a *fact* can be found by exploring the codebase, look it up rather than asking me. The *decisions*, though, are mine — put each one to me and wait for my answer.

fact 和 decisions 用斜体标出，是这份源码里唯一的强调。事实先查代码再问人，仓库里有的答案不占用人的注意力；决策归人，AI 可以推荐，不能拍板。这条划的是责任线，不是能力线：旧版本终端遇到新配置怎么办，代码里查不到，必须有人拍板；而"现有礼物墙接口返回哪些字段"，AI 应该自己去仓库里翻。

第四段：Gate

Do not enact the plan until I confirm we have reached a shared understanding.

一句话挡住"聊完顺手就开写"。这是 Brainstorm 阶段的 Gate 落到一句指令上的样子：关键取舍没落定，实现就不开始。更强的同阶段做法会把这条从"口头约定"升级成"硬门禁"，比如 Superpowers 的 brainstorming 明确规定，用户批准设计之前不准调用任何实现 Skill、不准写代码；含义相同，约束力不同。

十二行，四个动作：沿决策树问、一次一问、事实自查、确认前不动手。它们共同把"需求对齐"从一种良好愿望，变成一段可以被检查的行为。

六套工作流怎样覆盖这一阶段

两个代表值得展开看。OpenSpec 的 /opsx:explore 把"探索期"做成了明确状态：在创建任何文档、写任何代码之前，先聊透范围、边界和验收标准，期间不产生正式变更档案，原则是"没聊清楚前，不动工"。它适合那些想保留轻量对话、但希望"聊"和"做"之间有明确分界线的团队；等聊透了，才用 /opsx:propose 把结论落成合同（下一站会看到）。

OMC 的 /deep-interview 则是另一个取向：苏格拉底式的一次一问，专门暴露需求里的假设，同样不生成 Artifact、不写代码；等你说"make it a plan"，它把访谈结论 handoff 给 /plan，进入 PRD 和测试规格的生成。它适合任务边界模糊、又打算后续用 OMC 的多 Agent 执行能力的场景。访谈不是终点，是给后续编排选模式、攒输入。

需求对齐了，但别急着写代码。"要什么"清楚了，"放进系统的哪个位置"还没定。下一站要处理的，正是这个更隐蔽的坑。

一个最小 Skill：to-spec

Matt Pocock 的 to-spec（原名 to-prd）负责把已经讨论清楚的内容落成一份 Spec。这次给出完整原文，分段对照。

frontmatter

---
name: to-spec
description: Turn the current conversation into a spec and publish it to the project issue tracker — no interview, just synthesis of what you've already discussed.
disable-model-invocation: true
---

disable-model-invocation: true 这一行值得停一下。grilling 没有它，因为访谈应该由模型在需要时主动拉起；而 to-spec 是一个"落锤"动作——把讨论结果固化成文档——必须由人显式下令，不允许模型觉得"聊得差不多了"就自己把 Spec 写了。落锤权在人手里，这和 Design 阶段的 Gate 是同一件事的两面。

开头：只综合，不访谈

This skill takes the current conversation context and codebase understanding and produces a spec (you may know this document as a PRD). Do NOT interview the user — just synthesize what you already know.

它和 grilling 是分工关系：访谈已经做完了，这里只综合，不重新打扰人。防的是每个环节都重新问一遍，把人问烦以后开始敷衍确认。

Process 第 1 步：先读仓库和 ADR

1. Explore the repo to understand the current state of the codebase, if you haven't already. Use the project's domain glossary vocabulary throughout the spec, and respect any ADRs in the area you're touching.

两个具体要求。"domain glossary" 保证 Spec 里的词和代码里的词是同一套——直播案例里就是统一说"礼物墙""进场动效"，而不是 Spec 一套词、代码一套词；"respect any ADRs" 要求写方案前先读已有架构决策，新设计和旧 ADR 冲突时，要么改方案，要么显式推翻旧决策，不能假装它不存在。

Process 第 2 步：先定测试接缝

2. Sketch out the seams at which you're going to test the feature. Existing seams should be preferred to new ones. Use the highest seam possible. If new seams are needed, propose them at the highest point you can. The fewer seams across the codebase, the better - the ideal number is one.

   Check with the user that these seams match their expectations.

seams 是"从哪里看结果"的观察点：公开接口、消息输出、用户可见行为都算。这一步把"怎样验证"前置到设计阶段——测试接缝不是写完代码补的，是设计的一部分。直播案例里，"他人查看礼物墙"的接缝选在接口响应而不是页面渲染，第五站会看到，这个选择直接决定了 Spec Review 能不能抓住"前端不渲染但数据照返"的错误。

Process 第 3 步：按模板写并发布

3. Write the spec using the template below, then publish it to the project issue tracker. Apply the `ready-for-agent` triage label - no need for additional triage.

<spec-template>

## Problem Statement
## Solution
## User Stories
## Implementation Decisions
## Testing Decisions
## Out of Scope
## Further Notes

</spec-template>

发布到 issue tracker 并打 ready-for-agent 标签，是一个容易被忽略的闭环设计：Spec 的终点不是一份文档，而是任务系统里一张"可以被 Agent 直接领走"的工单——它把 Design 的产物直接接到 Plan/Execute 的入口上，不需要人再转述一遍。模板里 Testing Decisions 和 Out of Scope 独立成节也有讲究：这两项恰是大多数团队最容易漏的，漏了前者，Execute 没有观察点；漏了后者，Agent 会把顺手能做的都塞进范围。

这份 Skill 的 Gate 也清楚了：没有成型的 Spec，就不进入拆任务。下一站的 to-tickets，吃的正是这里的输出。

六套工作流怎样覆盖这一阶段

展开看两个。OpenSpec 的 /opsx:propose 把设计落成仓库里的变更档案：openspec/changes/<change-name>/ 下放 proposal.md、specs/<capability>/spec.md、复杂变更再加 design.md 和 tasks.md。Spec 有硬性格式：每条需求用 SHALL/MUST 表述，且至少配一个 Scenario——"他人查看时范围外数据不进入接口响应"这种规则，在这里必须写成可检查的场景，而不是形容词。它适合需要编码前评审、变更历史可追溯的团队；代价是这些合同要人持续写、持续审，没有 Review 习惯的团队会跳过它。

BMAD 走角色化路线：PM 角色用 bmad-prd 产出 planning_artifacts/prd.md（需求条目带稳定的 FR 编号），随后 Architecture 阶段产出 ARCHITECTURE-SPINE.md，写明不变量、模块边界、依赖、数据归属和状态管理。它有一道 PRD Reviewer Gate：按 rubric 逐项走查、reviewer 审查、遗留问题分诊，走完才能 finalize。适合产品型大项目从需求到架构一步不缺地推进；小团队全套走下来会嫌重，可以只借 PRD + Architecture 两份 Artifact 的格式。

设计落到了纸面上，SELF/OTHER 的判断有了归属。但一份好设计不等于一份能执行的任务清单。方案清楚，不代表适合一次性塞给 Agent。下一站的翻车，恰恰发生在"上下文装不下"这件事上。

任务 1：修改协议
任务 2：修改后端
任务 3：修改 H5
任务 4：修改 PC
任务 5：补测试

切片 1：普通直播间的进场动效，从协议到 PC webp 展示完整跑通
切片 2：本人查看礼物墙时，完整数据加分界线、锁头正常展示
切片 3：他人查看设置"仅展示近半年"的礼物墙时，只获得范围内礼物
切片 4：旧版本终端查看隐藏等级的资料卡时，按降级规则展示

任务标题还不够。以"他人查看礼物墙"为例，至少要给出可执行的验收标准。我的 PRD 里有个现成的情景：某用户累计收到 10 个 A 礼物（其中半年内 2 个，冠名人是一年前的送礼者）和 5 个 B 礼物（半年内 0 个），他把收礼可见范围设为"仅展示近半年"。这时验收标准应该是：另一个人来看他的收礼礼物墙，只能看到 A 礼物，而且 A 的数量和冠名仍按累计值展示；用户自己看，则能看到全部礼物，以及"以下礼物他人不可见"的分界线。写成验收语言就是一句"给定……当……那么……"：

给定墙上同时存在半年内和更早的礼物，当他人查看这面墙，那么响应里只有范围内礼物，本人查看则不受影响。

注意"数量和冠名按累计值展示"这一笔，就是 Brainstorm 阶段记下的那条容易漏的规则，在这里变成了可检查的断言。开发知道实现目标，测试知道观察入口，下一会话也不用重新解释什么叫"正确过滤"。一份能执行的计划，说到底就是让每个任务都能独立回答"怎样算完成"。

一个最小 Skill：to-tickets

Matt Pocock 的 to-tickets（原名 to-issues）把"怎么拆"直接写成了规则。完整原文分段对照如下。

frontmatter 与开头：拆成 tracer bullet

---
name: to-tickets
description: Break a plan, spec, or the current conversation into a set of tracer-bullet tickets, each declaring its blocking edges, published to the configured tracker — edges as text in a local file, or native blocking links on a real tracker.
disable-model-invocation: true
---

# To Tickets

Break a plan, spec, or conversation into a set of **tickets** — tracer-bullet vertical slices, each declaring the tickets that **block** it.

tracer bullet 是个精准的比喻：曳光弹不追求一击致命，它追求"打出去能看见弹道"。每个 ticket 存在的意义是让进展可见、可验证，而不是把工程量均分。

核心规则：vertical-slice-rules

<vertical-slice-rules>

- Each slice cuts a narrow but COMPLETE path through every layer (schema, API, UI, tests) — vertical, NOT a horizontal slice of one layer
- A completed slice is demoable or verifiable on its own
- Each slice is sized to fit in a single fresh context window
- Any prefactoring should be done first

</vertical-slice-rules>

Give each ticket its **blocking edges** — the other tickets that must complete before it can start.

四条规则各防一种死法。"narrow but COMPLETE path" 防的就是前面按技术层横切的拆法："改协议""改后端"各自完成却拼不起来。"demoable or verifiable on its own" 给了 Plan 一个客观判据：说不清"做完能演示什么"的切片，就是还没拆到位。"sized to fit in a single fresh context window" 直接回应 Context Rot——任务大小的上限不是模型读不读得下，而是在一个全新会话里能不能稳定做完。"blocking edges" 显式声明谁挡谁；没有依赖边，并行执行就是赌博，发布顺序靠记性。注意第四条 prefactoring：容易被跳过的一条——直播案例里"先把进场动效组装逻辑移出特殊玩法分支"正是典型的 prefactoring，不先做它，后面每个切片都要绕着这坨旧结构走。

收尾一步：让用户拷问拆分

### 4. Quiz the user

Present the proposed breakdown as a numbered list. For each ticket, show:

- **Title**: short descriptive name
- **Blocked by**: which other tickets (if any) must complete first
- **What it delivers**: the end-to-end behaviour this ticket makes work

Ask the user:

- Does the granularity feel right? (too coarse / too fine)
- Are the blocking edges correct — does each ticket only depend on tickets that genuinely gate it?
- Should any tickets be merged or split further?

Iterate until the user approves the breakdown.

这一步容易被当成文书工作省掉，其实它是 Plan 阶段的 Gate：拆分是设计决策，不是誊写。"What it delivers" 要求写出端到端行为而不是任务动作——写不出行为的 ticket，当场就暴露了它切得不对。对应到直播间案例，就是"他人查看设置'仅展示近半年'的礼物墙时只获得范围内礼物"这句可演示的话，而不是"修改礼物墙接口"。

到这一步，Plan 的 Gate 就立起来了：拆分经人批准、每个 ticket 自带验收行为，才轮到 Execute 开工。

六套工作流怎样覆盖这一阶段

展开看两个代表。Get Shit Done 的 /gsd:plan-phase 把计划当成要过审的 Artifact：gsd-phase-researcher 先写 NN-RESEARCH.md（事实结论必须带来源，第三方包标 ASSUMED/VERIFIED），gsd-planner 再写 NN-PLAN.md，每个任务带 <files>、<action>、<verify>、<done>，明确禁止"v1 先做个基础版"这种隐性砍范围；最后 gsd-plan-checker 做对抗性审查，默认计划有缺陷，最多打回三轮。另有专项门禁：计划必须含安全威胁模型，每个任务的 verify 必须是自动化命令。适合长周期多阶段项目；小任务可以走它的 /gsd:quick 快通道。

Trellis 的做法轻一些但更贴日常：每个任务是一个目录 .trellis/tasks/MM-DD-<name>/，计划写在 implement.md（有序检查清单、验证命令、回滚点——出问题能退回的位置），另有两份上下文清单 implement.jsonl 和 check.jsonl，逐条声明"实现时要读哪个文件、为什么"。这份清单直接决定执行 Agent 的上下文里装什么，把"该读什么"从临场判断变成计划的一部分。两者一个重审一个重接续，共同点是：计划落到文件里，下一会话不用从聊天记录里猜进度。

任务拆好了，每个切片都有验收标准。现在 Agent 终于可以写代码了。但"怎么写"里还藏着一种翻车：一次改太多，错误很晚才暴露。这是下一站的戏。

读取当前切片
→ 建立可运行的验证入口
→ 做最小修改
→ 立即验证
→ 通过后进入下一片

RED
运行"普通直播间返回进场动效"的场景测试
→ 失败：响应中没有进场动效资源

CHANGE
把进场动效数据组装移出特殊玩法专属分支
→ 保留特殊玩法原有行为

GREEN
重新运行普通直播间与特殊玩法两组场景
→ 两组都通过

一个最小 Skill：implement

Matt Pocock 的 implement 全文只有 15 行，是六个 Skill 里最短的一个。短是设计的一部分：执行阶段不该给 Agent 留自由发挥的空间。逐行对照看。

frontmatter 与第一句：输入是什么

---
name: implement
description: "Implement a piece of work based on a spec or set of tickets."
disable-model-invocation: true
---

Implement the work described by the user in the spec or tickets.

"based on a spec or set of tickets" 是这份 Skill 的地基：实现的输入是上一站的产物，不是脑子里的印象。没有 ticket 就没有开工依据——这一句把 Execute 焊死在 Plan 的输出上。

TDD 与接缝

Use /tdd where possible, at pre-agreed seams.

两个限定词都有出处。"where possible" 承认协议、跨端资源和复杂 UI 不适合严格单元测试；"pre-agreed seams" 把观察点的来源钉死——seams 是 Design 阶段 to-spec 第 2 步定下的，执行阶段不临场发明观察点。直播案例里"普通直播间返回进场动效"的场景测试之所以存在，就是因为接缝早已写进 Spec。

验证节奏

Run typechecking regularly, single test files regularly, and the full test suite once at the end.

注意 regularly 和 once 的对比。单测和类型检查频繁跑，问题在分钟级暴露；完整套件最后跑一次兜底。全量测试留到最后才跑，就是前面说的"一把梭"的出处——这一行是"短反馈循环"落到命令层面的样子。

完成后做什么

Once done, use /code-review to review the work.

Commit your work to the current branch.

最后两行划出 Execute 的边界：实现完不直接宣布完成，先过独立 Review——"done" 这个词在这份 Skill 里不等于"完成"，只等于"可以送审"；提交到当前分支而不是开新分支或推远端，一个切片的改动就是一个可回滚单元。Gate 也随之明确：切片拿到新鲜验证结果、过了 Review，才轮到下一个。

十五行，没有一句讲怎么写代码，全是关于输入、验证节奏和收尾边界。执行纪律的意义正在于此：写代码的能力模型自己有，工作流要管的是它什么时候写、拿什么验证、什么时候停。

六套工作流怎样覆盖这一阶段

Superpowers 的 subagent-driven-development 是"每任务一个干净上下文"的严格执行版：先用 using-git-worktrees 隔离工作区并验证基线测试，然后每个 task 派一个全新的 implementer subagent，不带主会话历史，只靠任务文件干活；实现完派独立的 task reviewer 审 spec 符合度和代码质量，不过就派 fix subagent 修完再审；全部完成还有一轮全分支 final review。进度记进 .superpowers/sdd/progress.md 账本，防止上下文被压缩后重复执行。约束同样硬：不允许跳过 review、不允许并行派多个 implementer、执行中不中途问人。它适合边界清楚、值得为每个任务付两次上下文成本的改动；小任务这么跑显然过重。

Get Shit Done 的 /gsd:execute-phase 解决另一个问题：长计划的并行与隔离。原则是"orchestrator 协调、不亲自执行"——分析依赖后把任务分组成 wave，每个 wave 派 gsd-executor subagent 并行跑；同 wave 改同一文件的任务强制串行，用 git worktree（给每个任务开一个独立目录）隔离；每个 wave 合并后跑构建和测试，绿了才进下一个。前提是环境支持 subagent 和 worktree，缺一这套并行就要降级。

代码写完了，切片测试全绿。可以宣布完成了吗？还不行。测试只回答测试里写过的问题。下一站要处理的，是"AI 自己证明自己正确"这件事。

测试通过，Spec Review 仍然失败

假设实现者选择了最容易观察的页面结果：前端不渲染隐藏礼物卡片，并补了一条页面测试。最后可能出现三份互相不一致的证据：

前两个 PASS 证明页面表现和代码结构没有明显问题。但回忆第一站定下的规则，"他人查看时只能获得可见范围内的礼物，范围外数据不进入接口响应"，所以最后一个 FAIL 仍应阻塞发布。Execute 检查当前反馈，Verify 还要追问：我们选的反馈足以证明原始需求吗？到这里你能看到整条因果链：Brainstorm 写下的那句规则，Design 定下的过滤位置，在这一刻变成了裁决发布的依据。

这一站的分工与门槛：AI 负责扫 Diff（改动对比）、追调用链、跑测试、查异常分支；风险能否接受、需求解释是否正确、哪些问题阻塞发布，由负责人判断。通过条件不变：没有新鲜验证输出，不声称完成；存在未处理的 Blocker（阻塞发布的问题），不进入发布。

一个最小 Skill：code-review

Matt Pocock 的 code-review 让两个独立上下文分别检查 Standards 和 Spec，再并排展示结果。完整原文分段对照。

frontmatter 与开头：审什么

---
name: code-review
description: Review the changes since a fixed point (commit, branch, tag, or merge-base) along two axes — Standards (does the code follow this repo's documented coding standards?) and Spec (does the code match what the originating issue/PRD asked for?). Runs both reviews in parallel sub-agents and reports them side by side. Use when the user wants to review a branch, a PR, work-in-progress changes, or asks to "review since X".
---

Two-axis review of the diff between `HEAD` and a fixed point the user supplies:

- **Standards** — does the code conform to this repo's documented coding standards?
- **Spec** — does it faithfully implement the originating issue / PRD / spec?

Both axes run as **parallel sub-agents** so they don't pollute each other's context, then this skill aggregates their findings.

三个设计点一次说清。"a fixed point the user supplies" 先把比较点钉死，审的是一段确定的 Diff——不钉死，AI 很容易挑一段对自己最有利的改动来夸。两个轴一个问"代码合不合规范"，一个问"是不是需求要的东西"，前面三份证据的例子已经说明，这两个问题的答案可以完全相反。"parallel sub-agents so they don't pollute each other's context" 是防自证闭环的直接手段：同一个人既写又审容易自我说服，让两个独立上下文分别审，误解才有机会被暴露。

Process 五步

## Process

### 1. Pin the fixed point

### 2. Identify the spec source

### 3. Identify the standards sources

### 4. Spawn both sub-agents in parallel

### 5. Aggregate

第 2、3 步容易被忽略，但它们解释了这份 Skill 为什么依赖前五个阶段：Spec 来源是 Brainstorm 和 Design 写下的规则，规范来源是项目长期沉淀的标准。没有这两份输入，双轴审查就成了空转——Reviewer 拿不出来对照的东西，只能凭感觉说"看着还行"。直播案例里，Spec 轴对照的就是"范围外数据不进入接口响应"和"数量冠名按累计值展示"这两条早已写下的断言。

Aggregate：报告不许合并

Present the two reports under `## Standards` and `## Spec` headings, verbatim or lightly cleaned. Do **not** merge or rerank findings — the two axes are deliberately separate.

"Do not merge or rerank findings" 防的是一种隐蔽的稀释：一旦合并，"代码写得好"和"需求做得对"就容易被混成同一项，FAIL 被 PASS 平均掉。即便只用一个 Reviewer，也可以照这个思路分两轮检查。与双轴配套的另一条纪律是 Superpowers 的 verification-before-completion：任何"完成/通过"的说法之前，必须先运行验证命令并读取输出，"应该能过"不算证据。双轴管"审什么"，那条管"凭什么下结论"。

这份 Skill 就是 Verify 阶段 Gate 的实体化：报告分开、证据新鲜、Blocker 不处理就不放行。

六套工作流怎样覆盖这一阶段

BMAD 的 bmad-code-review 把对抗性做到了角色级：并行派出一组审查 subagent：Blind Hunter 找视野外的问题，Edge Case Hunter 找边界，Verification Gap Reviewer 查"声称验证了但没证据"的缺口，Acceptance Auditor 逐条对验收标准。发现项按 high/medium/low 路由到处置：现场拍板、打补丁、延期（写入 deferred-work.md）或驳回；story 不过 review 就不能置为 done。官方也承认对抗式审查有误报，需要人过滤——所以它的结论是分诊清单，不是自动判决。

OMC 的 team-verify 则把 Verify 编成流水线的一级：多 Agent 执行走 team-exec → team-verify → team-fix 循环，verifier 必跑，按风险加 test-engineer、security-reviewer、code-reviewer；改动超 20 个文件或涉及架构变更时，后两者是必须项；不通过就生成 fix 任务回到执行，最多循环 max_fix_loops 次。适合已经在用 OMC 编排多 Agent、需要把"审不过就修"自动化的场景；代价是要治理这套状态机本身。

Blocker 清零，发布获准。很多人以为故事到这就结束了，其实最容易被低估的一段才刚开始：代码合并了，交付还没完成。

目标：完成"他人查看礼物墙时过滤隐藏数据"切片。
已完成：后端过滤、本人/他人契约测试、相关终端联调。
依据：需求规则见 Spec；边界决策见 Design；改动链接见任务记录。
验证：契约测试和相关回归已通过，输出链接见任务记录。
剩余风险：旧版本终端的降级展示只验证了主流版本，长尾版本待观察。
下一步：上线后跟踪礼物墙相关客诉与数据复盘；异常时关闭新规则开关并回滚服务版本。

一个最小 Skill：handoff

Matt Pocock 的 handoff 把"引用而非复制"写成了硬性条款。完整原文分段对照。

frontmatter 与第一句：写给谁看

---
name: handoff
description: Compact the current conversation into a handoff document for another agent to pick up.
argument-hint: "What will the next session be used for?"
disable-model-invocation: true
---

Write a handoff document summarising the current conversation so a fresh agent can continue the work. Save to the temporary directory of the user's OS - not the current workspace.

两个细节。"argument-hint" 要求调用时说清下一会话的用途，交接内容围绕这个用途裁剪，而不是泛泛总结全部历史。"保存到临时目录，不是工作区"是个容易看漏的决定：工作区是项目的共享事实源，放一份带个人观点和中间态的交接文档进去，它就会被后来的 Agent 当成项目材料读进去——交接是临时的，仓库是长期的，两者不能混。

建议调用的 skills

Include a "suggested skills" section in the document, which suggests skills that the agent should invoke.

交接不只交接状态，还交接"接下来该调用什么工具"。下一位不是从零猜流程，而是直接被接回工作流——比如接着做实现就提示调 /implement，准备收尾就提示调 /code-review。

引用而非复制

Do not duplicate content already captured in other artifacts (specs, plans, ADRs, issues, commits, diffs). Reference them by path or URL instead.

这条对应前面 Handoff 示例里"依据：需求规则见 Spec；边界决策见 Design"的写法。复制会制造第二份事实源，而第二份总是先过期——下一位沿着引用读到的是最新版本，沿着复制读到的是快照。

脱敏与参数

Redact any sensitive information, such as API keys, passwords, or personally identifiable information.

If the user passed arguments, treat them as a description of what the next session will focus on and tailor the doc accordingly.

交接文档会被更多人看到，密钥和个人信息要在这一步拦下。最后一句和 frontmatter 的 argument-hint 呼应：交接不是压缩比越高越好，是让下一位能立刻开工。

这份 Skill 把 Ship 阶段的 Gate 落到了纸面：交接存在、引用有效、敏感信息清零，这趟旅程才算真正走完。

六套工作流怎样覆盖这一阶段

Trellis 的 /trellis:finish-work 把 Ship 做成固定收尾动作：先检查有没有进行中的任务、有没有游离在任务之外的未提交业务改动（有就拒绝执行）；然后提交业务改动、把新规范写回 .trellis/spec/、归档任务目录，最后写一条 Workspace Journal，记下做了什么、改了哪些文件、提交哈希、下一步。Journal 进 Git。换会话、换工具之后，从 Journal 就能接回上下文。它维护的是"过程记忆"，适合长期项目、多人多工具接力。

OpenSpec 的 openspec archive 维护的是另一种记忆："规范记忆"。变更完成后，它把 Change 里的增量合并回 openspec/specs/ 长期规范，再把档案移到 openspec/changes/archive/ 按日期留存。specs/ 永远是"当前真相"，archive 是"变更历史"。新需求来了，AI 读的是最新事实源，而不是一摞过期方案。前者回答"上次做到哪了"，后者回答"系统现在约定成什么样了"，两者解决的是 Ship 的不同半边。

直播间这趟旅程走完了。回头看，六个阶段不像六级台阶，更像一条链：任何一环松动，问题都会顺着链往下游传，并且在更贵的地方爆掉。