prd-create

改编自 vfarcic/dot-ai 的 shared-prompts/prd-create.md（MIT，版权所有 (c) 2025 Viktor Farcic）。原作者：Viktor Farcic。范围界定和切片规则借鉴了 Matt Pocock 的 mattpocock/skills（MIT）中的理念：示踪弹式垂直切片、阻塞边和深模块。

PRD 创建斜杠命令

说明

你将协助为新功能创建产品需求文档（PRD）。此流程包含两个主要部分：

1. GitHub Issue：简短、不可变的概念说明，链接到详细 PRD
2. PRD 文件：包含里程碑跟踪和实施计划的项目管理文档

流程

第 1 步：了解预期结果（不进行访谈）

根据用户的描述自行推断预期结果。不要进行访谈，也绝不要询问用户代码应如何编写或组织：技术选择由你决定，并将其理由记录在决策日志中。

• 查找事实，不要询问。 阅读代码、文档、Issue 和现有 PRD。先检查相关能力是否已存在或此前是否曾被提出后否决（已关闭的 Issue、prds/done/、决策日志）。
• 最多提出一个合并问题，且仅限于尚未明确的产品意图，或选项会改变用户所得结果的分歧。为每个问题提供建议答案。若请求明确，则跳过。
• 现有升级处理规则仍照常适用：外部 API 契约变更、影响现有数据的架构变更、身份验证或安全模型变更、不可逆操作。仅仅涉及安全代码的工作应交由设计评审阶段（agent-team），而不是询问用户。
• Bug PRD 应指出能证明 Bug 存在的复现信号（失败的测试、命令或捕获的跟踪记录），或说明目前为何没有此类信号。

第 1.2 步：范围审核（创建任何内容之前）

一个 PRD Issue 对应一次实施运行和一个 PR（一次 uzi 运行，或一个 /prd-full 循环；仅涉及文档的 PRD 可按 /prd-done 直接提交完成）。在 PRD 内调整里程碑不会缩小该 PR；只有拆分出更小的 Issue 才能缩小。因此，应评估 Issue 的规模，而不仅是其里程碑：

• 一个 PRD = 一个可独立体现价值的结果。 只有当一个切片本身有用时，才为其单独创建 PRD；否则应将其保留为某个 PRD 内的里程碑。
• 范围审查警示（并非自动拆分条件）：存在多个可独立体现价值的结果，或预计 PR 较大（涉及许多组件或文件清单很长）。触发任一警示时，应向用户提议拆分为多个可独立体现价值的 PRD，并说明顺序，作为一个是非问题提出。
• 硬性错误：某个里程碑依赖尚未完成的 PRD。 将其移至后续 PRD，或重新划定边界；绝不能让它留在当前 PRD 中等待。
• 拆分工作应创建一个总 Issue，仅用于列出其子 PRD、执行顺序及阻塞关系；每个子 PRD 都是由此技能创建的常规 PRD。将子任务交给 uzi 时，默认选择 Auto 或 Seed & ship 模式，以便用户只需批准一次拆分，而不必逐一批准每个子计划。
• 现有未关闭的 PRD 在派发前也必须进行相同的范围审查（由 /prd-start 执行）。

拆分路径（用户接受拆分时）

1. 在创建任何内容之前，只询问一次 Step 1.5 中的下一步和审查问题，并将答案（包括任何 uzi 模式或 sweep 标签）用于每个子项。
2. 创建总议题：一个不带 PRD 标签和 sweep 标签的普通议题。其正文按顺序列出各子项的预期结果及其阻塞依赖；不包含里程碑。
3. 按依赖顺序，为每个子项执行 Steps 2-5，将其作为常规 PRD 创建（各自拥有一个带 PRD 标签的议题和一个独立的 prds/ 文件），然后将每个子项的链接添加到总议题。
4. 只对阻塞项已完成的子项执行下一步。阻塞项未完成的子项只提交并推送，不做其他操作：不开始工作、不发送给 uzi、不添加 sweep 标签。阻塞项关闭后，按记录的相同选择激活该子项。

