---

name: h3-intake-main description: "H3 需求受理员操作手册：把玩家/上级的原始意图整理成六段齐全、可被逐条核对的结构化需求 brd，落在 01-intake/。" layer: 1 domain: video keywords:

• intake
• brd
• requirement

- h3video

Skill: H3 需求受理员 四段式操作手册

角色契约（职能 / 交付物定义 / 验收判据）见本体 ../../agent.md，本手册只管"怎么干"。

我的坐标（固定落点）

坐标	路径	规矩
输入	派单正文（玩家意图/剧本原文），可能有参考图 url	只读
交付物	/app/data/companies/h3video/workspace/01-intake/brd.md	只有写到这里才算交付
禁写	02-* ~ 07-*、01-intake/ 以外的任何目录	越界 = 节点判失败

四段式（本角色具体化）

RESEARCH

1. 把派单原文逐字留在 _research.md 里（别只写摘要 —— 原话是后面所有节点的追溯依据）。
2. 翻 /app/data/companies/h3video/workspace/ 下既有的 01-intake/brd.md（历史订单）， 看有没有同类片子的口径可以直接沿用；有就引用路径，别重新发明。
3. 列空缺表：主角 / 场景 / 风格 / 时长 / 台词 五项，逐项标「输入已给 / 磁盘可查 / 需假设 / 需问」。

PLAN

_plan.md 里先写 brd 的六段骨架，再写每一段打算怎么填；验收标准写死为 "六段非空 + 无悬空 TBD + 假设逐条署名"（见 agent.md 验收判据 1-5）。

EXECUTE

按 agent.md 的六段模板写 brd.md。措辞纪律：

• 每条需求写成"可以对着成片判是/否"的句子；
• 主角/场景要素标注出处（输入原话 / 假设：我按 X 理解，理由 Y）；
• 查不到的核心主体外观写 UNSPECIFIED 并进「假设与待补项」，绝不编。

VERIFY

1. grep -c "^## " brd.md 核对段数；逐段 grep 关键字段（时长数字、主角名）确认非空。
2. grep -n "TBD\|待定" brd.md —— 允许出现在「假设与待补项」且带理由，其余位置不允许。
3. 反向自测：只读 brd.md，回答"第一镜拍什么" —— 答不出说明需求还不够开工，打回重写。

硬规矩（本角色）

• 输入连"想拍什么"都没有 → blocked，不造 brd。
• brd 是全链验收基准，措辞必须可判定；"好看/有质感"这类词不许当需求条目。
• 未经四段式流转直接报 PASS 属严重违规。