mcpField
A
agile-intake

agile-intake

github.com/djalmajr开发4121 次安装5 周前更新
代码仓库

关于 agile-intake

agile-intake 可将模糊想法或请求整理为结构化的需求登记文档，供团队在规划前明确约束和待解决问题，并选择路线图、Epic 或 Story 作为下一步。

主要功能

  1. 01将模糊请求整理为需求登记文档
  2. 02记录范围、约束和待解决问题
  3. 03建议路线图、Epic 或 Story
  4. 04支持保存或直接呈现

适用场景

  1. 01规划前澄清想法
  2. 02记录约束和未决事项
  3. 03选择敏捷流程的下一份文档

安装

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

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

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

附带文件templates/intake.md

详细介绍

需求初步梳理

使用此技能，将模糊的问题、初步想法或非结构化请求转化为清晰、可执行的需求初步梳理文档。

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

如果已填入 $ARGUMENTS（例如文件路径、文本、问题引用或 URL），请以此作为需求初步梳理的起点。 如果为空，请先询问用户简要描述问题。

语言

使用用户的语言撰写文档。确保语法正确，并使用所需的变音符号或特定文字。如果不清楚用户使用哪种语言，请在生成输出前询问。模板为英文，请翻译标题和内容以匹配用户的语言。

项目根目录

此技能会将文档写入相对于项目根目录（工作所在的仓库）的路径，而不是相对于 Agent 当前的工作目录。

  • 如果从项目内部调用，请使用此技能中所示的相对路径（例如 planning/<initiative>/intake.md）。
  • 如果从其他目录调用（例如从同级仓库调用，或项目位于其他位置），请在每个文档路径前添加 <project-root>/。
  • 如果项目根目录不明确，请在写入前通过宿主环境的问题工具向用户确认。

提问

遵循 CLAUDE.md / AGENTS.md（“Skill Prompting Conventions”）中的项目级约定。对于以下决策点，使用宿主环境的结构化提问工具——AskUserQuestion（Claude Code）、ask_user_question（Codex）或 question（OpenCode）。只有在路径／名称／值无法枚举时，才使用自由文本提问。

决策点使用结构化提问的原因建议选项
流程中的下一份文档决定后续流程/agile-roadmap · /agile-epic · /agile-story
保存需求初步梳理文档写入操作难以撤销保存 · 仅在此处展示

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

  • 计划名称（kebab-case 格式的标识符）
  • 问题描述和限制条件

无暂停模式：如果用户已明确关闭技能执行过程中的澄清提问，请将每个结构化问题转换为“待解答问题”下的条目（或等效内容），然后继续，不要暂停。

目标

  • 在制定计划前明确问题或机会
  • 确定限制条件、前提和待解答问题
  • 明确流程中的下一步：/agile-roadmap、/agile-epic 或 /agile-story
  • 避免在问题尚未明确时就开始工作

适用场景

  • 有人提出想法、需求或问题，但尚未明确范围
  • 请求过于模糊，无法直接转化为史诗或任务
  • 对工作规模、优先级或方法存在不确定性
  • 首次接触一个新问题

不适用场景

  • 问题已明确且范围已定义——直接使用 /agile-epic 或 /agile-story
  • 工作已完成拆分——转到 /agile-epic 或 /agile-story
  • 只是简单修复——直接使用 /agile-story

需求初步梳理流程

1. 倾听并记录

询问用户：

  • 问题或机会是什么？
  • 谁会受到影响？会受到怎样的影响？
  • 是否有紧急情况或截止日期？
  • 已知的限制条件有哪些？

不要臆测答案。如果用户不清楚，请将其记录为待解答问题。

2. 梳理需求

用收集到的信息填写模板：

  • 背景：问题、初始目标、价值信号、约束
  • 初始范围：包含什么、不包含什么（即使暂定）
  • 输入和参考资料：利益相关者、文档、技术背景
  • 未决问题：所有尚未得到解答的问题

**价值信号——探索性／示例项目：**如果项目属于探索性项目、示例项目或学习练习，请将 预期价值信号 标记为 N/A — 探索性，而不是凭空编造理想化的数字。真实产品指标应属于真实产品工作；示例项目不需要 KPI。

**假设与未决问题：**假设是记录下来以供审查的决策（Agent 已作出该决策，用户之后可以推翻）。未决问题是尚待决定的问题；如果不解决，就会阻碍下一份产物的生成。请根据实际情况填写对应部分。

3. 确定下一步

根据轨迹复杂度（而非持续时间）：

  • 存在依赖关系的多阶段轨迹（无论总持续时间如何）→ /agile-roadmap → 然后 /agile-epic 判断指标——符合 2 项或以上时，使用路线图：
    • 有多个需要排序的计划（无法全部并行推进）
    • 当前的决策会影响未来的决策（局部优化可能演变成技术债）
    • 利益相关者需要先了解整个推进过程，再批准各个步骤
    • 存在外部依赖（其他团队、供应商、截止日期）
    • 总体复杂度超出单个 Epic 的承载范围
  • 范围广泛的单个协同计划 → /agile-epic
  • 范围适中的问题 → /agile-epic（拆解为故事）
  • 范围明确的小问题 → /agile-story

**重要：**路线图并非由时间跨度（例如“3-12 个月”）决定。一个为期 4 周、包含 5 个不同阶段且有关键顺序要求的计划，同样适合使用路线图。判断标准是轨迹复杂度，而非持续时间。

在需求梳理中记录建议，并与用户确认。

**流程规则：**对于大型或复杂事项，执行前必须通过 /agile-epic 进行拆解。只有小型、局部的事项可以跳过这一步，直接进入 /agile-story。

4. 保存需求梳理
  • 询问计划名称（例如 component-tests、auth-refactor、mvp-reserva）。选择一个描述计划（而非产物）的 kebab-case slug。避免使用连续编号、日期或 intake-1 之类的标签；选择一个足够稳定、能适应范围变化的 slug。
  • 保存到 planning/<initiative>/intake.md
  • 如果用户不想保存，则直接在对话中提供
5. 衔接后续流程

用户确认后，按照官方流程提出生成下一份产物：

  • 多阶段轨迹 → “要我创建 /agile-roadmap 吗？”
  • 单个协同计划 → “要我运行 /agile-epic 来拆解为故事吗？”
  • 小型／明确事项 → “要我创建 /agile-story 吗？”
6. 验证

结束需求梳理前，确认：

  • 问题足够清晰，可以进入下一步
  • 已明确列出约束和前提
  • 已确定流程中的下一份产物

规则

  • 绝不能从需求梳理直接跳到实现。需求梳理生成的是下一份产物，而不是代码。
  • 如果用户坚持在问题尚不清晰时就开始，请记录风险，并询问他们是否仍要继续。
  • 需求梳理应简短——对话最长 10 到 15 分钟。如果耗时更长，说明问题可能需要通过 /agile-epic 进行拆解。
  • 保持探索式语气，不要进行详细规划。

模板

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

与流程的关系

flowchart LR
    A["/agile-intake"] --> B{next step}
    B --> C["/agile-roadmap"]
    B --> D["/agile-epic"]
    B --> E["/agile-story"]

此技能是流程的入口。它会梳理问题，并引导至正确的技能。要了解应使用哪个技能，也可以使用 /agile-router。

评论

支持 Markdown