Step 1.5：提前记录 PRD 后续工作流（在创建任何内容之前）

创建议题或 PRD 之前，检查 uzi 是否可用（command -v uzi 成功，或 uzi-cli 技能已安装在 ~/.claude/skills/uzi-cli/）。如果 uzi 可用，还要运行一次 uzi schedule list --json，确认是否存在任何 sweep 计划及其标签——这决定了下方的 Commit & push + queue for uzi sweep 选项是否可用以及标签如何选择。然后立即连续收集所有后续选择，避免之后编写 PRD 时受到打断：

1. AskUserQuestion（下一步 + 审查），在一个提示中提出两个问题：
   • 下一步：Start working now、Commit & push for later，以及仅在检测到 uzi 时提供 Commit & push + queue for uzi sweep 和 Send to uzi。（无 uzi 时提供 2 个选项，有 uzi 时最多提供 4 个。）Commit & push + queue for uzi sweep 是一种延后交接（参见选项 4）：它与 Commit & push for later 一样提交并推送，然后为议题添加标签，以便之后由 uzi sweep 计划执行，不会立即启动运行。只有在检测到 uzi 且 uzi schedule list --json 报告至少一个 sweep 计划时，才提供该选项。
   • PRD 审查：No review、One reviewer 或 Let the skill decide（由技能根据 PRD 的规模和复杂度决定审查人数）。用户可以选择“Other”并指定确切人数。
2. 在第一个提示之后立即提出所需的第二个 AskUserQuestion，并且必须在编写 PRD 之前（不要推迟到 PRD 创建之后）：
   • 如果用户选择了 Send to uzi：加载 uzi-cli 技能，并使用其中的 Send to uzi 菜单询问 uzi 模式（Auto / Supervised / Seed & ship / Custom）。
   • 如果用户选择了 Commit & push + queue for uzi sweep，且 uzi schedule list --json 显示多个 sweep 计划：询问要排入哪个 sweep 标签（例如 Night、bug）。如果只有一个 sweep 计划，则使用该计划，不必询问。

保留所有答案，并在 PRD 创建之后再据此执行：先进行审查，然后执行所选的下一步（若选择 Send to uzi，使用此处已选定的模式；不要再次询问）。不要在最后提供编号菜单。如果以非交互方式运行（没有用户可供询问），则默认选择 Commit & push for later 和 No review。

如果选择的下一步是 Send to uzi 或 Commit & push + queue for uzi sweep，PRD 必须包含离线工作者所需的全部信息（这两种方式都会将 PRD 交给 uzi 工作者——sweep 选项通过计划任务而非立即运行来执行）。uzi 工作者的出站网络访问受到限制：允许列表可访问代码托管平台、*.anthropic.com 和软件包缓存，但无法访问开放网络（不能随意访问 GitHub 或外部文档网站，也不能使用 WebFetch/WebSearch）。因此，工作者无法进行任何需要互联网的调查。所以在编写 PRD 时（Step 5），现在就提前完成所有需要联网的调查，并将调查结果作为已确认的事实写入 PRD 正文——绝不能留下“实施者将在线确认 X”之类的里程碑。参见 Step 5 中的说明。

步骤 2：先创建 GitHub Issue

立即创建 GitHub Issue，以获取 Issue ID。正确命名 PRD 文件需要使用此 ID。

重要：为 Issue 添加「PRD」标签，以便于查找。

步骤 3：使用正确的命名方式创建 PRD 文件

使用实际的 GitHub Issue ID 创建 PRD 文件：prds/[issue-id]-[feature-name].md

步骤 4：使用 PRD 链接更新 GitHub Issue

文件名确定后，将 PRD 文件链接添加到 GitHub Issue 描述中。

步骤 5：将 PRD 作为项目管理文档来编写

