relay-plan

输入

• 环境：可选的 RELAY_SKILL_ROOT，默认值为 skills。
• 文件：relay-ready 交接内容、问题/用户文本、可选的本地任务文本、可选的本地执行框架上下文（AGENTS.md、CLAUDE.md、CHARTER.md、spec/capabilities.md、当前迭代说明）、可选的 /tmp/done-criteria-<N>.md、/tmp/dispatch-<N>.md，以及名称兼容的 /tmp/rubric-<N>.yaml 评估产物。
• 同级脚本：${RELAY_SKILL_ROOT:-skills}/relay-plan/scripts/probe-executor-env.js、${RELAY_SKILL_ROOT:-skills}/relay-plan/scripts/persist-done-criteria.js、${RELAY_SKILL_ROOT:-skills}/relay-dispatch/scripts/dispatch.js。

Relay Plan

适用场景

• 为 relay 运行构建审查锚点、结构化评估渠道和分派提示词
• 将任务意图、明确的 AC、仓库信号和风险转化为可审查的 Done Criteria
• 在分派前保存由规划者编写的 Done Criteria

不适用场景

• 规划前梳理模糊任务 — 使用 relay-ready
• 将实现工作委派给执行器 — 使用 relay-dispatch
• 审查执行器的输出 — 使用 relay-review
• 合并已审查的 GitHub 更改 — 使用 relay-merge

relay-plan 仅生成交接产物；由 relay 或操作人员运行 relay-dispatch。

默认流程

1. 阅读任务

在读取任务证据前，先使用 /relay 的来源门控所选定的路径。无远程仓库的 Git 检出属于本地 Reviewed Result 交付，必须使用本地任务文本或用户描述，不得查询 forge。受支持的 GitHub 路径可在通过来源门控后使用 gh 获取问题文本。

读取所选路径的规范化任务来源：

• 存在 relay-ready 交接摘要时：~/.relay/requests/<repo-slug>/<request-id>/relay-ready/<leaf-id>.md
• 带有问题编号的 GitHub 路径：通过来源门控后运行 gh issue view <N>； 如果查询失败，则必须停止，不得回退到本地文本。
• 不带问题编号的 GitHub 路径，或本地路径：本地任务文本或 用户提供的描述。本地路径不得查询 forge。

如果 relay-ready 生成了交接摘要，则将其视为事实来源，不要重新读取原始请求。 对于已梳理的叶任务，使用持久化的 relay-ready/<leaf-id>.md 及其冻结的 Done Criteria 路径； 原始请求仅作历史背景，不得在未说明的情况下重新解读为不同任务。 如果 relay-ready 锚点不完整，应明确指出模糊之处，或在第 7 步保存由规划者编写的 Done Criteria。

2. 收集规划信号

node "${RELAY_SKILL_ROOT:-skills}/relay-plan/scripts/probe-executor-env.js" . --project-only --json

仅将仓库本地质量信号和与任务相关的本地执行框架上下文作为弱输入来读取。它们可为措辞、前置条件、命令和查找位置提供参考；但不会阻止分派，也不会覆盖任务要求。字段含义和权威层级：references/signals.md。

3. 规范化规划输入

在写入审查锚点之前，将明确的 AC、推断出的 Done Criteria、relay-ready 交接内容、项目执行框架上下文、仓库信号、可选的子系统探查记录以及任务风险保留为独立的证据渠道。

4. 梳理 Done Criteria

确定评估来源模型：

• 任务来源中的明确 AC（如有）
• 根据用户意图、问题正文、relay-ready 交接内容和附近的仓库惯例推断出的 Done Criteria
• 来自探查、可用命令和与任务相关的惯例的仓库信号
• 特定任务的风险，包括涉及的领域、信任边界、数据丢失、迁移、UX 流程或运维故障模式

如果 AC 缺失、含糊或不完整，请先编写可观察的 Done Criteria。将明确的 AC 视为高优先级证据，而非唯一来源。冻结之前，运行飞行前模糊性审查。如果最终审查锚点由规划者编写，或与任务来源不同，请在第 7 步保存。

5. 构建评估渠道

根据 references/evaluation-channels.md，将结果契约、验证和可选的已获评估标准分开。冻结的完成标准即为契约。最小产物：

evaluation:
  schema_version: 2
  outcome_contract:
    source: done_criteria
  verification:
    checks:
      - name: Focused behavior passes
        type: command
        command: "<task-specific command>"
        target: "<observable pass condition>"
  earned_rubric:
    factors: []

