用途
frontend-handoff 解决的是后端改动落地后前端开发者最先要回答的问题：我是否需要动我的代码？该技能把答案作为一个明确判定给出，再用契约证据、载荷示例和检查清单支撑，最终形成一整块可直接粘贴进工单或聊天窗口的交接内容。
主要能力
- 判定分级：输出三种结论之一——必须改（Must change）、应该改（Should change）、无需改动（Nothing required），并说明决定该判定的那一个条件。
- 契约分类：逐项判断路由、字段、枚举/状态值、HTTP 状态码与已知错误、以及“契约不变但行为变化”的情况是否发生改变，并为每一行保留证据（文件或测试）。
- 载荷示例：提供请求/响应示例，帮助前端理解实际数据形态。
- 检查清单：给出前端需要逐项确认的事项。
- 工作区目录约定：除“无需改动”外，将填充后的内容保存到 .scratch/<feature-slug>/frontend-handoff.md。
使用方式
技能按步骤执行：
- 锁定改动：同时读取意图（SPEC.md、tickets/NN-*.md 等）与代码（对固定点做 diff，已提交用三点 diff 加 git log，未提交先 git add -N . 再 git diff）。空 diff 说明固定点选错，应说明并询问，而不是仅凭工单写交接。
- 了解仓库的响应封装：阅读 GLOSSARY.md、CLAUDE.md、序列化器/资源以及一个通过的 feature 测试，确定成功封装、派生状态位置、错误封装与前端会分支的 HTTP 码、以及看似可互换实则不同的领域状态。
- 分类契约：对路由、字段、枚举/状态、HTTP 码与错误消息、仅行为变化逐项判定 changed/unchanged 并保留证据。
- 选择判定：按最强成立条件选唯一结论。
- 填充模板。
- 保存交接：若判定为“无需改动”则跳过保存，仅在聊天中给出判定行和一句理由；否则保存到 .scratch/<feature-slug>/frontend-handoff.md，已存在则覆盖，无需先请求许可。
- 交付：先检测宿主环境（printenv CLAUDECODE 在 Claude Code 中返回 1，其他环境为空）。在 Claude Code 中文件即副本，只回复判定行和保存路径；其他环境则给出判定行、完整内容块和保存路径。
输出模板包含：标题、判定、后端改了什么、API 契约表（路由/封装与字段/枚举与状态/HTTP 码与已知错误）、同契约下的新行为（之前/现在）、前端影响表（类型与封装解析、界面与状态、请求载荷构造、缓存与列表与失效、4xx 处理、范围外流程）、载荷/响应示例、前端应停止假设的事项、检查清单。
适用场景
- 后端改动完成，需要向前端团队交接契约影响。
- 需要判断前端是否必须跟进、是否只是可以优化、还是完全无需改动。
- 需要一份可直接粘贴进工单或聊天的结构化说明。
限制
- 仅提供上下文，前端工作属于独立任务；该技能描述前端需要决定什么，绝不编写前端代码或补丁。
- 判定必须基于实际读取改动，不能从分支名推断。
- 契约不变时新增行为最高只能判为“应该改”；若规格说明没有契约、schema 或枚举变化，判为“必须改”是错误的。
- 与后端对称不构成理由，前端改动只能因用户可见行为或前端读取的契约而成立。
- 模板中的标题与标签需按用户所用语言翻译，但代码、路由、字段名、枚举值和 HTTP 状态码保持原语言逐字不变。
- 缺失信息应标记为 N/A，不得编造路由或字段。
工作区目录与交付细节
.scratch/ 布局参见 docs/agents/issue-tracker.md。<feature-slug> 优先取自第 1 步锁定的功能文件夹，否则由模板标题中的短功能名生成 slug。