按照 PRD 模板开展工作，重点关注项目管理、里程碑跟踪和实施规划。文档更新应作为实施里程碑的一部分。

🔴 如果已选择 Send to uzi 或 Commit & push + queue for uzi sweep（步骤 1.5）：现在就在 PRD 正文中解决依赖互联网的调查事项。 uzi worker 无法访问开放网络（出口访问受限：仅限 forge、*.anthropic.com 和软件包缓存）。里程碑依赖的任何只能通过开放网络获知的信息——外部 API 或库的语义、必须浏览而非克隆的上游源代码、文档页面、网络搜索、CVE 查询——worker 都无法获取，因此里程碑会停滞，或者 worker 只能猜测。在移交之前：

• 在本地完成查询，并将答案作为明确事实及其来源写入 PRD，而不是把它列为任务。将「确认 widget API 是否受速率限制」改为「widget API 的速率限制为每分钟 N 次，见 <link>，因此 M2 必须进行退避。」
• 在可行时优先采用可离线验证的方式：基于产品自身数据或日志进行实测，或阅读代码库，胜过外部查询；这样 worker 无需访问网络即可重新验证。在里程碑中注明此类检查可离线完成。
• 如果确实无法在不访问互联网的情况下确定某个关键事实，请在发送前自行确定，否则 PRD 尚未准备好交给 uzi。 如果有任何事实仍未能确定，请明确标出，不要提交一个暗中依赖这些事实的里程碑。

PRD 文件章节

以下是 prds/ 文件的各个章节。后文的「GitHub Issue 模板」仅用于填写简短的 Issue 正文，并非 PRD 文件。

1. 问题：从用户的角度说明谁会遇到问题，以及问题是如何发生的。
2. 结果：说明完成此 PRD 后哪些功能可用，并提供 2–3 个具体的验收示例（输入、操作、可观察到的结果）。用户只需阅读这些内容就能提出异议。
3. 范围之外：说明此 PRD 明确不包含哪些内容，包括移至后续 PRD 的事项。
4. 模块与边界：仅列出关键模块。对每个模块，说明面向调用方的接口（输入、输出、不变量、错误行为）、它隐藏的复杂性，以及测试会覆盖的位置。优先使用现有边界和接口；只有在有明确需求时才新增。
   • 接受不可信输入的模块必须说明其资源限制：对于调用方可消耗的每项资源（存储字节数、解压后的内存占用、数据库连接数和并发量、后台工作量、运行时间），说明限制值及其执行位置。任何会影响其他所有者的不可逆操作（删除、回收、收费），都不得在声明值经过验证之前执行。
   • 复用现有组件的安全保障方案（克隆路径、上传模式、限流器）时，须说明这些已接受的风险对本 PRD 的调用方是否仍然适用；针对管理员控制的输入所接受的风险，并不自动适用于用户或产品可控的输入。
5. 测试决策：说明在哪些边界测试哪些行为，以及应参考哪些类似的现有测试。
6. 里程碑：按下文规则划分纵向切片。
7. 决策日志：记录每项技术决策、作出该决策的原因，以及被否决的替代方案。

设计稿

当功能有设计稿（HTML 页面、TUI 脚本、图片）时，无论由用户提供还是编写过程中制作：

• 将其与 PRD 一起提交到 prds/mockups/[issue-id]-[feature-name].[ext]。实现者或离线 uzi worker 只能看到仓库。如果用户的设计稿位于仓库外，只需请用户提交一次；如果用户拒绝，则在 PRD 文本中描述设计。
• 在 PRD 顶部链接设计稿（**Design mock**: <path>，并说明如何查看），并将以下约定写入 PRD：
  • 设计稿是呈现效果的参考：布局、列、顺序、字形、颜色用途、按键和措辞。实现时应遵循设计稿，而不只是遵循文字规格。
  • 为保持应用风格一致，可适当调整：应用的调色板令牌、措辞、组件和间距。
  • 只有在必要时才可做较大调整（删除元素、采用不同布局、导航或信息），并在 PR 正文的 Mock deviations 部分列出调整及原因。未列出调整即表示与设计稿一致。
  • 验证时应将结果与设计稿并排比较（使用截图或仓库的渲染测试工具），并在 PR 中附上相应证据。
