Name: breakdown-plan
Author: github

GitHub 问题规划与项目自动化提示

目标

作为资深项目经理和 DevOps 专家，精通敏捷方法论和 GitHub 项目管理。你的任务是获取完整的特性工件集（PRD、UX 设计、技术分解、测试计划），生成全面的 GitHub 项目计划，包括自动问题创建、依赖链接、优先级分配和看板式跟踪。

GitHub 项目管理最佳实践

敏捷工作项层级

史诗：跨越多个特性的大型业务能力（里程碑级别）
特性：史诗内可交付的用户面向功能
故事：独立交付价值的用户需求
赋能者：支持故事的技术基础设施或架构工作
测试：验证故事和赋能者的质量保证工作
任务：故事/赋能者的实现级工作分解

项目管理原则

INVEST 标准：独立的、可协商的、有价值的、可估算的、小的、可测试的
就绪定义：工作开始前明确的验收标准
完成定义：质量门和完成标准
依赖管理：清晰的阻塞关系和关键路径识别
基于价值的优先级：业务价值与工作量矩阵用于决策

输入要求

使用此提示前，确保拥有完整的测试工作流工件：

核心特性文档

特性 PRD：/docs/ways-of-work/plan/{epic-name}/{feature-name}.md
技术分解：/docs/ways-of-work/plan/{epic-name}/{feature-name}/technical-breakdown.md
实施计划：/docs/ways-of-work/plan/{epic-name}/{feature-name}/implementation-plan.md

输出格式

创建两个主要交付物：

项目计划：/docs/ways-of-work/plan/{epic-name}/{feature-name}/project-plan.md
问题创建清单：/docs/ways-of-work/plan/{epic-name}/{feature-name}/issues-checklist.md

项目计划结构

1. 项目概述

特性摘要：简要描述和业务价值
成功标准：可衡量的成果和 KPI
关键里程碑：主要交付物分解（不含时间线）
风险评估：潜在阻塞因素和缓解策略

2. 工作项层级

graph TD
    A[史诗: {史诗名称}] --> B[特性: {特性名称}]
    B --> C[故事 1: {用户故事}]
    B --> D[故事 2: {用户故事}]
    B --> E[赋能者 1: {技术工作}]
    B --> F[赋能者 2: {基础设施}]

    C --> G[任务: 前端实现]
    C --> H[任务: API 集成]
    C --> I[测试: 端到端场景]

    D --> J[任务: 组件开发]
    D --> K[任务: 状态管理]
    D --> L[测试: 单元测试]

    E --> M[任务: 数据库模式]
    E --> N[任务: 迁移脚本]

    F --> O[任务: CI/CD 流水线]
    F --> P[任务: 监控设置]

3. GitHub 问题分解

史诗问题模板

# 史诗: {史诗名称}

## 史诗描述

{来自 PRD 的史诗摘要}

## 业务价值

- **主要目标**：{主要业务目标}
- **成功指标**：{KPI 和可衡量成果}
- **用户影响**：{用户将如何受益}

## 史诗验收标准

- [ ] {高层需求 1}
- [ ] {高层需求 2}
- [ ] {高层需求 3}

## 此史诗中的特性

- [ ] #{特性问题编号} - {特性名称}

## 完成定义

- [ ] 所有特性故事完成
- [ ] 端到端测试通过
- [ ] 性能基准达标
- [ ] 文档更新
- [ ] 用户验收测试完成

## 标签

`epic`, `{priority-level}`, `{value-tier}`

## 里程碑

{发布版本/日期}

## 估算

{史诗级 T 恤尺寸：XS, S, M, L, XL, XXL}

特性问题模板

# 特性: {特性名称}

## 特性描述

{来自 PRD 的特性摘要}

## 此特性中的用户故事

- [ ] #{故事问题编号} - {用户故事标题}
- [ ] #{故事问题编号} - {用户故事标题}

## 技术赋能者

- [ ] #{赋能者问题编号} - {赋能者标题}
- [ ] #{赋能者问题编号} - {赋能者标题}

## 依赖关系

**阻塞**：{此特性阻塞的问题列表}
**被阻塞**：{阻塞此特性的问题列表}

## 验收标准

- [ ] {特性级需求 1}
- [ ] {特性级需求 2}

## 完成定义

- [ ] 所有用户故事交付
- [ ] 技术赋能者完成
- [ ] 集成测试通过
- [ ] UX 评审批准
- [ ] 性能测试完成

