task-prd-creator

任务与 PRD 创建器

编写清晰、可执行的 PRD 或任务。输出取决于用户跟踪工作的方式。

约定

输入：

• 功能、缺陷、增强或规划请求
• 目标位置偏好：GitHub issue、本地 PRD／任务文件，或两者兼有
• 可选的父 issue、标签、负责人和优先级

输出：

• PRD 或任务正文草稿
• 特定目标位置的创建命令或文件路径
• 获得批准后创建的 issue／文件 URL 或路径

创建／修改：

• 仅在草稿获批后创建本地 .agents/memory/<kebab-name>.md PRD 文件
• 仅在草稿获批后创建 GitHub issue／子 issue

外部副作用：

• 读取 GitHub issue 状态
• 可能创建 GitHub issue、子 issue 或 issue 分支

需要确认：

• 创建文件或 GitHub issue 前，始终先展示草稿
• 链接子 issue 或创建 issue 分支前先询问

委派给：

• 如果实现约束仍不明确，则委派给 spec-first
• 如果工作应采用测试优先的方式执行，则委派给 tdd
• 如果实现后出现 CI 故障，则委派给 gh-fix-ci
• 如果是路线图级别的规划，则委派给 strategy-expert

步骤 1：检测工作流偏好

按顺序检查：

1. 用户是否明确提到“GitHub issue”、“本地文件”或两者兼有
2. 检查 gh auth status 是否成功且是否存在 GitHub 远程仓库 → GitHub 可用
3. 如果仍不明确，询问：“选择 GitHub issue、.agents/memory/ 中的本地 PRD 文件，还是两者兼有？”

步骤 2：了解请求

只询问缺少的信息——如果上下文明确，就不要追问：

• 要解决什么问题？
• 谁会受到影响？（面向用户、内部或基础设施）
• 有哪些硬性约束或依赖项？
• 这是否属于更大的 epic？（→ 子 issue）
• 优先级：critical／high／medium／low

步骤 3：撰写前先调研

• 如果有相关架构文档，请先阅读（.agents/memory/ — 查找架构、摘要或上下文文件）
• 在代码库中搜索相关模式
• 检查是否已有同一主题的 issue：gh issue list --search "[keyword]"

步骤 4：撰写 PRD

完整的 PRD 结构请参阅 references/full-guide.md。

一份优秀的 PRD 包含：

• 问题 — 为什么要做这件事；不做会出现什么问题
• 目标 — 一句话描述可衡量的结果
• 范围 — 包含哪些内容，以及明确不包含哪些内容
• 验收标准 — 可测试，不含含糊表述
• 技术说明 — 方案、风险、依赖项

保持精简，不写凑字数的内容。验收标准必须能由人工核验。

面向 Agent 的 issue 规则

当输出是供自主运行或 AFK Agent 使用的 issue 时，应将其写成 Agent 简报，而不是想到哪写到哪的计划：

• 描述行为和约定，而不是逐个文件给出指示。
• 避免使用行号和脆弱的文件路径，除非路径本身就是约定的一部分。
• 包含当前行为、期望行为、验收标准和范围外内容。
• 如果已知，则注明公共接口、CLI 命令、API 结构、配置项或数据约定。
• 将实现说明作为约束，而不是要求 Agent 照着执行的脚本。

垂直切片拆分

将 epic、PRD 或计划拆分为 issue 时：

• 优先选择精简的垂直切片，并产出可验证的结果。
• 如果 Agent 无需更多人工输入即可完成某个 issue，则将其标记为 AFK。
• 如果某个 issue 需要人工决策、设计评审、凭据或产品判断，则将其标记为 HITL。
• 先发布阻塞项，再发布被阻塞的 issue，以便依赖项能引用真实的 issue ID。
• 每个子 issue 的规模应适合通过一次专注的 PR 完成。

步骤 5：输出到正确的目标位置

GitHub（可用时优先）

新建 issue：

gh issue create \
  --title "[type]: clear title" \
  --body "$(cat <<'BODY'
[PRD content here]
BODY
)" \
  --label "type:feature" \
  --assignee "@me"

子 issue（关联到父 issue）：

# Create sub-issue
gh issue create --title "..." --body "..." 

# Link as sub-issue to parent #N
gh issue develop N --checkout  # only if needed
# Use: gh api repos/{owner}/{repo}/issues/{parent}/sub_issues --method POST -f sub_issue_id={child_id}

从 issue 创建 PR 草稿：

gh issue develop [issue-number] --branch "feature/[name]"

本地文件（可选，或在没有 GitHub 时使用）

• PRD：.agents/memory/[kebab-name].md

本地文件模板请参阅 references/full-guide.md。

步骤 6：创建前获取批准

展示 PRD 草稿。等待用户回复“看起来不错”或提出修改意见，然后再创建。

规则

• disable-model-invocation: true → 仅在用户明确调用时运行
• 未先让用户查看草稿，不要创建文件或 GitHub issue
• 子议题应足够小，能够在一个 PR 中交付
• 如果需求不明确，先写问题陈述，而不是解决方案
• 如果以超出范围为由拒绝一项增强，在仓库使用本地范围外记忆时，将持久的理由记录在 .out-of-scope/<concept>.md 中。

相关内容

• spec-first — 编写代码前采用规格驱动开发
• tdd — 对行为明确的任务采用红—绿—重构执行流程
• gh-fix-ci — 修复现有 PR 中的 CI
• strategy-expert — 更广泛的路线图与内容规划