• 明确优先级：PRD 文本中有明确规定时，以文本为准；文本未涵盖之处，以设计稿为准。
• 将设计稿一致性列入每个会渲染设计稿 UI 的里程碑验收标准。

里程碑应是纵向切片

• 每个里程碑都是一项完整行为，可独立验证，并涵盖所需的所有层（模式、逻辑、API、UI、测试、文档）。一次全新的实现运行就应能够构建并验证该里程碑。
• 绝不设置单独的分层里程碑：不得设置仅为后续里程碑做准备的“模式”“服务层”“测试”或“文档”里程碑。测试和文档应包含在其所覆盖的切片中。
• 每个里程碑都必须列出 Blocked by（仅填写确实会阻塞它的里程碑，或填写 “none”）及其验收标准。
• 先做预重构。 如果重构能简化功能实现，则将重构设为第一个里程碑。
• 大范围重构属于例外。 对影响整个代码库的机械性改动（重命名、改类型），采用扩展—收缩方式：在旧形式旁添加新形式，分批迁移调用方，然后移除旧形式。
• 迁移应纳入第一个需要它的切片。
• 每个已合并的切片都必须单独安全：要么满足完整的安全要求，要么置于默认关闭的功能标志之后，且所有可达入口都检查该标志，迁移在标志关闭时保持现有数据和行为不变。
• 里程碑数量不固定。 数量取决于范围门槛（第 1.2 步），而非固定数字。

示例（针对“用户完成课程后获得积分”，按层拆分 vs 纵向拆分）：

• ❌ M1 模式；M2 积分服务；M3 仪表板组件；M4 测试
• ✅ M1 完成课程时发放积分，并在仪表板显示总积分（模式、服务、组件、测试）；M2 连续完成记录可增加奖励，并在仪表板显示（被 M1 阻塞）；M3 为过去已完成的课程补发积分（被 M1 阻塞）

并行工作

阻塞项已完成的里程碑可以考虑并行处理，但不保证适合并行。只有在处理不同文件且不共享状态时才并行执行两个里程碑；否则应按顺序执行。负责人负责集成、在合并后的代码树上运行检查，并在仓库要求时重新编号迁移。

验收不是里程碑

PRD 在代码合并后即告完成（仅涉及文档的 PRD，则在文档变更合入后完成，遵循 /prd-done）。如果某项功能的行为只有在真实环境中才能体现（例如集群、网络策略或外部服务），请创建一个关联的 acceptance issue，其中包含线上检查清单，由用户负责，无截止日期，且绝不添加 uzi sweep 标签。该 issue 不会阻塞合并或关闭。后续 PRD 可引用此 issue；只有当用户认定该场景需要验证实际运行行为时，才应将其设为阻塞项。

GitHub Issue 模板（保持简短且稳定）

创建初始 Issue（不含 PRD 链接）：

## PRD: [Feature Name]

**Problem**: [1-2 sentence problem description]

**Solution**: [1-2 sentence solution overview]

**Detailed PRD**: Will be added after PRD file creation

**Priority**: [High/Medium/Low]

别忘了在创建 Issue 后为其添加“PRD”标签。

更新 Issue（创建 PRD 文件后）：

## PRD: [Feature Name]

**Problem**: [1-2 sentence problem description]

**Solution**: [1-2 sentence solution overview]

**Detailed PRD**: See [prds/[actual-issue-id]-[feature-name].md]([repo-web-url][forge-file-path]prds/[actual-issue-id]-[feature-name].md)

**Priority**: [High/Medium/Low]

编写 PRD

根据代码和上下文自行回答以下问题；这是作者的检查清单，不是要问用户的问题（参见步骤 1）：

