相关 Skills
SKILL.md
readonly只读
name
gen-specs-as-issues
description
此工作流引导您通过系统化的方法来识别缺失功能、确定优先级，并创建详细的实现规范。
产品经理助手：功能识别与规范制定
此工作流引导您通过系统化的方法来识别缺失功能、确定优先级，并创建详细的实现规范。
1. 项目理解阶段
- 审查项目结构以了解其组织方式
- 阅读 README.md 和其他文档文件以了解项目的核心功能
- 通过检查以下内容来识别现有实现状态：
- 主要入口点（CLI、API、UI 等）
- 核心模块及其功能
- 测试以了解预期行为
- 任何占位符实现
引导性问题：
- 该项目的主要目的是什么？
- 它解决了用户的哪些问题？
- 当前实现中存在哪些模式？
- 文档中提到但未完全实现的功能有哪些？
2. 差距分析阶段
- 仅将文档中描述的能力与实际实现进行对比
- 识别缺乏实际功能的“占位符”代码
- 查找文档中提到但缺少稳健实现的功能
- 考虑用户旅程，识别中断或缺失的步骤
- 首先关注核心功能（而非锦上添花的功能）
输出创建：
- 创建潜在缺失功能列表（5-7 项）
- 对于每个功能，记录：
- 当前实现状态
- 文档中的引用
- 如果缺失，对用户体验的影响
3. 优先级排序阶段
- 对每个识别出的差距进行评分：
评分矩阵（1-5 分制）：
- 用户影响：有多少用户受益？
- 战略契合度：是否符合核心使命？
- 实现可行性：技术复杂度如何？
- 资源需求：开发工作量？
- 风险等级：潜在的负面影响？
优先级 = (用户影响 × 战略契合度) / (实现工作量 × 风险等级)
输出创建：
- 根据评分，展示优先级最高的前 3 个缺失功能
- 对于每个功能，提供：
- 功能名称
- 当前状态
- 如果未实现的影响
- 对其他功能的依赖关系
4. 规范制定阶段
- 对于每个优先功能，制定详细且实用的规范：
- 从哲学方法开始：简单优于复杂
- 首先关注 MVP 功能
- 考虑开发者体验
- 保持规范易于实现
每个功能规范：
-
概述与范围
- 它解决了什么问题？
- 包含什么，明确排除什么？
-
技术要求
- 所需的核心功能
- 面向用户的接口（API、UI、CLI 等）
- 与现有代码的集成点
-
实现计划
- 需要创建或修改的关键模块/文件
- 展示方法的简单代码示例
- 清晰的数据结构和接口
-
验收标准
- 如何知道何时完成？
- 哪些具体功能必须正常工作？
- 哪些测试应该通过？
5. GitHub Issue 创建阶段
- 对于每个规范，创建一个 GitHub issue：
- 清晰、描述性的标题
- 正文中包含全面的规范
- 适当的标签（enhancement、high-priority 等）
- 在相关处明确提及 MVP 理念
Issue 模板结构：
[功能名称]
概述
[功能的简要描述及其目的]
范围
[包含什么，明确排除什么]
技术要求
[具体的技术需求和约束]
实现计划
[逐步方法，附简单代码示例]
验收标准
[认为功能完成所需的明确条件列表]
优先级
[优先级排序的理由]
依赖关系
- 阻塞： [被此 issue 阻塞的 issue 列表]
- 被阻塞： [此 issue 依赖的 issue 列表]
实现规模
- 预估工作量： [小/中/大]
- 子 issue： [如果这是父 issue，则链接到子 issue]
5.5 工作分配优化
-
独立性分析
- 审查每个规范，识别真正独立的组件
- 重构规范以最大化独立工作流
- 在相互依赖的组件之间建立清晰的边界
-
依赖关系映射
- 对于存在不可避免依赖的功能，建立清晰的 issue 层级
- 为整体功能创建父 issue，并为组件创建子 issue
- 明确记录“被阻塞”和“阻塞”关系
-
工作负载平衡
- 将大型规范拆分为更小、可管理的子 issue
- 确保每个子 issue 代表 1-3 天的开发工作
- 包含子 issue 特定的验收标准
实现指南：
- 使用 GitHub issue 链接语法创建明确的关系
- 添加标签以指示依赖状态（例如，“blocked”、“prerequisite”）
- 为每个 issue 包含预估复杂度/工作量，以辅助冲刺规划
6. 最终审查阶段
- 总结所有创建的规范
- 突出功能之间的实现依赖关系
- 建议逻辑上的实现顺序
- 记录任何潜在的挑战或注意事项
请记住在整个过程中：
- 简单优于复杂
- 从最小可行实现开始，确保其工作
- 关注开发者体验
- 构建可后续扩展的基础
- 考虑开源社区和贡献模型
此工作流体现了我们的方法，有助于保持功能规范和优先级排序的一致性，确保软件项目以深思熟虑、以用户为中心的方式演进。
