mcpField
G
gen-specs-as-issues

gen-specs-as-issues

github.com/github开发40.5k8.8k 次安装1 天前更新
代码仓库

关于 gen-specs-as-issues

gen-specs-as-issues 是一项工作流技能，用于分析软件项目、识别并排序功能缺口，再将选定事项整理为详细的 GitHub issue。它引导产品经理和开发者从实现审查推进到依赖映射与最终规划。

主要功能

  1. 01审查项目结构与实现
  2. 02识别并评估功能缺口
  3. 03编写便于实现的规格
  4. 04创建结构化 GitHub issue
  5. 05映射依赖并拆分工作

适用场景

  1. 01检查项目缺失的功能
  2. 02确定开发工作的优先级
  3. 03准备功能实现规格
  4. 04组织独立任务及其依赖

安装

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

$npx skills add https://github.com/github/awesome-copilot --skill gen-specs-as-issues

安装后在 Claude Code 中输入/gen-specs-as-issues确认已加载。

详细介绍

产品经理助手：功能识别与规格说明

此工作流引导你通过系统化方法识别缺失功能、为其排定优先级，并创建详细的实现规格说明。

1. 项目理解阶段

  • 查看项目结构以了解其组织方式
  • 阅读 README.md 和其他文档文件，了解项目的核心功能
  • 通过检查以下内容识别现有实现状态：
    • 主要入口点（CLI、API、UI 等）
    • 核心模块及其功能
    • 测试以了解预期行为
    • 任何占位实现

引导性问题：

  • 此项目的主要目的是什么？
  • 它解决了哪些用户问题？
  • 当前实现中存在哪些模式？
  • 哪些功能在文档中被提及但未完全实现？

2. 差距分析阶段

  • 仅将文档中描述的能力与实际实现进行对比
  • 识别缺乏真实功能的“占位”代码
  • 查找文档中提到但缺少可靠实现的功能
  • 考虑用户旅程并识别中断或缺失的步骤
  • 优先关注核心功能（而非锦上添花的功能）

输出创建：

  • 创建潜在缺失功能列表（5-7 项）
  • 对于每个功能，记录：
    • 当前实现状态
    • 文档中的引用
    • 缺失时对用户体验的影响

3. 优先级排序阶段

  • 为每个识别出的差距应用评分：

评分矩阵（1-5 分制）：

  • 用户影响：有多少用户受益？
  • 战略一致性：是否符合核心使命？
  • 实现可行性：技术复杂度如何？
  • 资源需求：需要多少开发工作量？
  • 风险水平：潜在的负面影响？

优先级 = (用户影响 × 战略一致性) / (实现工作量 × 风险水平)

输出创建：

  • 根据评分呈现优先级最高的 3 个缺失功能
  • 对于每个功能，提供：
    • 功能名称
    • 当前状态
    • 未实现时的影响
    • 对其他功能的依赖

4. 规格说明开发阶段

  • 对于每个已排定优先级的功能，制定详细但实用的规格说明：
    • 从哲学方法开始：简单优于复杂
    • 优先关注 MVP 功能
    • 考虑开发者体验
    • 保持规格说明便于实现

对于每个功能规格说明：

  1. 概述与范围

    • 它解决了什么问题？
    • 包含什么，明确排除什么？

  2. 技术要求

    • 所需的核心功能
    • 面向用户的接口（API、UI、CLI 等）
    • 与现有代码的集成点

  3. 实现计划

    • 要创建或修改的关键模块/文件
    • 展示方法的简单代码示例
    • 清晰的数据结构和接口

  4. 验收标准

    • 我们如何知道它已完成？
    • 哪些具体功能必须工作？
    • 哪些测试应通过？

5. GitHub Issue 创建阶段

  • 对于每个规格说明，创建一个 GitHub issue：
    • 清晰、描述性的标题
    • 正文中包含全面的规格说明
    • 适当的标签（enhancement、high-priority 等）
    • 在相关处明确提及 MVP 哲学

Issue 模板结构：

[功能名称]

概述

[功能及其目的的简要描述]

范围

[包含什么，明确排除什么]

技术要求

[具体技术需求和约束]

实现计划

[分步方法及简单代码示例]

验收标准

[认为功能完成所需满足的要求的清晰列表]

优先级

[优先级排序的理由]

依赖

  • 阻塞： [被此 issue 阻塞的 issue 列表]
  • 被阻塞于： [此 issue 依赖的 issue 列表]

实现规模

  • 预估工作量： [小/中/大]
  • 子议题： [如果这是父议题，则链接到子议题]

5.5 工作分配优化

  • 独立性分析

    • 审查每份规范，识别真正独立的组件
    • 重构规范，以最大化独立工作流
    • 在相互依赖的组件之间建立清晰的边界

  • 依赖关系映射

    • 对于存在不可避免依赖的功能，建立清晰的议题层级
    • 为整体功能创建父议题，并为各组件创建子议题
    • 明确记录“被阻塞于”和“阻塞”关系

  • 工作量平衡

    • 将大型规范拆分为更小、更易管理的子议题
    • 确保每个子议题代表 1-3 天的开发工作
    • 包含子议题特定的验收标准

实现指南：

  • 使用 GitHub 议题链接语法创建明确的关系
  • 添加标签以指示依赖状态（例如“blocked”、“prerequisite”）
  • 为每个议题包含预估的复杂度/工作量，以协助冲刺规划

6. 最终审查阶段

  • 总结所有已创建的规范
  • 突出显示功能之间的实现依赖关系
  • 建议合理的实现顺序
  • 注明任何潜在的挑战或注意事项

在整个过程中请记住：

  • 宁简勿繁
  • 从可用的最小可行实现开始
  • 关注开发者体验
  • 构建一个日后可扩展的基础
  • 考虑开源社区和贡献模式

这种对我们方法的工作流体现，应有助于在功能如何被指定和排定优先级方面保持一致，确保软件项目以深思熟虑、以用户为中心的方式演进。

评论

支持 Markdown