objective-to-build-blueprintlisted

## 何时使用 把**一句话目标**变成任何编码 Agent 都能**冷启动执行**的分步施工计划——每一步都带「自包含上下文简报」，一个全新会话里、没读过历史的 Agent 也能直接捡起任意一步开干。 **该用：** - 目标跨越多个 PR 或多个会话才能完成。 - 多个 Agent / 团队成员需要分工共享执行。 - 希望在执行**前**先对计划做一次对抗式评审。 - 步骤间的并行性识别与依赖图很重要。 **不该用（负边界）：** - 单个 PR 就能完成的任务——别上蓝图，直接做。 - 用户明确说「直接做 / just do it」——尊重指令，不要插入规划环节。 - 纯问答 / 纯解释，或还在探索、连目标都没定清的需求。 判据：**3+ 个 PR 或多会话 → 用蓝图；否则不用。** ## 步骤 调用形态（源作约定）：`/blueprint <project> <objective>`。内部走五步流水线： 1. **Research（研究）** —— 扫描代码库、读取项目记忆、跑预检（pre-flight checks），摸清现状与约束。 2. **Design（设计）** —— 把目标拆成**单 PR 粒度**的步骤；识别可并行的步骤、画依赖图；为每步分配合适的模型档位（model tier）。 3. **Draft（起草）** —— 用结构化模板生成计划，把**分支工作流规则、CI 策略、回滚策略**内联写进每一步。 4. **Review（对抗评审）** —— 把计划交给「最强模型」子 Agent 做对抗式评审作为执行前的门禁（该模型不可用时优雅降级到默认模型）。 5. **Register（登记）** —— 保存计划并更新项目记忆，供后续会话/Agent 调取。 ## 指令 每个步骤必须满足「冷启动可执行」——独立写出，无需读前面的步骤： - **自包含上下文简报**：该步要改什么、为何改、前置状态、涉及文件、约束，全部就地写清。 - **单 PR 粒度**：一步 = 一个可独立合并的 PR；太大就拆，太碎就并。 - **内联工程纪律**：分支命名/创建流程、CI 必过项、失败回滚策略，写进步骤本身而非散落别处。 - **并行与依赖**：标注哪些步骤可并发、哪些被谁阻塞（依赖图）。 - **计划变更协议（Plan mutation protocol）**：步骤可被**拆分 / 插入 / 跳过**，但须留**审计痕迹**（audit trail），保证计划可追溯演进。 关键差异点（保留源约束）： - **零运行时风险**：纯 Markdown 产物——无 hook、无脚本、无可执行代码。 - **对抗评审门禁**：执行前必须过一次最强模型评审。 - **优雅降级**：自动探测 `git` / `gh` 可用性，缺失时降级而非报错。 ## 示例 ```bash # 示例 1：数据库迁移 /blueprint myapp "migrate database to PostgreSQL" # 示例 2：插件抽取 /blueprint antbot "extract providers into plugins" ``` 单步简报（冷启动）的最小骨架： ```markdown ## Step 3 — 抽取 provider 接口到独立插件（可并行：是；依赖：Step 1） 上下文：providers 现位于 src/core/providers/*，已在 Step 1 完成接口定义。 目标：把 X pr