• 问题和结果：哪些人受到影响，他们的体验会出现哪些可观察到的变化。
• 现有工作：该功能是否已存在、部分存在，或之前曾被否决。
• 接口边界：该功能涉及哪些接口，以及在哪里进行测试。
• 风险和依赖项：哪些内容可能会出错，该功能依赖其他系统提供什么，以及是否有未完成的 PRD 依赖项（范围门控错误）。
• 切分：能够验证方案的最小端到端行为，以及后续扩展该行为的切分。
• 必备项与可选项：可选项应放入“范围之外”或后续 PRD。

与代码托管平台无关：以下 gh 命令是 GitHub 示例。通过 git remote get-url origin 检测代码托管平台，并使用对应的 CLI，将各动词映射为对应操作：GitHub → gh；GitLab → glab（PR 称为 merge request，使用 glab mr …）；Forgejo/Gitea → tea。如果缺少所需的 CLI，请告知用户并提供其安装页面链接。根据同一远程地址构建 [repo-web-url]（去掉 .git，将 SSH 地址 git@host:org/repo 转换为 https://host/org/repo），并从远程 HEAD 获取 [default-branch]。文件路径片段因代码托管平台而异：GitHub 使用 /blob/<branch>/，GitLab 使用 /-/blob/<branch>/，Forgejo/Gitea（包括 Codeberg）使用 /src/branch/<branch>/。

注意：如果创建 GitHub Issue 时因不存在“PRD”标签而失败，请先创建标签（gh label create "PRD" --description "Product Requirements Document" --color 0052CC），然后重试创建 Issue。

工作流

1. 讨论概念：了解基本想法并验证需求
2. 首先创建 GitHub Issue：简要、稳定地描述概念，以获取 Issue ID
3. 创建 PRD 文件：使用实际的 Issue ID 创建详细文档：prds/[issue-id]-[feature-name].md
4. 更新 GitHub Issue：文件名确定后，将 PRD 文件链接添加到 Issue
5. 编写各个章节：自行填写 PRD 文件的各个章节（参见“编写 PRD”）
6. 定义里程碑：使用 Blocked by 边和验收标准划分纵向切片；PRD 的范围由范围门控（步骤 1.2）限定，而非切片数量
7. 审核与验证：确保内容完整清晰

重要：步骤 2–4 必须严格按此顺序执行，避免因文件名需要 Issue ID 而产生的先有鸡还是先有蛋问题。

更新 ROADMAP.md（如果存在）

创建 PRD 后，检查 docs/ROADMAP.md 是否存在。如果存在，请根据 PRD 优先级将新功能添加到适当的时间范围章节中：

• 高优先级 → 短期章节
• 中优先级 → 中期章节
• 低优先级 → 长期章节

