用途：把一份功能的 PRD 转成「代码能表达的一切」——类型、签名、路由、迁移、集成接口，全部落成可编译的桩，并生成一份契约文档来约束实现顺序。流程定位为 to-prd → to-scaffold → to-tickets → fleet，每次只处理一个功能。
主要能力：读取 docs/prds/<feature>.md；若指定功能则用对应文件，存在多份 PRD 且目标不明确时先询问，绝不一次处理多个功能；没有 PRD 时通过逐个提问现场写出核心 PRD（问题、带可观察终态的旅程、交付切片），确认后继续。随后探索代码库的架构、模式、测试布局与构建命令。先写调用方视角的用法示例（放入 examples 或测试位置），再据此推导最少类型与签名并分模块放置，偏好深模块、只在必要处留接缝；每个桩体按语言惯例显式失败（如 panic("not implemented")、unimplemented!()、throw new Error("not implemented")）。运行构建命令直到桩与示例可编译，但不实现行为。
使用方式：向用户以编号列表展示模块边界、用法示例与切片并迭代确认，切片为纵向、可独立演示；在功能分支之外新建分支提交桩与示例并推送，创建以功能分支为 base 的草稿 PR：gh pr create --draft --base <feature-branch> --title "Scaffold: <Feature>" --body "<summary of modules and the usage example>"。合并该 PR 即冻结签名。随后创建 gh label create "project:<slug>" 形式的标签，并写入 docs/plans/<feature>.md 契约：含来源、标签、Scaffold PR 编号、实现顺序（每个切片匹配 PRD 切片并列出旅程编号，每个桩只出现在一个切片下，每个符号一行）与 Notes（仅写代码无法表达的理由、顺序、不变量、坑、约定、鉴权方式，约一屏）。最后询问是否记录反馈。
适用场景：已有 PRD、需要先固定接口与模块边界的单个功能；希望在写实现前冻结签名、让后续工单有据可依的团队。
限制：签名冻结后变更须走 contract-change 而非静默编辑；不实现任何行为；注释仅限仓库规则允许处；Notes 不超过约一屏，能在代码表达的应移入桩；契约中不写签名。所需 PRD 路径、分支名、颜色等具体参数与运行环境未在资料中给出，暂未提供。