mcpField
A
agile-status

agile-status

github.com/djalmajr生产力4120 次安装5 周前更新
代码仓库

关于 agile-status

agile-status 是用于跟踪交付进度的技能，面向需要记录阶段进展、周期汇总或正式交付收尾的团队。它按不同模式整理阻塞项、风险、验证和后续步骤，并维护与计划或问题的可追溯性。

主要功能

  1. 01快速记录进展、阻塞项和下一步
  2. 02汇总周期交付、偏差与风险
  3. 03正式收尾并记录验证和交接
  4. 04关联计划、故事或问题以追溯

适用场景

  1. 01记录每日或任务中的进度检查点
  2. 02为干系人整理每周或里程碑状态
  3. 03完成故事或 Epic 后核对交付与验证

安装

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

$npx skills add https://github.com/djalmajr/skills --skill agile-status

安装后在 Claude Code 中输入/agile-status确认已加载。

附带文件templates/status.md

详细介绍

状态

使用此技能跟踪交付进度。它会根据用户的需求进行调整：快速检查点、阶段性汇总或交付收尾。

通过斜杠命令收到的初始上下文：$ARGUMENTS

如果 $ARGUMENTS 不为空（例如，项目名称、问题、计划引用、“daily”、“report”、“close”），请以此为起点。 如果为空，请询问用户需要什么：检查点、汇总还是收尾。

语言

使用用户的语言编写文档。确保语法正确，并使用所需的变音符号或特定文字系统字符。如果无法确定用户使用的语言，请先询问。模板为英文——请翻译标题和内容，以符合用户的语言。

项目根目录

此技能会在项目根目录（开展工作的代码库）下的相对路径中写入文档，而不是在 Agent 当前的工作目录中。

  • 如果从项目内部调用，请使用此技能中显示的相对路径。
  • 如果从其他目录调用（例如，兄弟代码库，或项目位于其他位置），请在每个文档路径前添加 <project-root>/。
  • 如果无法确定项目根目录，请通过 harness 的提问工具与用户确认，然后再写入。

提问

遵循项目级约定 CLAUDE.md / AGENTS.md（“Skill Prompting Conventions”）。对于以下决策点，请使用 harness 的结构化提问工具——AskUserQuestion（Claude Code）、ask_user_question（Codex）或 question（OpenCode）。

决策点结构化提问的原因建议选项
模式选择模板和流程检查点 · 汇总 · 收尾
后续步骤（按故事收尾）决定下一步操作下一步 /agile-story · 稍后汇总 · 无
后续步骤（周期结束收尾）决定下一步操作/agile-review · /agile-retro

自由文本提问（不使用结构化工具）：

  • 阻碍因素描述
  • 进度叙述

无需暂停模式：如果用户明确禁用了技能执行期间的澄清，则将每个结构化提问转换为“待解决问题”下的条目（或等效内容），然后继续执行，不要暂停。

目标

  • 根据计划、故事或史诗跟踪实际进度
  • 明确记录阻碍因素及其影响、负责人和后续行动
  • 汇总某一阶段的交付、偏差和风险
  • 通过验证和交接正式完成交付
  • 与当前计划或问题保持可追溯性

模式

检查点（原 /daily）

快速状态更新——进度、阻碍因素、下一步。用时少于 5 分钟。

适用场景：

  • 每日或每个工作阶段的进度更新
  • 出现需要明确记录的阻碍因素
  • 任务中途检查点

流程：

  1. 找出当前计划、故事或问题。
  2. 记录自上个周期以来取得的进展。
  3. 记录阻碍因素及其影响、负责人和后续行动。
  4. 明确下一项可观察的步骤。

保存位置：

  • 默认在对话中直接呈现（检查点内容简短）
  • 如果用户要求保存：planning/<initiative>/status/YYYY-MM-DD.md
汇总（原 /status-report）

阶段或里程碑总结——已完成事项、偏差、风险和待决策事项。