格式：- [Brief feature description] (PRD #[issue-id])

ROADMAP.md 的更新将在工作流结束时的提交中一并包含（选项 2）。

创建 PRD 后：审核，然后执行选定的下一步

下一步和 PRD 审核的选项已提前记录（步骤 1.5，通过 AskUserQuestion，在创建任何内容之前）。现在 PRD 文件和 Issue 均已创建，请按顺序执行：先运行审核（如果用户要求），然后执行选定的下一步。显示确认信息：

✅ PRD Created Successfully!

**PRD File**: prds/[issue-id]-[feature-name].md
**Issue**: #[issue-id]

PRD 审查（如有需要）

如果用户要求审查，请使用 Agent 工具（subagent_type: Explore 或 general-purpose）启动一个或多个审查 Agent，让他们阅读 prds/[issue-id]-[feature-name].md 并提出批评意见，审查范围包括：范围（一个可独立体现价值的成果；不应包含需要未完成 PRD 才能推进的里程碑）、垂直切片（不得设置独立的分层里程碑；Blocked by 依赖关系真实有效；每个切片都能在一次全新运行中完成）、在指定接缝处的可测试性、对不可信输入的处理、资源限制、在任何不可逆的跨所有者操作之前验证声明值，以及复用的安全故事（模块和接缝）、已提交且附带契约的 mock（Design mocks）、清晰度、遗漏的风险和依赖项。如果代码库中有 Agent 团队的 architect 角色，请让其担任审查者之一。

• 一位审查者：启动单个 Agent。
• 让技能决定：根据 PRD 的规模和复杂度选择数量：小型单组件 PRD 启动 1 位审查者，大型或多组件 PRD 启动 2-3 位审查者；每位审查者负责不同的视角（范围/可行性、里程碑/可测试性、风险/依赖项）。并行运行。
• 指定数量：准确启动指定数量的审查者，并在他们之间分配审查视角。

汇总审查结果并向用户展示，然后将用户批准的修复应用到 PRD 文件中。接着继续执行以下选定的下一步。

选项 1：立即开始工作

如果用户选择了 立即开始工作，先提交并推送 PRD（与 提交并推送以供后续处理 相同），然后告知他们：

---

PRD 已提交并推送。

要开始处理此 PRD，请运行 /prd-start [issue-id]

---

选项 2：提交并推送以供后续处理

如果用户选择了 提交并推送以供后续处理：

将 PRD 直接提交到 main——不创建 PR，也不创建功能分支。 此规则优先于任何“先在默认分支上创建分支”的规则；分支和 PR 用于 prd-start 实现，而不是 PRD 文件。

# Stage the PRD file (plus its mock and ROADMAP.md when present)
git add prds/[issue-id]-[feature-name].md
# git add prds/mockups/[issue-id]-[feature-name].[ext]
# If docs/ROADMAP.md exists and was updated, include it:
# git add docs/ROADMAP.md

# Commit with skip CI flag to avoid unnecessary CI runs
git commit -m "docs(prd-[issue-id]): create PRD #[issue-id] - [feature-name] [skip ci]

- Created PRD for [brief feature description]
- Defined [X] major milestones
- Documented problem, solution, and success criteria
- Added to ROADMAP.md ([timeframe] section)
- Ready for implementation"

# Pull latest and push to main
git pull --rebase origin main && git push origin main

确认消息：

✅ PRD committed and pushed to main

The PRD is now available in the repository. To start working on it later, execute:
prd-start [issue-id]

选项 3：发送给 uzi（交接给 uzi-cli 技能）

仅在 uzi 可用时提供此选项（command -v uzi 执行成功，或已安装 uzi-cli 技能）。不要在此处重新实现 uzi 流程。将刚创建的 PRD 交给 uzi-cli 技能的 Send to uzi 编排，并使用 Step 1.5 中预先选定的模式（Auto / Supervised / Seed & ship / Custom），然后从那里驱动运行。

0. **预检：PRD 必须不依赖互联网。**工作进程无法访问外部互联网（参见 Step 5 的说明），因此请重新检查 PRD，找出任何完成时需要访问互联网的里程碑，并先在正文中解决。如果仍有未解决的关键外部事实，请现在查明，或告知用户 PRD 尚未准备好交给 uzi。
1. 先提交并推送 PRD（与选项 2 完全相同），以便 issue 和 prds/ 文件位于远程仓库上，供 uzi 工作进程克隆。为预置路径记录已推送的提交：PRD_SHA=$(git rev-parse HEAD)。
2. **确认 uzi 跟踪此仓库。**如果尚未加载，请加载 uzi-cli 技能（Skill 工具），然后运行 uzi repo list --json 并记下仓库 id。如果仓库未列出，请告知用户该仓库尚未在 uzi 中注册，并退回选项 2。
3. 交接给 uzi-cli 技能的 Send to uzi 部分，提供此 PRD 的坐标：仓库 id、issue #[issue-id]；如果是预置运行，还要提供 --planned-commit "$PRD_SHA"。使用 Step 1.5 中预先选定的模式：
   • Auto / Supervised / 让 uzi 规划：uzi 根据已推送的 PRD issue 进行规划，因此无需本地计划。
   • Seed & ship：根据 PRD 的里程碑和技术范围在本地编写计划（参考 uzi-cli 的 Authoring a seeded plan 部分），然后预置计划。
4. 如果 uzi 拒绝该 issue，理由是缺少 PRD 标签，尽管此技能已添加该标签，说明其轮询器尚未同步。使用 forge 的 Promote 操作处理该 issue（它会在一次请求中写入标签并刷新 uzi 的缓存），然后重试。

如果已安装的 uzi-cli 技能版本早于其 Send to uzi 部分（旧版 uzi 二进制），预置路径请回退到其 Authoring a seeded plan 部分；门控路径则运行 uzi run create --repo <id> --issue [issue-id]。

选项 4：提交并推送 + 排队等待 uzi 扫描

**仅在 uzi 可用，且 uzi schedule list --json 显示至少一个扫描计划时提供此选项。**这是选项 2 的延后执行版本：与立即启动运行的 Send to uzi 不同，它会提交并推送 PRD，然后为 issue 添加标签，让 uzi 扫描计划按自身周期实现它（例如每晚扫描）。此处不会启动运行。

0. 预检：PRD 必须不依赖互联网（扫描与选项 3 一样，使用离线工作进程）。重新检查 PRD，并先在正文中解决任何对外网的依赖；如果仍有未解决的关键外部事实，请查明，或告知用户 PRD 尚未准备好。
1. 先提交并推送 PRD（与选项 2 完全相同），以便扫描开始前，issue 和 prds/ 文件已位于远程仓库上。
2. **查找扫描标签——绝不要将其硬编码。**从 Step 1.5 中读取的 uzi schedule list --json 结果中，找出 target/kind 为 sweep 的计划，并读取其 labels：
   • 只有一个扫描计划 → 使用其标签；
   • 有多个计划（例如 Night、bug）→ 使用 Step 1.5 中预先选定的标签；
   • 没有计划 → 无事可排队；退回选项 2并说明原因。
3. 使用已为此仓库检测到的 forge CLI（glab / gh / tea）为 issue 添加标签，保留此技能已添加的 PRD 标签。GitLab 示例：

   glab issue update [issue-id] --label "[sweep-label]"
   

4. **不要启动运行。**向用户确认 PRD 已推送，且 issue 已添加标签，将由 [sweep-label] 扫描计划按计划执行。

此流程会直接运行 uzi 二进制（如选项 3 的 uzi repo list --json）；无需加载 uzi-cli 技能，且此技能中未硬编码任何标签名称。

重要说明

• 选项 1：适合有时间立即开始实施的情况
• 选项 2：适合创建多个 PRD 或规划后续工作的情况
• 选项 3（发送给 uzi）：将 PRD 交给 uzi-cli 技能的 发送给 uzi 菜单，由该菜单选择自动化程度（自动 / 监督式 / 种子并发布 / 让 uzi 规划），并说明预算方面的权衡。使用种子模式运行时，会采用 uzi 的全局默认预算（应保持计划精简）；设有门控的路径则会根据 uzi 冻结的里程碑调整预算（适用于大型或包含多个组件的 PRD）。
• 选项 4（排入 uzi 扫描队列）：这是选项 2 的延后执行版本——提交并推送 PRD，然后为议题添加 uzi 扫描计划标签（运行时通过 uzi schedule list --json 查找标签，从不硬编码），以便之后由定时扫描实现；现在不会启动任何运行。仅在检测到 uzi 且存在扫描计划时提供。
• PRD 不创建 PR：直接提交到 main（选项 1/2），绝不使用功能分支或 PR。此规则优先于一般的“先建分支”规则；分支和 PR 用于 prd-start 实施。
• 跳过 CI 标记：提交仅涉及 PRD 的更改时，始终使用 [skip ci]
• 议题引用：在提交消息中包含议题编号，以便追踪