prd-to-prod-autopilot

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

PRD To Production Autopilot

PRD 到生产环境自动化领航工具

Quick start

快速开始

Given an existing PRD, load the current installed

to-issues

skill, create thin implementation issues, triage them with

triage

, implement every

ready-for-agent

issue with supervised worker agents, verify each slice, then run the full repo gate.

This skill does not create the PRD. The user or another agent workflow owns PRD creation and validation before this autopilot starts.

给定一份现有PRD，加载已安装的

to-issues

技能，创建轻量化的实现任务，使用

triage

对任务进行分类，通过受监督的Worker Agent实现每个

ready-for-agent

任务，验证每个切片，最后运行完整的代码库准入检查。

本技能不会创建PRD。在启动此自动化流程之前，PRD的创建和验证由用户或其他Agent工作流负责。

Core Rules

核心规则

Compose the current installed skills instead of duplicating their internals:
```
to-issues
```
,
```
triage
```
, and
```
diagnose
```
when checks fail.
Treat those referenced skills as the source of truth for their own steps. This skill only defines ordering, handoffs, state tracking, and completion gates.
Use the PRD as the product source of truth. If implementation questions can be answered from the PRD, code,
```
CONTEXT.md
```
, or ADRs, answer them from evidence and record the source.
If a decision depends on secrets, credentials, legal/business policy, production deploy permissions, irreversible external actions, or product scope not covered by the PRD, stop that slice and mark it
```
ready-for-human
```
or blocked with the smallest targeted question.
Production-ready means implemented and validated in the repo. Do not deploy, publish, push, create PRs, run migrations against shared infrastructure, or perform external side effects unless the user or repo policy explicitly asks for them.
Keep each issue narrow, testable, and independently reviewable. Split oversized issues before implementation.
Keep a temporary autopilot state file at
```
.scratch/<idea-slug>/idea-autopilot-state.md
```
, where
```
<idea-slug>
```
comes from the PRD title or filename.
Update the state file after every major transition. Delete it only after full success; keep it if blocked or failed.

组合已安装的技能而非重复其内部逻辑：检查失败时使用
```
to-issues
```
、
```
triage
```
和
```
diagnose
```
技能。
将上述引用的技能视为对应步骤的权威来源。本技能仅定义流程顺序、交接方式、状态跟踪和完成准入条件。
将PRD作为产品的权威来源。若实现问题可从PRD、代码、
```
CONTEXT.md
```
或ADRs中找到答案，需基于证据作答并记录来源。
若决策涉及密钥、凭证、法律/业务政策、生产部署权限、不可逆外部操作或PRD未覆盖的产品范围，则停止该切片的处理，将其标记为
```
ready-for-human
```
，或附上最精准的针对性问题标记为阻塞状态。
生产就绪指已在代码库中完成实现并通过验证。除非用户或代码库政策明确要求，否则不得执行部署、发布、推送、创建PR、针对共享基础设施运行迁移或产生其他外部副作用。
确保每个任务范围明确、可测试且可独立评审。在实现前拆分过大的任务。
在
```
.scratch/<idea-slug>/idea-autopilot-state.md
```
路径下保存临时自动化状态文件，其中
```
<idea-slug>
```
取自PRD标题或文件名。
每次重大流程转换后更新状态文件。仅在完全成功后删除该文件；若流程阻塞或失败则保留。

Workflow

工作流程

1. Prepare

1. 准备阶段

Identify the PRD path or PRD content from the user's request.
Read repo instructions,
```
CONTEXT.md
```
, relevant ADRs, issue tracker config, and verification commands.
Ensure the engineering-skill config exists; if not, run
```
setup-matt-pocock-skills
```
first.

Create

.scratch/<idea-slug>/idea-autopilot-state.md

Record PRD source, assumptions, verification commands, issue tracker location, delivery policy, and any known blockers.

从用户请求中确定PRD路径或PRD内容。
阅读代码库说明、
```
CONTEXT.md
```
、相关ADRs、问题跟踪器配置及验证命令。
确保工程技能配置已存在；若不存在，先运行
```
setup-matt-pocock-skills
```
。

创建

.scratch/<idea-slug>/idea-autopilot-state.md

文件。

记录PRD来源、假设条件、验证命令、问题跟踪器位置、交付政策及所有已知阻塞项。

2. Create Issues From The PRD

2. 从PRD生成任务

Load
```
to-issues
```
.
Convert the PRD into thin vertical implementation slices with acceptance criteria and verification notes.
Preserve dependencies and put blockers first.
Mark slices
```
AFK
```
by default unless they require a real human decision.
Publish issues in the configured issue tracker when policy allows it.
Record the issue manifest in the state file: title, path/id, dependencies, acceptance criteria, and expected checks.