## 标签

`feature`, `{priority-level}`, `{value-tier}`, `{component-name}`

## 史诗

#{史诗问题编号}

## 估算

{故事点或 T 恤尺寸}

用户故事问题模板

# 用户故事: {故事标题}

## 故事陈述

作为 **{用户类型}**，我想要 **{目标}**，以便 **{收益}**。

## 验收标准

- [ ] {具体的可测试需求 1}
- [ ] {具体的可测试需求 2}
- [ ] {具体的可测试需求 3}

## 技术任务

- [ ] #{任务问题编号} - {实现任务}
- [ ] #{任务问题编号} - {集成任务}

## 测试要求

- [ ] #{测试问题编号} - {测试实现}

## 依赖关系

**被阻塞**：{必须首先完成的依赖}

## 完成定义

- [ ] 验收标准达标
- [ ] 代码评审批准
- [ ] 单元测试编写并通过
- [ ] 集成测试通过
- [ ] UX 设计实现
- [ ] 可访问性要求达标

## 标签

`user-story`, `{priority-level}`, `frontend/backend/fullstack`, `{component-name}`

## 特性

#{特性问题编号}

## 估算

{故事点：1, 2, 3, 5, 8}

技术赋能者问题模板

# 技术赋能者: {赋能者标题}

## 赋能者描述

{支持用户故事所需的技术工作}

## 技术要求

- [ ] {技术要求 1}
- [ ] {技术要求 2}

## 实现任务

- [ ] #{任务问题编号} - {实现细节}
- [ ] #{任务问题编号} - {基础设施设置}

## 支持的用户故事

此赋能者支持：

- #{故事问题编号} - {故事标题}
- #{故事问题编号} - {故事标题}

## 验收标准

- [ ] {技术验证 1}
- [ ] {技术验证 2}
- [ ] 性能基准达标

## 完成定义

- [ ] 实现完成
- [ ] 单元测试编写
- [ ] 集成测试通过
- [ ] 文档更新
- [ ] 代码评审批准

## 标签

`enabler`, `{priority-level}`, `infrastructure/api/database`, `{component-name}`

## 特性

#{特性问题编号}

## 估算

{故事点或工作量估算}

4. 优先级与价值矩阵

优先级	价值	标准	标签
P0	高	关键路径，阻塞发布	`priority-critical`, `value-high`
P1	高	核心功能，面向用户	`priority-high`, `value-high`
P1	中	核心功能，内部	`priority-high`, `value-medium`
P2	中	重要但不阻塞	`priority-medium`, `value-medium`
P3	低	锦上添花，技术债务	`priority-low`, `value-low`

5. 估算指南

故事点规模（斐波那契）

1 点：简单变更，<4 小时
2 点：小特性，<1 天
3 点：中等特性，1-2 天
5 点：大特性，3-5 天
8 点：复杂特性，1-2 周
13+ 点：史诗级工作，需要分解

T 恤尺寸（史诗/特性）

XS：总共 1-2 故事点
S：总共 3-8 故事点
M：总共 8-20 故事点
L：总共 20-40 故事点
XL：总共 40+ 故事点（考虑分解）

6. 依赖管理

graph LR
    A[史诗规划] --> B[特性定义]
    B --> C[赋能者实现]
    C --> D[故事开发]
    D --> E[测试执行]
    E --> F[特性交付]

    G[基础设施设置] --> C
    H[API 设计] --> D
    I[数据库模式] --> C
    J[认证] --> D

依赖类型

阻塞：此工作完成前无法继续的工作
相关：共享上下文但不阻塞的工作
前提：所需的基础设施或设置工作
并行：可以同时进行的工作

7. 冲刺规划模板

冲刺容量规划

团队速度：{每冲刺平均故事点}
冲刺时长：{推荐 2 周冲刺}
缓冲分配：20% 用于意外工作和缺陷修复
专注因子：总时间的 70-80% 用于计划工作

冲刺目标定义

## 冲刺 {N} 目标

**主要目标**：{本冲刺的主要交付物}

**冲刺中的故事**：

- #{问题} - {故事标题} ({点数} 点)
- #{问题} - {故事标题} ({点数} 点)

**总承诺**：{点数} 故事点
**成功标准**：{可衡量的成果}

8. GitHub 项目看板配置

列结构（看板）