测试、构建、类型检查、lint、产物是否存在及其他二元证据都归入验证。已获评估标准因素为零也是有效的。只有在梯度、可观察、可操作和有后果这四项全部成立时，某个因素才算获得；在进行任何可选的数值映射前，先使用定性的弱／合格／强锚点。参见 references/evaluation-channels.md。 先观察，再推导质量：识别产物、目标用户、使用场景和可用界面，然后使用 references/observation-lenses.md 中的可选问题。

6. 验证并简化各渠道

交接前快速检查：结果契约中的条目均为二元且可观察；验证检查项均指明具体证据；已获评估标准可以为空，且不包含常规卫生检查。完整清单：references/rubric-validation.md。

持久化前，应用 references/rubric-simplification.md：将 HOW 改写为可观察的 WHAT，合并重叠内容，移除缺乏依据的防御性条款，并核验权重。

7. 必要时持久化由规划器编写的完成标准

仅当规划阶段编写了最终完成标准，或扩展、拒绝或缩小了问题正文中的 AC 时，才进行持久化。这包括输入缺少 AC、用户提供的描述，以及规划阶段更改问题正文 AC 的任何情况。

将最终字节写入明确路径，其父目录必须已存在且不是符号链接。此步骤不会分配运行 ID，并会拒绝将输出写入 ~/.relay/runs；调度时才会创建运行并冻结这些字节。

node "${RELAY_SKILL_ROOT:-skills}/relay-plan/scripts/persist-done-criteria.js" \
  --output /tmp/done-criteria-<N>.md --file /tmp/done-criteria-source-<N>.md --json

如果问题或 relay-ready 交接已提供最终完成标准，且规划器未做更改，则跳过此步骤。

8. 生成交接产物

将调度提示词和评估 YAML 写入临时文件。提示词使用 ../relay/references/prompt-template.md，并附加 Setup、可选的 Working Guidance、Evaluation Channels 和 Completion Responsibilities。通过兼容性命名的 --rubric-file 传递评估产物；references/iteration-protocol.md 定义了精简的证据与交接契约，以及可选的 TDD 风格。

所有执行器都使用相同的提示词模板和完成职责。执行器的适配器保留其实际调用工具；提示词内容不会选择不同的结果或验证契约。

返回交接摘要，其中包含调度提示词路径、rubric YAML 路径、持久化时的完成标准锚点路径，以及推荐的 relay-dispatch 命令。

如果第 7 步持久化了完成标准，调度交接必须保留两个锚点：

node "${RELAY_SKILL_ROOT:-skills}/relay-dispatch/scripts/dispatch.js" . \
  --branch issue-<N>-<slug> --prompt-file /tmp/dispatch-<N>.md --rubric-file /tmp/rubric-<N>.yaml \
  --done-criteria-file <done-criteria-path>

不要从 relay-plan 运行 relay-dispatch。

风险触发的附加项

仅在任务证据足以支持时使用附加项；不要将参考清单照搬到提示词中。

• 评分标准模板脚手架：读取 references/rubric-templates/_index.json，然后选择其 signals（test_infra、type_check、lint_format）与步骤 2 探查输出有重叠的模板；若没有重叠，则根据任务编写评分标准。模板只是供手动调整的起始脚手架，绝不会自动应用，也不是契约。
• TDD 风格因素：仅当先红后绿测试适用于某个因素时，该因素才带有 tdd_anchor: <test path>（可选 tdd_runner）——行为明确、路径具体，且运行器能够针对该路径运行。若步骤 2 探查报告了可用的测试运行器，而某个自动化契约因素尚无锚点，则建议添加；文档、散文、UI 判断和宽泛的设计因素不添加锚点。无法解析运行器的 tdd_anchor 因素会在步骤 0a 前失败关闭：references/iteration-protocol.md。
• task_profile 或工作指南：references/task-profile.md 和 references/guidance-packs.md。
• 领域评分标准构想：references/rubric-domain-axes.md。
• 以观察为先的领域问题：references/observation-lenses.md。
• 信任边界和失败关闭行为：references/rubric-trust-model.md 和 references/rubric-fail-closed-patterns.md。
• 文件／路径精确性、禁止区域、事件结构变更或 TDD 风格因素：references/rubric-patterns.md。
• L／XL 任务存在歧义或子系统边界不明确：考虑通过 references/subsystem-scout.md 进行只读侦察；范围明确的 S／M 任务可跳过。
• 新颖、模糊、高风险或容易被钻空子的完成标准：通过 references/rubric-stress-test.md 进行一轮压力测试；任何规模的任务都可因歧义或风险而选择压力测试。
• 根据评审反馈重新分派：保持原有锚点不变；先前尝试的证据和评审者反馈会自动前置。迁移期间仍可读取旧版 Score Log 文本，但执行者撰写的分数不属于评审证据。