加载
```
to-issues
```
技能。
将PRD转换为包含验收标准和验证说明的轻量化垂直实现切片。
保留任务依赖关系，优先处理阻塞项。
默认将切片标记为
```
AFK
```
，除非需要人工决策。
若政策允许，在配置的问题跟踪器中发布任务。
在状态文件中记录任务清单：标题、路径/ID、依赖关系、验收标准及预期检查项。

3. Triage Created Issues

3. 分类生成的任务

Load
```
triage
```
.
Classify each created issue with the repo's label vocabulary.
Use
```
ready-for-agent
```
for implementable AFK slices,
```
ready-for-human
```
for true product or permission decisions, and
```
needs-info
```
for missing facts.
Add durable agent briefs for every
```
ready-for-agent
```
issue: PRD reference, acceptance criteria, dependencies, files likely involved, verification commands, and known assumptions.
Do not start blocked or human-decision issues until their blockers are resolved.

加载
```
triage
```
技能。
使用代码库的标签体系对每个生成的任务进行分类。
可实现的AFK切片标记为
```
ready-for-agent
```
，需产品或权限决策的标记为
```
ready-for-human
```
，缺少信息的标记为
```
needs-info
```
。
为每个
```
ready-for-agent
```
任务添加持久化Agent简报：PRD参考、验收标准、依赖关系、可能涉及的文件、验证命令及已知假设。
阻塞或需人工决策的任务在阻塞项解决前不得启动。

4. Implement Ready Issues

4. 实现就绪任务

Treat each
```
ready-for-agent
```
issue as the unit of work.
Run independent, non-overlapping issues in parallel with supervised worker agents when that is allowed by the current agent environment.
Serialize issues that touch the same risky files, public contracts, migrations, data models, or shared tests.
Give each worker exactly one issue, the PRD reference, dependencies, acceptance criteria, verification commands, delivery policy, and final handoff requirements.
Track progress in the state file as
```
ready
```
,
```
in_progress
```
,
```
implemented
```
,
```
verified
```
, or
```
blocked
```
.
If an issue is too broad, split it through the issue tracker before implementation continues.

将每个
```
ready-for-agent
```
任务作为工作单元。
若当前Agent环境允许，通过受监督的Worker Agent并行处理独立、无重叠的任务。
对涉及相同风险文件、公共契约、迁移、数据模型或共享测试的任务进行串行处理。
为每个Worker分配恰好一个任务，并提供PRD参考、依赖关系、验收标准、验证命令、交付政策及最终交接要求。
在状态文件中跟踪任务进度，状态包括
```
ready
```
、
```
in_progress
```
、
```
implemented
```
、
```
verified
```
或
```
blocked
```
。
若任务范围过宽，在继续实现前通过问题跟踪器拆分任务。

5. Verify Each Slice

5. 验证每个切片

Require concrete evidence before marking an issue
```
verified
```
: changed files when code changed, relevant tests/build/lint output, and acceptance criteria status.
When a slice check fails, use
```
diagnose
```
to reproduce, minimize, hypothesize, instrument if needed, fix, and retest.
If a worker returns incomplete, sandbox-only, or integration-needed work, the parent agent integrates it into the canonical workspace and reruns the slice checks.
Update the issue and state file with verification evidence or a precise blocker.

标记任务为
```
verified
```
前需提供具体证据：代码变更时的修改文件、相关测试/构建/lint输出及验收标准状态。
若切片检查失败，使用
```
diagnose
```
技能重现问题、简化问题、提出假设、必要时添加监控、修复问题并重新测试。
若Worker返回的工作不完整、仅适用于沙箱或需要集成，父Agent需将其集成到标准工作区并重新运行切片检查。
在任务和状态文件中更新验证证据或精准的阻塞信息。

6. Final Repo Gate

6. 最终代码库准入检查

Re-run or confirm the full repo checks that matter for the combined change.
Check for cross-issue conflicts, duplicated abstractions, missing docs, migration gaps, and PRD acceptance criteria coverage.
Confirm every implementable issue is
```
verified
```
and every remaining non-implemented issue is explicitly blocked or
```
ready-for-human
```
.

Delete

.scratch/<idea-slug>/idea-autopilot-state.md

only after the full gate passes.

Summarize PRD source, created issues, completed issues, verification commands, remaining blockers, and assumptions accepted during delivery.

重新运行或确认与合并变更相关的完整代码库检查。
检查跨任务冲突、重复抽象、缺失文档、迁移缺口及PRD验收标准覆盖情况。
确认每个可实现任务均已标记为
```
verified
```
，所有未实现的任务均已明确标记为阻塞或
```
ready-for-human
```
。
仅在完整准入检查通过后删除
```
.scratch/<idea-slug>/idea-autopilot-state.md
```
文件。
总结PRD来源、生成的任务、已完成的任务、验证命令、剩余阻塞项及交付过程中接受的假设条件。