用途：在范围界定、设计或规格化工作时使用，尤其适用于尚无 Todo issue 的新构建请求，也用于修订 Backlog 规格。即使是用户直接说“build”，新构建请求也从这里开始；但像改文案这类极小且边界清晰的编辑，不应强行走完整 Plan 流程，也不应开 issue，而应说明假设并询问是否需要完整流程。
主要能力：把想法转化为 Linear 中完整的 Backlog 规格；先完整阅读 references/conventions.md，其中定义 preflight、Linear MCP 工具、规格正文模板、层级、依赖与状态规则；再完整阅读并遵循 references/plan.md。硬性要求包括：用户未回答对齐问题或未批准推荐方向前，不得起草规格 issue；每个规格 issue 必须包含精确的 ## Acceptance criteria 章节，并带有可观察的通过/失败复选框；用 Linear MCP 创建和修订规格，最终停在人工批准进入 Todo，不自行写入 Todo。Plan 之后只调用 Build 工作流，不在此实现产品代码。
使用方式：需要托管 Linear MCP，具备 get_issue、save_issue、save_comment、list_comments、list_issues、list_issue_statuses；gh 需对 GitHub 仓库完成认证，以便在收集上下文时读取远程和现有 PR；会话首次写入 Linear 前先运行 references/conventions.md 中的 preflight。
适用场景与限制：适合需要对齐方向、拆分史诗、优先最小可端到端切片的工作。共享原则要求先检查仓库和 Linear backlog 再下结论，一次只问一个聚焦的对齐问题，存在多个可行方向时提出 2-3 种方案，按可演示行为拆分史诗，规格不完整则不可交付，Linear issue 即规格，遇到不确定应显式暴露而非猜测。具体命令与模板细节需查阅上述参考文件，资料未提供完整内容。