mcpField
P
plan-feature-from-issue

plan-feature-from-issue

github.com/gtrabanco开发2293 次安装今天更新
代码仓库

关于 plan-feature-from-issue

plan-feature-from-issue 是一项 Agent 技能，可将功能请求 issue 转为 SPEC 的产品部分并关联路线图。它检查能力闭环与就绪状态，随后停下等待独立评审，再进入工程规划。

主要功能

  1. 01识别功能 issue 并转交缺陷
  2. 02找出产品规格缺口
  3. 03检查能力闭环
  4. 04估算功能规模
  5. 05编写 SPEC 产品部分并更新路线图
  6. 06保留 issue 到 PR 的追踪关系

适用场景

  1. 01根据功能 issue 起草 SPEC
  2. 02在评审前找出缺失的产品决策
  3. 03将 issue 派生功能登记到路线图
  4. 04准备与 issue 关联且需评审的规划

安装

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

$npx skills add https://github.com/gtrabanco/agentic-workflow --skill plan-feature-from-issue

安装后在 Claude Code 中输入/plan-feature-from-issue确认已加载。

详细介绍

规划功能 — 从 Issue 开始（内部）

将功能请求 issue 转换为项目规划文档，保持清晰的 issue → SPEC → PR（Closes #n）追踪关系。编写 SPEC 的产品部分（采用 design-feature 使用的相同双部分约定），并且在交接前必须满足能力闭环要求——不能因为 issue 内容单薄就绕过这一步。

**此技能止步于产品部分。**完成设计后，交由 review-spec 对该部分进行独立的产品评审；工程规划属于另一权限方的职责。在撰写设计的同时组合使用 plan-feature-scaffold，正是这项职责分离要杜绝的绕行方式——产品部分的作者不能同时决定它已准备好进入构建阶段。

适用场景

  • 当输入是 GitHub issue（或 --from-issue N），且描述的是新的产品能力时，plan-feature 路由器会调用此技能。

如果 issue 属于缺陷或技术债务，请停止并转交：先用 triage-issue 分类，再执行 plan-fix + execute-phase --fix。此技能仅用于真正的功能需求。

步骤 0 — 探索项目（始终首先执行）

按照 Agent 指南中的工作流约定和文档地图，然后阅读此技能所需的内容：功能 SPEC 模板、路线图以及 issue/PR 模板（.github/ISSUE_TEMPLATE/、.github/PULL_REQUEST_TEMPLATE.md），确保 SPEC 与评审者期望的字段一致。接着阅读 issue（根据项目的工作流约定使用 forge CLI——示例使用 gh）：

gh issue view <N> --json number,title,body,labels,state,comments

流程

  1. 先分类。 确认这是一项功能。如果描述的是缺陷、回归问题、重复代码、性能债务，或包含“何时修复／触发”条款，则不属于功能 → 转交给 triage-issue。明确说明判定结果。

  2. 统一语言。 如果内容不是项目文档所用语言（此仓库为：English），请先翻译，再起草任何产物。

  3. 映射到路线图。 分配下一个编号 + slug。识别依赖项以及与现有功能的冲突、耦合／迁移风险，并判断是否应该扩展现有功能。

  4. 主动补齐产品部分的缺口。 对照完整 SPEC 的产品部分所需内容（目标、范围内／范围外、业务目标、根据文档映射确定的 i18n/SEO/a11y/定价信息；如果功能有 UI 界面，还需提供 UI 设计参考），并使用 design-feature 访谈所采用的同一套固定模糊性评估标准进行探查：受影响的用户／角色 · 错误与边缘状态 · 数据形态 · 边界与限制 · 范围外内容 · 成功标准——每项都必须填写，或明确标注 n/a: <reason>。对于无法安全采用默认值的实际缺口，每轮只向用户提一个问题，绝不一次提出多个问题；每个问题都要附上建议默认值；不要询问 issue 或文档已经解答的内容。**结构性转交阈值：**如果根据 issue 和此前的回答，仍有 ≥ 3 项评估标准无法填写，则停止，并将该功能转交给 design-feature（即下方薄弱 issue 规则的固定触发条件），不要继续在此处访谈。

  5. 满足能力闭环。 将 design-feature 使用的同一套固定清单（按实体：CRUD + 状态转换，每项都要有 UI + API + 测试，或明确标注 n/a: <reason>；按能力：入口 + ACL；按角色：在哪里分配／撤销／查看）纳入 SPEC 的 ## Capability closure 和 ## Acceptance criteria。信息不足以完成闭环的薄弱 issue 不能绕过此关卡——应将其转交给 design-feature（仅当达到此技能的等级时，才在本轮组合处理，具体见 Guardrails；否则转交并执行 run /design-feature <slug>，然后在此处停止），不要在闭环内容空洞的情况下将其标记为 designed。

  6. 评估规模。 估算为 XS / S / M / L（定义见 SPEC 模板），并记录在 SPEC 中。XS/S → SPEC 是唯一的规划产物（单次执行）；M/L → 完整产物集。如果为 L，建议拆分。

  7. 产出 SPEC 的产品部分。 填写内容，并在闭环完成后标记 ## Design status: designed；如果路线图中尚无该条目，先以 idea 状态添加，然后在同一次编辑中将其设为 defined——这是 design-feature 负责的同一项 idea → defined 转换；当本技能完成闭环时，由本技能执行。然后运行内部 evidence-grounding 能力中的 stage: spec 就绪预检，生成当前的 artifactRevisionId，并停止：本技能绝不继续处理工程部分，不会将路线图条目提升到 defined 以上，也不会在本轮组合执行 plan-feature-scaffold。只有在 review-spec 返回绑定到这些确切字节的当前 spec-review-pass 凭证后，plan-feature 路由器才能搭建脚手架。

  8. 建立追溯关系。 在 SPEC 中记录 #N；PR 正文必须包含 Closes #N，以便在合并时关闭 issue。

  9. 移交——必须原样返回（固定完成报告，返回给路由器）：

    ISSUE #<N> → SPEC <slug> — size: <XS|S|M|L>