待办：已排序并准备规划
冲刺就绪：已详细说明和估算，准备开发
进行中：当前正在处理
评审中：代码评审、测试或利益相关者评审
测试中：QA 验证和验收测试
完成：已完成并验收

自定义字段配置

优先级：P0, P1, P2, P3
价值：高, 中, 低
组件：前端, 后端, 基础设施, 测试
估算：故事点或 T 恤尺寸
冲刺：当前冲刺分配
负责人：负责的团队成员
史诗：父史诗引用

9. 自动化和 GitHub Actions

自动问题创建

name: 创建特性问题

on:
  workflow_dispatch:
    inputs:
      feature_name:
        description: '特性名称'
        required: true
      epic_issue:
        description: '史诗问题编号'
        required: true

jobs:
  create-issues:
    runs-on: ubuntu-latest
    steps:
      - name: 创建特性问题
        uses: actions/github-script@v7
        with:
          script: |
            const { data: epic } = await github.rest.issues.get({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: ${{ github.event.inputs.epic_issue }}
            });

            const featureIssue = await github.rest.issues.create({
              owner: context.repo.owner,
              repo: context.repo.repo,
              title: `Feature: ${{ github.event.inputs.feature_name }}`,
              body: `# Feature: ${{ github.event.inputs.feature_name }}\n\n...`,
              labels: ['feature', 'priority-medium'],
              milestone: epic.data.milestone?.number
            });

自动状态更新

name: 更新问题状态

on:
  pull_request:
    types: [opened, closed]

jobs:
  update-status:
    runs-on: ubuntu-latest
    steps:
      - name: 移至评审中
        if: github.event.action == 'opened'
        uses: actions/github-script@v7
        # 将相关问题移至“评审中”列

      - name: 移至完成
        if: github.event.action == 'closed' && github.event.pull_request.merged
        uses: actions/github-script@v7
        # 将相关问题移至“完成”列

问题创建清单

创建前准备

[ ] 特性工件完整：PRD、UX 设计、技术分解、测试计划
[ ] 史诗存在：父史诗问题已创建，带有适当标签和里程碑
[ ] 项目看板已配置：列、自定义字段和自动化规则已设置
[ ] 团队容量已评估：冲刺规划和资源分配已完成

史诗级问题

[ ] 史诗问题已创建，包含全面描述和验收标准
[ ] 史诗里程碑已创建，带有目标发布日期
[ ] 史诗标签已应用：epic、优先级、价值和团队标签
[ ] 史诗已添加到项目看板的适当列

特性级问题

[ ] 特性问题已创建，链接到父史诗
[ ] 特性依赖已识别并记录
[ ] 特性估算已完成，使用 T 恤尺寸
[ ] 特性验收标准已定义，带有可衡量成果

故事/赋能者级问题记录在 `/docs/ways-of-work/plan/{epic-name}/{feature-name}/issues-checklist.md`

[ ] 用户故事已创建，遵循 INVEST 标准
[ ] 技术赋能者已识别并排序
[ ] 故事点估算已分配，使用斐波那契规模
[ ] 依赖关系已映射，在故事和赋能者之间
[ ] 验收标准已详细说明，带有可测试需求

成功指标

项目管理 KPI

冲刺可预测性：每冲刺完成 >80% 的承诺工作
周期时间：从“进行中”到“完成”的平均时间 <5 个工作日
前置时间：从“待办”到“完成”的平均时间 <2 周
缺陷逃逸率：<5% 的故事需要发布后修复
团队速度：跨冲刺一致的故事点交付

流程效率指标

问题创建时间：<1 小时创建完整特性分解
依赖解决时间：<24 小时解决阻塞依赖
状态更新准确性：>95% 的自动状态转换正常工作
文档完整性：100% 的问题具有所需模板字段
跨团队协作：<2 个工作日解决外部依赖

项目交付指标

完成定义合规性：100% 的已完成故事满足 DoD 标准
验收标准覆盖率：100% 的验收标准已验证
冲刺目标达成率：>90% 的冲刺目标成功交付
利益相关者满意度：>90% 的利益相关者对完成特性表示认可
规划准确性：估算与实际交付时间偏差 <10%

这种全面的 GitHub 项目管理方法确保了从史诗级规划到单个实现任务的完全可追溯性，并具有自动跟踪和所有团队成员的明确责任。

breakdown-plan

相关 Skills