用途：把单个功能的 PRD 转成技术设计方案，用 markdown 签名而非可编译代码描述类型与接口，放在 docs/plans/<feature>.md。一次只处理一个功能。
主要能力：读取 docs/prds/<feature>.md，若无 PRD 则通过简短访谈现场生成核心内容并写入 PRD；探查代码库架构、命名与测试布局；先按每条 journey 写调用方视角的使用示例，再据示例反推每个交付切片所需的最小类型、函数、路由、迁移与集成接口；用 codebase-design 词汇判断边界，偏好深模块，仅在行为需变化或需独立测试处设缝；发现 PRD 决策不成立时列出并询问用户是改 PRD 还是记入方案 Notes 的 PRD drift；切片间不允许前向引用，新符号用 new: 块写完整签名，改动现有符号用 change: 列出。
使用方式：按流程依次定位输入、探查代码库、写使用示例、按切片推导签名、向用户列模块边界与切片并反复确认、确定功能分支与标签。分支取用户指定，否则取启动时检出的分支；若为默认分支则建议 feature/<slug> 并询问，方案只记录名称，不创建分支。标签用 gh label list --search "project:<slug>" --json name -q '.[].name' | grep -qx "project:<slug>" || gh label create "project:<slug>" -d "<Feature> (docs/plans/<slug>.md)" -c "<any unused hex>"。最后写方案、核对覆盖、运行 git check-ignore -q docs/plans/<feature>.md 并说明是本地还是提交，结尾询问是否记录反馈。
适用场景：已有一份 PRD、希望先冻结接口设计再并行拆票的团队流程。
限制：仅产出 docs/ 下文档，不写 stub、不开分支、不构建。一次只处理一个功能，多个 PRD 且目标不明时须先询问用户。方案覆盖已存在时须先展示差异并获确认才覆盖。除资料所述外，未提供其他收费、平台或效果信息。