---
name: brifdo-execution-consumer
description: Consume a Brifdo (稿见) execution handoff contract through the Brifdo MCP service and implement it as a real codebase. Use whenever a coding agent is asked to implement, resume, or verify a product whose requirements, prototypes, and acceptance contract live in Brifdo, including long-running implementation resumed across sessions.
---

# Brifdo Execution Consumer

本 Skill 面向实施方 coding agent（Claude Code、Cursor 等）：通过稿见 MCP 的
`read_execution_handoff` 工具读取已评审产品的执行合同（实施任务、验收合同、
需求文档），并在自己的工作区把它实现为真实代码库。此路径只读稿见；把服务端
随响应返回的 `consumption` 与 `nextAction` 指引视为权威。

## 前置：连接与授权

- 通过既有的稿见 MCP OAuth 连接读取，`mcp:read` scope 即可；不需要原型写入
  权限。
- access token 15 分钟过期。长时间实施应在授权时额外请求 `offline_access`
  scope（客户端注册需包含 `refresh_token` grant），用轮换的 refresh token
  续期；刷新请求必须携带与初次授权相同的 `resource` 参数，否则续期失败。
- 只能读取当前稿见账号有权访问的产品。`read_execution_handoff` 未注册时，
  调用 `get_service_capabilities` 查看 `unavailableTools` 中列出的原因并
  转告用户，不要猜测替代路径。

## 读取顺序

1. 以 `scope:"index"`（默认 scope）起步，只带 `productReference`（产品 URL
   中的公开引用）。响应字段：
   - `live.contractStatus`：`"ready"` 表示需求合同已闭环，可正式实施；
     `"draft"` 表示尚未闭环——把 `live.blockingIssues` 逐条转述给用户，
     内容照样可读但仅供预研，不得当作已确认交付范围实施。
   - `live.sourceFingerprint` 与 `live.moduleRevisions`：实时合同的恢复
     凭据（见下节）。
   - `frozenRevisions` / `latestFrozenRevision`：团队冻结过的基线修订列表
     及最新修订号。可能为空——为空不是错误，直接读实时合同即可。
   - `consumption` / `nextAction`：服务端给出的消费与下一步指引。
2. `scope:"execution"`（省略 `revision` 即读实时合同）获取实施合同：
   `markdown` 字段是完整的「Agent 执行说明」文档，含实施任务与验收合同。
3. 需要产品需求文档时读 `scope:"prd"`（同样在 `markdown` 字段）。
4. `scope:"manifest"` 返回结构化机器合同，体量较大，仅在需要程序化处理
   （生成任务清单、统计组件用量等）时使用；正常实施读 `execution` 就够。

## 恢复凭据：先记录，再动手

实时合同没有锁：原型可能随时被继续修改。开始实施前必须记录内容响应
（`source:"live"`、`revision:null`）中的两项凭据：

- `sourceFingerprint`：整份合同的指纹。
- `moduleRevisions`：每个模块的 `moduleRef` 与 `sceneRevision`
  （`sceneRevision: null` 表示该规划模块尚未绘制原型）。

中断、换会话、隔天继续时：重新读取同一 scope 并比对。`sourceFingerprint`
一致即从断点继续；不一致时用 `moduleRevisions` 找出 `sceneRevision` 变化的
模块（若所有模块修订都没变而指纹变了，变化发生在成功标准等补充材料部分），
向用户说明差异并确认后再继续。严禁静默按新合同实施。

携带 `revision` 参数读取的是不可变冻结修订（`source:"frozen"`）：

- 固定同一 `revision` 重复读取，内容保证逐字节一致。中断后携带相同的
  `productReference` 与 `revision` 重新调用即为恢复。
- `status:"stale"` 只表示产品在该修订冻结之后又被修改；已固定修订的内容
  不变，可以继续按它实施。是否切换到更新的修订或实时合同由用户决定。
- 指定的 `revision` 不存在时返回 `HANDOFF_NOT_FOUND`，不会静默回退到实时
  合同；把错误信息转述给用户。

## 落地实施

执行合同 markdown 的固定小节及用法：

- 「成功标准 / 非目标 / 业务约束 / 目标技术环境 / 交付决策」：实现的边界
  条件。与实际情况冲突时停下询问用户，不要自行取舍。
- 「组件清单」：原型由 shadcn 体系组件构成，任意 shadcn 支持的框架均可。
  用 shadcn CLI 初始化项目后，按清单 `add` 同名组件（每个条目注明所属
  `recipeId`）；`block:*` 与 REUI 来源的组件以 registry 配置为准，不要
  手工重写既有组件。
- 「视口与响应式」：原型按固定设计视口绘制（`scope:"manifest"` 的
  `viewport` 块给出 width / height / prototypeType / responsiveIntent；
  height 是起始值，页面可纵向延展）。`responsiveIntent:"adaptive"`
  （Web 产品）表示设计稿视口只是设计基准，不是唯一断点——shadcn/Tailwind
  产物必须响应式适配窄视口；断点行为用 reflow / wrap / collapse /
  prioritize / scroll / hide 词汇描述，具体断点决策由你作出并在交付汇报
  中向用户说明。`"native-mobile"`（App 产品）表示直接以移动视口实现原生
  移动形态。验收语义：移动端/窄视口不出现横向溢出，核心流程在窄视口可
  完成。
- 「实施任务与验收」：每个 Screen 对应实现为一个页面/路由。每项任务列出
  「依赖任务」；同模块的前置任务先做。
- 「推荐实施顺序」：默认按此顺序推进，可在不违反依赖的前提下并行。
- 每个 Screen 的「完成条件」是验收合同：其中标注的主交互（原型里的
  hotspot 连接）要翻译成真实的导航/跳转；验收项的证据文案要作为页面上
  真实可见的文案落地——不要把整句验收句子塞进按钮或标签。
- 「验证建议」：实现完成后的自检清单。按每项的人工动作、预期结果、验证
  方式逐项核对，交互路径要真实走通。
- 「停止条件」：遇到列出的情形时停止实现并请求产品负责人确认，不得用
  未验证的页面或交互替代已列出的验收项。

## 完成后

- 向用户汇报实现与合同的映射：每个任务 ref（`task-…`）对应哪些文件或
  路由；显式列出未覆盖或有意偏离的验收项及原因。
- `responsiveIntent:"adaptive"` 的产品还要汇报响应式断点决策：采用了哪些
  断点、各区域的行为（reflow / wrap / collapse / prioritize / scroll /
  hide），以及任何被 hide 的补充性内容。
- 稿见侧没有进度回写：实施进度以你自己的工作区（代码、提交、测试）为准，
  稿见中的合同不会因你的实现而改变。

## 成本与用量

- 此路径不调用稿见模型，稿见 AI 模型费用为 0；需求理解消耗用户自己的
  Agent 模型额度。
- 每次 `read_execution_handoff` 读取都会出现在用户的稿见 MCP 用量记录中
  ——这是「合同被真实消费」的凭证，不产生稿见模型费用。