适用场景：

  • 利益相关者询问某项计划“进展如何？”
  • 史诗或冲刺中期的综合情况
  • 每周/每两周状态总结
  • 冲刺评审前准备状态概览

流程：

  1. 确定报告范围（阶段、里程碑、计划）。
  2. 从检查点、计划、史诗/故事和 git 日志中收集信息。
  3. 汇总：已完成、进行中、偏差、风险和待决策事项。
  4. 明确后续步骤及负责人。

保存位置：

  • planning/<initiative>/status/report-YYYY-MM-DD.md
  • 或者，如果报告较短，则在对话中直接呈现
交付收尾（原为 /post-impl）

正式完成交付收尾——对照计划与实际结果、验证情况、剩余风险和交接事宜。

使用时机：

  • 计划、故事或史诗已完成
  • 开始下一次交付之前
  • 复盘之前，用于创建客观记录

流程：

  1. 确定要收尾的交付内容（计划、故事或史诗）。
  2. 起草前检查范围偏移。 对照故事的验收标准运行 git diff（或等效操作）。明确列出任何无法对应到验收条目的改动，并说明每项改动的理由。在撰写时发现范围偏移，而不是事后才发现。
  3. 对比计划与结果：交付了什么、还有什么待完成、范围有哪些变化。
  4. 执行验证：lint、类型检查、测试和手动验证。记录实际结果。
  5. 记录剩余风险和后续步骤。
  6. 明确交接安排（谁需要了解情况）。

收尾范围（影响后续流程）：

  • 单故事收尾——在进行中的史诗或冲刺中完成单个故事。不要触发 /agile-retro；建议进行下一个 /agile-story，或稍后进行整合。
  • 周期结束收尾——史诗完成、冲刺结束或计划完成。建议先进行 /agile-review（演示 + 指标），然后进行 /agile-retro。

保存位置：

  • planning/<initiative>/status/<mode>-YYYY-MM-DD-<slug>.md——<slug> 用于区分同一天的多个收尾文件（例如，closure-2026-05-12-story-01.md）。
  • 如果是独立计划：直接在行内呈现

如何确定模式

  • 需要快速检查点？ → 检查点模式
  • 需要整合一段时期或一个里程碑？ → 整合模式
  • 交付已完成，需要收尾？ → 收尾模式
  • 不确定？ 询问用户背景，并建议合适的模式。

后续流程

  • 检查点：如果存在关键阻碍 → 升级处理或调整计划。如果交付即将收尾 → 切换到收尾模式。
  • 整合：如果周期结束并完成了一项交付 → 建议使用收尾模式。如果冲刺结束 → 建议使用 /agile-review 或 /agile-retro。
  • 收尾（单故事）：建议进行下一个 /agile-story，或稍后进行整合。单个故事的收尾不要触发 /agile-retro。
  • 收尾（周期结束）：建议使用 /agile-review，然后使用 /agile-retro。如果属于某个史诗，也要更新史诗概览中的故事状态。

参考模板

使用此技能中的 templates/status.md 作为基础。

规则

  • 每次更新都必须反映真实状态，而不是乐观的预期。
  • 阻碍必须说明影响、负责人和下一步行动，不能只有描述。
  • 检查点必须引用具体的计划、故事或问题，以便追踪。
  • 收尾模式必须始终运行 lint、类型检查和测试。不要假设它们会通过。
  • 报告实际结果，而不是预期。如果 lint 失败，就明确说明失败。
  • 保持适度——检查点应在 5 分钟内完成，整合应在 15 分钟内完成。

与工作流的关系

flowchart LR
    A["/agile-story"] --> B[execution]
    B --> C["/agile-status<br>(checkpoint)"]
    C --> D["/agile-status<br>(consolidation)"]
    D --> E["/agile-status<br>(closure)"]
    E --> F["/agile-retro"]

此技能负责所有交付跟踪。规划请使用 /agile-intake、/agile-epic 或 /agile-story。仪式请使用 /agile-sprint、/agile-review 或 /agile-retro。

评论

支持 Markdown