dev-pipeline

Dev Pipeline

通过复用现有技能来编排功能的生命周期。你不会在这里实现各个阶段——你会定位当前状态、应用决策规则、执行属于自己的工作，并告诉用户下一阶段的确切命令。

问题跟踪器和 triage 标签词汇表应该已经提供给你；如果没有，请运行 /setup-leandrocfe-skills。

用户调用的技能（to-spec、to-tickets、wayfinder、triage、implement、handoff）只能由用户运行：你的职责是说明何时以及为什么运行。模型调用的技能（grilling、tdd、code-review）由你在正确阶段直接调用。

1. 定位状态

在提出任何建议前，先弄清楚工作处于哪个阶段。自行探索，不要提问：

• 用户的描述是一个新想法？→ 估算阶段。
• 跟踪器中存在 spec，但没有衍生的 tickets？→ 分解阶段。
• 存在未关闭的 issues，但没有 brief/triage 标签？→ triage 阶段。
• 存在已就绪的 issues（带 brief），但没有 branch？→ 派发阶段。
• 存在进行中的 branch？→ 实现或 review 阶段（检查 diff）。

用一句话宣布检测到的阶段，然后从那里继续。如果已有进行中的工作，绝不要从头重启 pipeline。

2. 估算（阶段 0）

新功能首先要进行估算。有三种可能的结果：

大小	标准	路径
琐碎	< ~1h，1–2 个文件，毫无歧义	不需要产物。在当前会话中直接实现（如果仓库使用 PR，则创建 branch + PR）。
小型	可在 1 个会话和 1 个 PR 中完成，范围明确	不需要 spec。编写简短 spec（在跟踪器中创建一个 issue；如果跟踪器是本地 Markdown，则使用 .md），然后直接进入实现。
中型/大型	> 1 个会话，或 > 1 个并行 Agent，或范围存在真正的歧义	完整 pipeline（第 3 节）。
超大型/模糊	尚不清楚如何抵达目标——全新项目，或功能大到连一次会话都无法规划	“运行 /wayfinder”来绘制路线图，并通过决策消除迷雾。路径明确后，它会从 /to-spec 重新进入 pipeline。

黄金法则：> 1 个工作会话，或 > 1 个并行 Agent → 在跟踪器中创建 issues。否则，尽可能精简。 如果无法判断是小型还是中型，只问用户一个问题；不要出于谨慎而扩大范围。

wayfinder 的分界点不在大小，而在于清晰度：如果你能说清楚要构建什么，就走完整 pipeline，无论规模多大；如果你还不知道该先决定什么，就走 wayfinder。

3. 完整 pipeline（中型/大型）

每个阶段都以一个 gate 结束：产出交付物，由用户审查，然后你指出下一条命令。

阶段	执行者	交付物	Gate — 下一步
澄清	你，通过技能 grilling（直接调用）	对话中达成的共同理解	“运行 /to-spec 进行归纳”
编写 spec	用户：/to-spec	跟踪器中的精简 spec	“针对该 spec 运行 /to-tickets”
分解	用户：/to-tickets	按垂直切片划分的 tickets，每个都包含自己的阻塞边	“运行 /triage 进行分类并撰写 briefs”
分类 + 路由	用户：/triage；你在 triage 期间应用第 4 节的表格	带 brief 和 agent:* 标签的 issues	“在 issue #N 上运行 /implement”（指出 frontier 上的第一个，即没有未解决 blockers 的 issue）
实现	用户：/implement；在已约定的 seams 上使用 tdd	Branch + commits + PR	调用 code-review
Review	你，通过技能 code-review（直接调用）	从两个维度（Standards + Spec）检查 diff 后得出的结果	通过 → 合并。存在问题 → 返回实现阶段。
继续	—	—	同一会话中还有更多 tickets → 处理下一个 ticket。新会话 → “运行 /handoff”。结束 → 关闭 spec。

4. Agent 路由与运行时

两个独立维度，在分类阶段确定，并在 issue 上记录为两个标签。

维度 1 — role。 按顺序回答三个问题；第一个回答“是”的问题决定 role：

1. 是否存在尚未确定的设计决策或权衡？ → agent:architect
2. 路径已知，但需要判断？ → agent:builder
3. 机械性工作，没有歧义？ → agent:runner

Advisor 仅在编码前介入（深入探讨、界定范围）。Reviewer 仅在编码后介入（审查阶段）。

维度 2 — runtime。 执行工作的工具/模型。默认映射表（根据你的设置调整；role→runtime 的默认映射记录在此处，例外情况记录在标签中）：

Role	默认 Runtime	理由
agent:architect	Claude Code，顶级模型	深度推理、权衡
agent:builder	Claude Code 中型模型，或 Codex	标准实现
agent:runner	可用的最快/最便宜选项（Codex mini、Grok fast、Haiku）	机械性工作、批量处理

只有偏离默认值时才使用 runtime:* 标签（例如，在 architect 上使用 runtime:codex）。审查规则：尽可能让作者和 Reviewer 使用不同的 runtime/vendor——跨模型审查比自我审查更容易发现缺陷。

这些标签会添加到 issue 上，因此分派时无需重新决定。

跨 Runtime 分派

自包含的 brief 就是接口——任何 CLI 都能在没有额外上下文的情况下接手 issue。两种模式：

• 手动：用户在 issue 的 worktree 中打开标签所指示的 runtime，并指向 brief（gh issue view N）。
• 无头：编排会话通过 shell 分派——例如，在 worktree 内执行 codex exec --full-auto "implemente a issue #N; brief em: gh issue view N"；其他 CLI 也有等效方式。编排器只负责分派和收集；不会与 worker 并行实现。

无论哪种模式，结果都会通过同一渠道返回：引用该 issue 的 branch 和 PR。流水线无需知道、也不需要知道哪个 runtime 生成了 diff。

5. 上下文与并行处理

Agent 无状态，产物有状态。 上下文绝不保留在对话记忆中：

• issue brief 是自包含的——接手 issue 的人不需要其他信息。一个 Agent 可以通过编写 brief 为另一个 Agent 准备工作。
• spec 说明缘由；issue 会链接到它。
• PR 描述 说明完成的工作，供审查使用。
• /handoff 仅用于 issue 中途中断的工作——绝不能替代 brief。

无冲突的并行处理：

• 1 个 issue = 1 个 branch = 1 个 Agent。本地并行处理 → 使用 git worktree。
• brief 列出 issue 会涉及的文件。不要并行分派涉及文件有交集的 issue。
• 依赖关系是 /to-tickets 已记录的 阻塞边——tracker 支持时使用原生功能，不支持时写入正文。只分派当前可推进的前沿：所有阻塞项均已关闭的 ticket。

6. Git

• Branch：feat/<n>-slug-curto（名称中包含 issue 编号）。
• 使用 Conventional Commits；在 PR 正文中添加 Closes #N。
• PR 保持精简（目标：一次审查即可完成），逐步合并。

反模式

• 小型工作不要创建 spec——工作量分级机制就是为此而设。
• tracker 已配置时，不要将 spec 写成散落的 .md 文件——孤立产物没有状态，也没有负责人。
• 不要因为“issue 显而易见”就跳过分类——agent:* 标签和 brief 是无需重新分析即可分派工作的关键。
• 不要在一次回复中累积多个阶段——一次只推进一个关卡；用户需先审阅当前产物，再进入下一阶段。