Verdict: feature (not bug/debt — else this would have routed to triage-issue)
Gaps closed: <n> asked / <n> defaulted (logged)   Closure: designed | handed to design-feature
Readiness: READY-FOR-REVIEW | NEEDS-EVIDENCE | NEEDS-DESIGN   Artifact revision: <id>
Traceability: Closes #<N> wired
→ review-spec next (engineering planning is gated on its receipt; do not scaffold here)

护栏

  • 不要悄悄将范围扩展到议题之外——应将新增内容作为提案提出。
  • 不要在此处创建功能分支或编写代码。
  • 不要在此处规划工程工作。 不要编写工程部分，不要划分阶段，不要将状态从 defined 提升为 planned，也不要在本轮组合调用 plan-feature-scaffold：此技能编写的产品部分必须先经过 review-spec 审核，而就绪状态 READY-FOR-REVIEW 并不等于通过了该审核。
  • 保留 Closes #N 链接；由议题产生的功能必须关闭该议题。
  • 绝不要在 Capability closure 行为空时标注 ## Design status: designed——design-feature 遵循相同规则；对于内容单薄的议题，应移交，而不是伪造闭环。
  • 组合调用层级。 只有在此技能运行时所处层级不低于 design-feature 的层级（规划级——最强模型／最高工作量）时，才允许在本轮为内容单薄的议题组合调用 design-feature；否则应移交（运行 /design-feature <slug>），不要在能力不足时强行处理。
  • 其他情况请遵循项目的 工作流约定（分支／PR、文档语言）。

架构不变量

规划预检负责读取规范化的仓库状态，并对整个计划做出唯一的最终架构分类。编写产品部分之前，先在此处使用该结果：对于每条适用的不变量规则，引用其 ID 和仓库证据，并将议题提案分类为 preserves、violates、introduces 或 changes。只有分类为 preserves 时，才能标注为 designed；其他任何分类都必须暂停，等待由项目指定的权威方明确做出架构决策——必须等完整计划形成之后，绝不能提前做出，也绝不能从议题正文、SPEC 或通过的测试中推断。

与其他技能的关系

  • triage-issue — 判断是缺陷、功能还是暂缓处理；不确定时调用。
  • plan-fix — 用于缺陷／技术债议题的修复侧对应技能。
  • design-feature — 接收此技能无法安全完成能力闭环的内容单薄议题；两者均以相同格式编写 SPEC 的产品部分。
  • review-spec — 每个由议题衍生的功能都必须进入的下一步：它会审核并确认此技能产出的产品部分。
  • plan-feature-scaffold — 仅在 review-spec 通过后，才用于补充工程部分。此技能绝不会调用它。
  • execute-phase — 执行各阶段；其 PR 会包含 Closes #N。

完成条件

  • 已填写 SPEC 的产品部分，并在路线图中登记为 defined；同时已打印 stage: spec 就绪状态块，并记录当前的 artifactRevisionId。
  • 已满足能力闭环要求（或者将议题移交给 design-feature，而不是伪造闭环），且 ## Design status 状态准确。
  • 只要标注了 ## Design status: designed，路线图行的状态就必须为 defined（新条目应先添加为 idea）；闭环不完整时绝不能设为 defined，标注 designed 后也绝不能仍保持 idea。
  • 未进行任何脚手架搭建：没有工程部分、没有阶段、没有写入 planned，且最终报告已移交给 /review-spec。
  • 已记录 #N，且 PR 计划包含 Closes #N。
  • 已与用户解决范围缺口，而非自行假定。

评论

支持 Markdown