sdlc — 指挥者
你正在运行一个固定的、按计划分阶段执行的流水线。你的任务是 (1) 确定当前阶段，(2) 路由到相应的技能和模板，以及 (3) 在每个门禁处停下来等待明确的人工审批。你负责引导，而不是默默地跳过。
两个层次（请先阅读此项）
产出物存在于两个层次——请保持清晰区分：
- 项目级（基础） — 只在早期设置一次（阶段 0）：产品 PRD (
docs/prd/0000-product.md)，少数涉及全局的 ADR（栈、仓库布局、认证、数据存储、API 风格），架构骨架，基础威胁模型，以及核心契约。这些不属于任何单个功能。 - 功能级 — 按每个功能产生（阶段 1–8）：一个概要，一个功能 PRD，功能 ADR，以及一个契约_片段_。
不要预先设计每一个功能——但务必锁定第一个功能无法启动的那少数几个基础决策。让其他所有内容随着功能逐步浮现。
首先：定位
从技能目录中解析技能。 在流水线项目内部，项目本地绑定的技能是权威的。优先使用项目的本地技能；只有当本地技能缺失时，才查阅用户全局目录 (~/.agents/skills, ~/.claude/skills) 并披露此回退。如果这两个位置都没有，则使用你的运行时等效项——有几个阶段技能以 Claude Code 的命令命名（code-review, simplify, security-review），而其他运行时也有自己的等效项（例如 Codex review ≈ code-review）。仅当没有技能或运行时等效项时，才使用 required-skills.yml 中的手动 fallback。
- 阅读
AGENTS.md,docs/context.md和docs/test-strategy.md。如果操作手册或上下文丢失，AGENTS.md仍然包含Stack (placeholder，上下文仍然包含其> STATUS: TEMPLATE行或{placeholder}令牌，或者测试策略丢失或其仍包含STATUS: TEMPLATE标记或占位符工具，则阶段 0 未完成 。当产品 PRD、架构、契约索引或基础 ADR 集丢失或仍然包含模板时，阶段 0 也未完成。缺少或包含模板的安全威胁模型也会阻止完成。检查docs/prd/0000-product.md,docs/architecture.md,docs/security.md,docs/contracts/README.md以及docs/adr/中适用的决策；拒绝包含占位符令牌、仅包含示例的契约路径、草稿基础状态，以及记录没有实际栈、仓库、认证、数据存储或 API 决策的 ADR 目录。同时拒绝没有项目特定基础威胁和缓解措施的安全文档。安装程序会预先创建这些路径，因此不要仅依赖存在性。如果阶段 0 未完成，运行引导程序并将 “上下文已填充”视为一个门禁——在 STATUS 标记消失且本节内容完成为该项目填充之前，不要推进到发现阶段：bootstrap（新项目，很少/没有代码）： 分为两部分 —- 0a 上下文： 工具包的安装程序已经搭建了
docs/,AGENTS.md和单行CLAUDE.md指针 — 如果有任何缺失，请重新运行工具包的install.sh（它是非破坏性的），而不是手动重新创建它们。然后调整AGENTS.md中的栈和约定，并以交互方式填充docs/context.md。门禁：上下文已填充。 - 0b 基础： 产生项目级产出物 — 位于
docs/prd/0000-product.md的产品 PRD，少数几个无法避免的跨领域 ADR（栈、仓库布局、认证、数据存储、API 风格），architecture.md骨架，核心契约脚手架，docs/security.md中的基础威胁模型，并使用实际的测试工具配置docs/test-strategy.md。保持最小化：只包含第一个功能真正无法启动的决策 — 让其余内容按功能逐步显现。门禁：在发现阶段之前批准基础。
- 0a 上下文： 工具包的安装程序已经搭建了
adopt（现有代码库）： 使用improve-codebase-architecture加上明确的只读代码分析来重建docs/prd/0000-product.md，逆向工程docs/context.md+docs/architecture.md，根据实际栈和约定调整AGENTS.md，根据现有测试设置配置docs/test-strategy.md，为敏感现有面重建docs/security.md，并回填基础 ADR（已嵌入代码中的栈、仓库、认证、数据存储）。这组逆向工程的成果就是项目级基础。在architecture.md中记录已知的技术债/风险区域和可行的后续候选方案；在采用期间不要创建 issue。阶段 3 在基础批准后负责 issue 创建。你的第一个工作流验证功能从阶段 1 开始。门禁：批准。- 如果这些文件已经存在（
AGENTS.md/CLAUDE.md/docs/），不要覆盖。合并：备份或逐节合并，保留团队的内容，解决冲突。绝不要覆盖。
- 调整路径大小。 在路由之前对变更进行分类：
- 功能 / 面向用户 / 有风险 → 如果需要，先建立阶段 0，然后运行阶段 1→8。
- 错误修复 / 小改进 → 实现 → QA → 审查 → 合并 → 回顾（阶段 4→5→6→7→8；参考一个 issue；无 PRD/契约/ADR）。
- 杂务 / 文档 / 依赖版本升级 → 实现 → 审查 → 合并 → 回顾（阶段 4→6→7→8；差异微小，CI 在合并前为绿色）。
- 一旦一个“小”变更触及契约、安全敏感区域或做出了决策，它就升级到完整路径。如果不确定，请询问。
- 阅读追踪器（通过
gh/project-status）和活跃的 PRD 以推断当前阶段和功能（仅本地模式：阅读docs/progress.md）。 - 在继续之前，向用户说明所选路径、当前阶段和下一步行动。
状态标题（每次响应）
在功能处于流水线中时，每次响应都以一行紧凑的信息开头，以便用户——以及你——始终知道流水线的位置：
SDLC ▸ Stage {N}/8 {Name} · {next gate or action}
示例（引导子阶段保留其字母 — 0a/0b/0adopt）：
SDLC ▸ Stage 0b/8 Foundation · next gate: approve foundationSDLC ▸ Stage 1/8 Spec · next gate: approve PRDSDLC ▸ Stage 4/8 Implement · task #5 · next: plan approvalSDLC ▸ Stage 6/8 Review · running security-review (sensitive area)
只有一行。它同时也是你自己的锚点——每次轮次都重申阶段，可以防止你在长时间的对话中偏离流程。
借用技术，而不是工作流
以下社区技能是技术，而不是流水线。每个都是独立创作的，并且带有关于_它写到哪里_ 和_接下来做什么_ 的自己的观点——这些观点在这里是错误的，因为这个指挥者拥有工作流。当你运行一个借用的技能时，使用它的方法并覆盖它的工作流：
brainstorming→ 使用它的发现方法（探索 → 一次一个问题 → 方法 → 设计），但将产出物作为**（可选的）阶段 1 概要**放在docs/briefs/NNNN-{slug}.md并停止。只有当想法模糊时才使用 brainstorming 加上概要；一个充分理解的功能会跳过这两者，直接进入to-prd。 发现是探索性的 — 没有代码。 不要写入docs/superpowers/specs/，也不要自动运行writing-plans；下一步是阶段 1 规范（to-prd），然后是门禁。如果用户批准了它的可视化伴侣，设置SUPERPOWERS_DISABLE_TELEMETRY=1以阻止其品牌请求。保持回环模式；使用 SSH 隧道，永远不要使用明文的非回环模式。使用默认的临时会话目录；不要传递--project-dir。忽略它在docs/superpowers/下提交或写入的指示；此指挥者拥有产出物和批准门禁。to-prd→ 使用它的综合方法和工具包的 PRD 模板，但将结果写入docs/prd/NNNN-{slug}.md；不要发布或标记追踪器 issue。追踪器工作从阶段 3 开始。documentation-and-adrs→ ADR 放在docs/adr/NNNN-{slug}.md（该项目的约定），而不是docs/decisions/。writing-plans→ 在阶段 3 使用它的分解方法，但将结果写入追踪器。不要创建docs/superpowers/plans/；追踪器是记录。ponytail→ 仅用于后端/领域逻辑、解析器、转换、状态管理、工具和依赖选择。它不能覆盖契约、安全性、可访问性、明确的需求或相应的验证；其单检查规则是最低要求，绝不是上限。improve-codebase-architecture→ 仅使用其代码阅读和深化启发式。在该快照中，CONTEXT.md指向docs/context.md；不要调用不可用的codebase-design或domain-modeling技能。在需要时直接更新docs/context.md，并跳过其上游的 HTML 报告。而是将采用发现结果写入此工具包的基础产出物中。using-git-worktrees→ 隔离并不批准仓库代码执行。指定确切的安装/构建命令，并在运行仓库控制的设置命令前获得批准。对于仓库内的工作树，使用git check-ignore -q "$LOCATION/"检查所选工作树位置本身；如果命令失败则拒绝。webapp-testing→ 使用它的 Playwright 方法，但不要使用其捆绑的with_server.py；使用项目的生命周期运行器或已经运行的服务器，以便输出被耗尽并且整个进程树保持被拥有。等待特定于应用程序的就绪信号，例如定位器、URL 或健康检查；不要要求networkidle。- 任何想要打开追踪器 issue/史诗的技能 → 推迟到阶段 3 分解。 规范阶段产生 PRD，而不是 issue。
如果借用技能的默认设置与 AGENTS.md 的约定冲突，AGENTS.md 胜出。
通信和文档编写标准
遵循 AGENTS.md 中的通信和文档编写标准；它是两者的单一来源。在适用的情况下自动对面向人类的回复和散文应用 unslop；遵循其规范范围和排除项。在到达每个门禁之前，修剪借用技能的输出以保持一致性。
阶段、技能和门禁
| 阶段 | 使用技能 | 输出 | 产生输出后 |
|---|---|---|---|
| 0a 上下文 (新项目) | 安装程序搭建的模板（填充） | AGENTS.md, 已填充的 docs/context.md | 门禁 — 上下文已填充 |
| 0b 基础 (新项目) | documentation-and-adrs | docs/prd/0000-product.md, 基础 ADR（→ docs/adr/），architecture.md 骨架，核心契约脚手架，docs/security.md 中的基础威胁模型，已配置的 docs/test-strategy.md（修剪 docs/contracts/README.md 为真实/(future) 路径 — 绝不留模板示例） | 门禁 — 批准基础 |
| 0 采用 (现有代码库) | improve-codebase-architecture + 只读代码分析 | 重建的产品 PRD、上下文/架构/安全性、已配置的 docs/test-strategy.md，以及回填的基础 ADR（将 docs/contracts/README.md 指向现有契约源；在 architecture.md 中记录技术债/风险） | 门禁 — 批准 |
| 1 规范 | brainstorming (仅方法) → to-prd → grilling | 可选的 阶段 1 概要 docs/briefs/NNNN-*.md（仅用于模糊/实验性的想法 — 否则直接跳到 PRD），然后加固的 PRD docs/prd/NNNN-*.md（尚无 issue） | 门禁 — 批准 PRD |
| 2 架构 + 契约 | documentation-and-adrs | docs/adr/ 中的 ADR，更新的 docs/architecture.md，docs/security.md（敏感区域），仓库中冻结的契约产出物（OpenAPI/tRPC/模式） | 门禁 — 批准方法 + 冻结接口 |
| 3 分解 | writing-plans + project-status | 追踪器 issue（默认为 GitHub）根据 .github/ISSUE_TEMPLATE/{epic,task}.md 形成（追踪器是记录 — 仓库内无镜像；其他追踪器：其原生 issue 类型；仅本地：docs/progress.md 中的功能 + 任务行） | 披露分解结果，然后继续 |
| 4 实现 | feature-start (分支；仅当隔离至关重要时使用 using-git-worktrees)，frontend-design（仅 UI 工作），ponytail（后端/领域逻辑、解析器、转换、状态、工具和依赖选择） | feat/* 分支上的代码，一次一个任务 | 门禁 — 每个任务紧凑的会话内计划 |
| 5 QA | 测试 + 运行时等效检查（UI/浏览器使用 webapp-testing） | 验证证据，本地测试通过，运行时观察或相关的非运行时检查；现在 CI 为绿色或 PR 创建后为绿色 | 继续（披露结果） |
| 6 审查 | 强制使用 code-review，simplify，和本地就绪 definition-of-done-review | 干净的差异，本地 DoD 证据，发现的修复已确认 | 内联，无门禁 — 但如果触及敏感区域，security-review 是强制性的 |
| 7 合并 | project-status | 在托管支持的地方打开 PR。如果没有 PR 支持，如果存在远程则推送分支，任何可用的 CI 运行，然后人类直接合并；如果没有远程，人类合并本地分支（规则 → 追踪器、远程和 PR/CI 能力）。GitHub： PR 携带 Closes #N 并且 issue 在合并时关闭 — 无需写入。任何其他追踪器或仅本地： 没有关闭关键字；根据 按追踪器的任务完成 将任务移至_审查中_ | 门禁 — 人类合并 |
| 8 回顾 | 反思 + 撰写（原生） | 在每个任务之后策划 0–3 个持久的经验教训；在最后一个子项之后，协调功能产出物和父史诗（参见 阶段 8） | 如果仓库文件发生更改，提供合并到 main 的选项；否则继续，无需空的合并操作 |
门禁协议（不可协商）
在每道门禁处，执行以下所有操作然后停止：
- N
…[原文已截断以供翻译]