mcpField
I
issue-to-prd

issue-to-prd

github.com/fellowship-dev开发3224 次安装2 周前更新
代码仓库

关于 issue-to-prd

面向使用 GitHub issue 和分阶段 ICM 流程的团队，将 issue 整理为 PRD。它会先分流需求，必要时提出问题，或发布包含防错措施和测试计划的结构化 PRD。

主要功能

  1. 01筛除不适用 issue 的前置检查
  2. 02与现有机制对照分流
  3. 03上下文与清晰度评估
  4. 04失效模式与测试规划
  5. 05提问或发布 PRD

适用场景

  1. 01将新 GitHub issue 整理为 PRD
  2. 02为信息不足的 issue 请求澄清
  3. 03停止或重定范围重复及不适用的需求

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/fellowship-dev/dogfooded-skills --skill issue-to-prd

安装后在 Claude Code 中输入/issue-to-prd确认已加载。

包含的文件

除 SKILL.md 外，安装时一起下载的参考资料和脚本。

CONTEXT.md
evals/
linked-metric-001.json
no-causal-contract-001.json
outcomes_contract_harness.py
outcomes-api-failure-001.json
redundant-mechanism-001.json
test_triage_label_contract.py
shared/
failure-modes.md
prd-template.md
prototype-mission-brief.md
stages/00-automation-guard/
CONTEXT.md
stages/00-automation-guard/output/
.gitkeep
stages/01-read-issue/
CONTEXT.md
stages/01-read-issue/output/
.gitkeep
stages/01b-triage-challenge/
CONTEXT.md
stages/01b-triage-challenge/output/
.gitkeep
stages/02-context-completeness/
CONTEXT.md
stages/02-context-completeness/output/
.gitkeep
stages/03-assess-clarity/
CONTEXT.md
stages/03-assess-clarity/output/
.gitkeep
stages/03-assess-clarity/references/
gap-checklist.md
stages/04-failure-modes/
CONTEXT.md
stages/04-failure-modes/output/
.gitkeep
stages/05-test-plan/
CONTEXT.md
stages/05-test-plan/output/
.gitkeep
stages/05b-prototype-gate/
CONTEXT.md
stages/05b-prototype-gate/output/
.gitkeep
stages/05b-prototype-gate/references/
gate-checklist.md
stages/05c-outcomes-baseline/
CONTEXT.md
stages/05c-outcomes-baseline/output/
.gitkeep

详细介绍

issue-to-prd

ICM 流程：将新的 GitHub issue 转换为结构化 PRD，或提出澄清问题。

调用

/issue-to-prd {repo} {issue_number}

示例：/issue-to-prd fellowship-dev/pylot 123

使用场景

  • 收到新的 issue，需要进行结构化处理（由 challenge-new-issue 事件规则触发）
  • 人工回答了 open-questions，并触发重新挑战（由 rechallenge-after-answers 触发）
  • 手动调用以结构化处理特定 issue

功能

11 阶段 ICM 流程：

  1. 00-automation-guard — 在读取任何内容之前，拒绝 no-automation / epic / 已关闭的 issue
  2. 01-read-issue — 获取 issue 数据（标题、正文、标签、评论）
  3. 01b-triage-challenge — 搜索是否已有满足相同需求的机制，并根据其最小版本检查请求 → delete-retire / close / re-scope / prd；非 prd 结果会停止流程（跳过阶段 02-07）
  4. 02-context-completeness — 审查新接手的 Agent 可能遗漏的隐含上下文
  5. 03-assess-clarity — 根据 8 部分缺口检查清单进行检查 → clear 或 needs-questions
  6. 04-failure-modes — 预测 Agent 可能出错的方式 → 为 PRD 制定防护措施
  7. 05-test-plan — 测试策略和前置条件（合并前和合并后）
  8. 05b-prototype-gate — 这是否属于 UI 探索？→ skip / ask / dispatch / picked
  9. 05c-outcomes-baseline — 检测 issue 中是否存在因果目标／评估／结果约定；仅在存在约定时，才会获取该指定指标的基线 GET /outcomes/summary（失败时放行）
  10. 06-ask-or-structure — 决策：发布问题（退出）或起草 PRD（仅在存在约定时包含可衡量影响，否则标记为“不适用”）
  11. 07-publish — 重写 issue 正文并应用标签

退出路径

  • 防护路径（阶段 00）：不读取、不写入，status=success，停止
  • 分流路径（阶段 01b）：发布一条评论，说明判定结果及引用的证据，应用 wontfix 或 needs-rescope，然后停止（跳过阶段 02-07）——必须附带引用才会触发
  • 问题路径（阶段 06）：发布 GH 评论，添加 open-questions 标签，然后停止
  • PRD 路径（阶段 07）：重写 issue 正文，添加 prd-ready（若仍有待处理的原型变体，则不添加 ready-to-work）

原型变体

阶段 05b 可以派发一项任务，推送 proto/<issue>-a|b|c 分支并发布一条包含截图和启动说明的选项评论，供负责人选择。此流程受到严格限制： 自动检测只能提出问题；只有明确的负责人信号（prototype-options 标签或“构建原型”的回答）才会派发任务。 参见 stages/05b-prototype-gate/CONTEXT.md。

阶段交接

每个阶段都会写入自己的 output/handoff.md。下游阶段会读取上游阶段的交接文件。 所有输出目录均位于 stages/{stage}/output/。

执行

按顺序运行各阶段。执行每个阶段前，请先阅读其 CONTEXT.md。 阶段 00 是硬性关卡——如果它中止，不要运行其他任何阶段。 阶段 01b 是硬性关卡——如果判定结果不是 prd，则不要运行后续阶段（跳过阶段 02-07）。 阶段 05c 始终运行（失败时放行）——它不会阻止阶段 06。 阶段 06 结束后，如果已发布问题，则跳过阶段 07。

参考文件

  • shared/prd-template.md — PRD 结构（阶段 06 使用）；## Measurable Impact 部分是否包含，取决于阶段 05c 的约定判定结果
  • shared/failure-modes.md — 常见 Agent 陷阱目录（阶段 04 使用）
  • shared/prototype-mission-brief.md — 原型变体任务的独立说明（阶段 05b）
  • stages/03-assess-clarity/references/gap-checklist.md — 8 部分检查清单
  • stages/05b-prototype-gate/references/gate-checklist.md — 原型关卡及分类示例
  • stages/05c-outcomes-baseline/CONTEXT.md — 因果约定检测及范围限定的失败放行基线格式

评论

支持 Markdown