ghpm-status
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
Chineseghpm-status
ghpm-status
PREREQUISITE: Readfor prerequisites and error handling.../ghpm-shared/SKILL.md
Comprehensive project health dashboard. The goal is to give the user a rich, actionable overview — not just counts, but breakdowns that surface where work is concentrated, who's overloaded, and what needs attention. Think of this as the dashboard a project manager checks every morning.
前置要求: 阅读了解前置条件和错误处理方式。../ghpm-shared/SKILL.md
全面的项目健康仪表板。目标是为用户提供丰富且可执行的概览——不仅是统计数字,还能通过细分展示工作集中的区域、负荷过重的人员以及需要关注的事项。可以将其视为项目经理每天早上都会查看的仪表板。
Arguments
参数
- — full dashboard for the project
/ghpm-status - — scoped to a team or component name (matched against field options in
/ghpm-status <scope>).ghpm/config.json
- — 项目的完整仪表板
/ghpm-status - — 限定为团队或组件名称(与
/ghpm-status <scope>中的字段选项匹配).ghpm/config.json
Workflow
工作流程
Phase 1: Load Config and Cache
阶段1:加载配置与缓存
Follow the startup sequence in and load cache per .
../ghpm-shared/SKILL.md../ghpm-shared/references/cache.md遵循中的启动流程,并按照加载缓存。
../ghpm-shared/SKILL.md../ghpm-shared/references/cache.mdPhase 2: Aggregate
阶段2:聚合数据
Count items by workflow column (using the name from config to find the matching field on each item). Include a count for items with no status.
workflow.fieldIf a scope argument was provided, filter items first:
- Match the argument against all field option names in (case-insensitive).
.ghpm/config.json - If no exact match, try semantic/fuzzy matching. The user may use informal or umbrella terms that don't match any single field option but logically group several. Use your understanding of the project's team/component names to infer which options the user likely means, and combine them. Explain the mapping you chose (e.g., "Interpreting '<term>' as <option1> + <option2>").
- If you still can't determine a reasonable match, list available options and ask the user to clarify — but try hard to infer first.
- Filter items to only those matching the scope before aggregating.
Build the following sections from the cached items. Each section adds a different dimension of insight. Include all sections where the data exists — skip a section only if the project doesn't have that field.
按工作流列统计事项数量(使用配置中的名称查找每个事项上的匹配字段)。统计无状态的事项数量。
workflow.field如果提供了范围参数,先过滤事项:
- 将参数与中的所有字段选项名称进行匹配(不区分大小写)。
.ghpm/config.json - 如果没有精确匹配,尝试语义/模糊匹配。用户可能使用非正式或概括性术语,这些术语与单个字段选项不匹配,但在逻辑上包含多个选项。请结合你对项目团队/组件名称的理解,推断用户可能指代的选项并将其合并。说明你选择的映射关系(例如:“将'<术语>'解读为<选项1> + <选项2>”)。
- 如果仍然无法确定合理匹配,列出可用选项并请用户澄清——但请先尽力推断。
- 在聚合数据前,过滤出符合范围的事项。
从缓存的事项中构建以下板块。每个板块都添加了不同维度的洞察。包含所有存在数据的板块——仅当项目没有对应字段时才跳过该板块。
Component Health
组件健康状况
If a "Component" (or similar grouping) field exists, break down items by component × status. This reveals which areas of the project are healthy vs struggling. Show completion percentage per component and flag components with low completion or high active workload.
如果存在“Component”(或类似分组)字段,按组件×状态细分事项。这能揭示项目中哪些区域运行良好、哪些区域存在问题。显示每个组件的完成率,并标记完成率低或活跃工作量大的组件。
Epic Tracker
史诗追踪
If items have a "Level" or type field that distinguishes epics from tasks, show epic-level status separately. Active epics (InProgress) are especially useful — list them with their component and assignees. Flag unassigned active epics as a risk.
如果事项有“Level”或类型字段用于区分史诗(epic)与任务,单独展示史诗级别的状态。活跃中的史诗(InProgress)尤其有用——列出它们的组件和经办人。将未分配的活跃史诗标记为风险项。
Team Workload
团队工作量
Count InProgress items per assignee. This surfaces overload — anyone with 8+ concurrent InProgress items deserves a flag. Also count unassigned InProgress items.
统计每个经办人手中的进行中(InProgress)事项数量。这能发现负荷过重的情况——任何拥有8个及以上并发进行中事项的人员都应被标记。同时统计未分配的进行中事项数量。
Attention Items
需要关注的事项
Identify items needing attention:
- Untriaged: items with no status, no component, or no assigned team (check which fields exist in config — not all projects have these fields).
- No assignee: items in non-Done columns with empty assignees. Call out ReadyForDev items without owners specifically — they're bottlenecked.
- Active InProgress: items in InProgress status — count as a workload indicator. No date info is available, so don't claim staleness.
识别需要关注的事项:
- 未分类(Untriaged):无状态、无组件或未分配团队的事项(检查配置中存在哪些字段——并非所有项目都有这些字段)。
- 无经办人:处于非“Done”列且未分配经办人的事项。特别指出无负责人的ReadyForDev事项——它们是瓶颈所在。
- 活跃进行中:处于InProgress状态的事项——作为工作量指标统计。由于无日期信息,请勿提及是否停滞。
Available Views
可用视图
List available views with their layout type and filter text. Do NOT attempt to count items per view — filter parsing is handled by . Just show the view name, layout, and raw filter so the user knows what's available.
/ghpm-viewFor key normalization when matching fields, see .
../ghpm-shared/references/cache.md列出可用视图及其布局类型和过滤文本。不要尝试统计每个视图下的事项数量——过滤解析由处理。只需显示视图名称、布局和原始过滤条件,让用户了解可用选项。
/ghpm-view有关字段匹配时的关键标准化规则,请参阅。
../ghpm-shared/references/cache.mdPhase 3: Format Output
阶段3:格式化输出
Format per conventions in . Use markdown tables for breakdowns — they're easier to scan than flat text. Include a brief "Key Observations" section at the end that highlights 3-5 actionable insights (bottlenecks, risks, overloaded contributors).
../ghpm-shared/references/format.mdThe output should feel comprehensive. A good dashboard is one where the user doesn't need to ask follow-up questions to understand the project's health.
If scoped, prefix with the scope name:
<Project Title> — <scope> — <filtered count> of <total> itemsEnd with:
Use /ghpm-view <name> to drill into a view.按照中的约定进行格式化。使用Markdown表格展示细分内容——比纯文本更易于浏览。在末尾添加一个简短的“关键洞察”板块,突出3-5个可执行的发现(瓶颈、风险、负荷过重的贡献者)。
../ghpm-shared/references/format.md输出内容应全面。一个优秀的仪表板应能让用户无需后续提问即可了解项目健康状况。
如果限定了范围,在开头添加范围名称:
<项目标题> — <范围> — <过滤后数量> / <总数量> 事项结尾添加:
使用 /ghpm-view <名称> 深入查看具体视图。Tips
提示
- Read-only — never modifies the project or its items.
- 只读模式——绝不会修改项目或其事项。
See Also
另请参阅
- ghpm-shared — Prerequisites and error handling
- ghpm-view — Drill into a specific view
- ghpm-suggest — Get work recommendations
- ghpm-shared — 前置条件与错误处理
- ghpm-view — 深入查看具体视图
- ghpm-suggest — 获取工作建议