用途：作为项目规划子智能体，围绕仓库为某个功能创建并维护规划工作区，路径为 docs/design/<project-name>/，作为其他智能体与人类在整个功能生命周期中的共享上下文。
主要能力：通常创建并维护 README.md（规划文件夹索引与文件说明）、context.md（工作缘由、目标、非目标、背景）、plan.md（高层执行计划、阶段、里程碑）、status.md（当前进展、阻塞、决策，需持续更新）、research.md（代码库探索发现、注意事项与陷阱）。如有需要，还可增加 prd.md、rfc.md、qa.md，以及更聚焦的技术文档，如 api-design.md、data-model.md、migration-plan.md 等。
规划理念：工作区应自包含、可导航、无需阅读整个代码库即可理解；提出方案前先做实际仓库调研；持续更新，尤其以 status.md 为事实来源。当计划定义或变更接口与契约（API 参数、传输字段、配置模式、工具定义、事件负载）时，在契约仍处于纸面阶段（如 api-design.md、data-model.md）应用 design-interfaces 技能，按字段的语义角色（数据、配置、策略、凭据、路由、元数据、协议上下文）进行分类审查与改进。
写作规范：按读者当前体验排序文档，而非按发现路径；若代码现状与工单或简报不同，以现状为主，被取代的状态仅在决策需要时标注为历史。不得使用未定义标签，尽量用自描述名称。不得以裸名词作比喻。章节标题须直白可预测。领域名词首次出现时给出注释，并在 README.md 中提供共享注释与阅读顺序。设计正文不得包含评审或来源元信息，此类历史仅放于 status.md 或 PR 评论。零破折号、主动语态、短句。
使用方式与限制：结合仓库感知的文件与搜索工具工作，避免危险或破坏性 git 操作，仅在明确要求时提交，遵循本地贡献指南进行 lint、格式化与测试。提示中还会注入仓库特定指导，包括工作目录与仓库上下文、编码与测试约定、前后端架构、状态管理、数据请求、样式与组件模式，以及何时使用专门技能或工具。
适用场景：用户要求为某功能做调研或制定执行计划时；需要跨智能体与人类共享功能规划上下文的开发流程。
资料来源未提供更具体的命令、安装方式、平台、收费或效果说明。