mcpField
S
slice-the-spec

slice-the-spec

github.com/kambleakash0开发1077 次安装今天更新
代码仓库

关于 slice-the-spec

slice-the-spec 将已明确的 PRD 拆分为少量端到端 GitHub issue，供开发团队或 Agent 并行执行。它会梳理依赖、验收标准及需人工判断的任务，并在生成 issue 前迭代确认拆分方案。

主要功能

  1. 01将 PRD 拆成垂直切片
  2. 02探索代码库与集成点
  3. 03标注 HITL 和 AFK 任务
  4. 04定义验收标准与依赖
  5. 05生成 GitHub 就绪 issue

适用场景

  1. 01把明确的 PRD 转成看板任务
  2. 02为多名工程师或 Agent 安排并行工作
  3. 03在实施前识别依赖和人工决策

安装

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

$npx skills add https://github.com/kambleakash0/agent-skills --skill slice-the-spec

安装后在 Claude Code 中输入/slice-the-spec确认已加载。

详细介绍

将 PRD 转化为 Issues

此技能可将已明确的 PRD 转化为一组精简、清晰的待办事项，拆分为纵向切片的 GitHub issue。每个 issue 都应是一个可独立领取的“示踪弹”，贯穿所有相关层并端到端交付价值，尽早暴露未知的问题。

适用场景

用户有以下需求时，可使用此技能：

  • 用户已有 PRD 或类似规格说明（可能通过 /spec-writer 创建），现在希望生成具体的 issue。
  • 用户想把“目标”文档转化为看板上的任务。
  • 用户需要拆分工作，让多位工程师或 Agent 并行工作且互不干扰。

如果尚无 PRD，或者需求尚不清晰，建议先使用 /grill-me 和 /spec-writer。

概念

  • 纵向切片 / 示踪弹： 一小块端到端的功能，贯穿所有必要层（数据、领域、API、UI 等），而不是只涉及某一层。
  • HITL issue： 需要人参与决策的 issue（设计评审、利益相关方签字确认、高风险重构等）。
  • AFK issue： 对人类来说“离开键盘”也安全的 issue；自主 Agent 可以在无需人工干预的情况下完成实现并合并。

尽可能优先选择 AFK 切片，但涉及人类判断的地方要明确标记为 HITL。

工作流

如果上下文已经给出了答案（例如，PRD 已加载且范围明确），可以合并或跳过步骤。

  1. 定位并理解 PRD

    • 从对话或代码库中找到 PRD（issue、文档、文件）。
    • 浏览并了解目标、用户故事、功能需求和明确的非目标。
    • 如果存在多个 PRD，请向用户确认要使用哪一个。

  2. 探索代码库

    • 检查仓库的相关部分，了解当前架构、主要模块和可能的集成点。
    • 记录需要遵循的现有模式（例如已有的功能标志、后台任务、通知系统）。

  3. 起草纵向切片（示踪弹）

    • 将 PRD 拆分为少量纵向切片，每个切片都能端到端交付价值，并覆盖系统的多个层。
    • 避免“设置数据库表”或“构建所有 UI 组件”这类横向切片，除非确有必要；应将这些工作纳入端到端切片。
    • 为每个切片判断它属于 HITL 还是 AFK；风险较低时优先选择 AFK。

  4. 定义 issue 结构和依赖关系 为每个切片定义：

    • 标题： 简短、明确，并与用户价值直接相关。
    • 类型： HITL 或 AFK。
    • 描述： 说明此 issue 将交付什么，并引用具体的用户故事和 PRD 章节。
    • 验收标准： 明确且可测试，并涵盖边缘情况。
    • 阻塞项： 必须先完成的其他切片（如有）。

    至少确定一个无阻塞、可立即开始的 issue。

  5. 询问用户并迭代 将拟议的拆分方案以编号切片列表的形式呈现，并包括：

    • 标题
    • 类型（HITL/AFK）
    • 阻塞项
    • 覆盖的用户故事

    询问用户：

    • 粒度是否合适（太粗还是太细）？
    • 依赖关系是否正确？
    • 是否应将某些切片合并或拆分？
    • HITL 与 AFK 的标记是否恰当？

    反复调整，直到用户批准拆分方案。

  6. 生成可直接用于 GitHub 的 issues

    • 为每个已批准的切片生成可直接用于 GitHub 的 issue 正文（Markdown），包括：
      • 上下文摘要
      • 详细任务描述
      • 验收标准
      • PRD 和相关 issue 的链接
      • HITL/AFK 标记，以及给人工评审者的备注
    • 如果仓库约定明确，也可以将它们归入史诗级任务或添加标签。

行为与规则

  1. 优先拆分为少量、高杠杆的切片，而不是几十个微小问题。
  2. 每个问题都应确保拿到 PRD 和代码仓库的人无需过多澄清即可实现。
  3. 优先选择能打通系统中范围较窄但真实可用路径的纵向切片，而不是宽泛的基础工作——后者不会带来用户可见的变化。
  4. 始终明确标出并说明 HITL 工作；不要把需要人工决策的事项隐藏在 AFK 问题中。
  5. 如果 PRD 缺少关键信息，应提出少量有针对性的澄清问题，而不是自行猜测；或者建议返回 /spec-writer。

示例

输入： 一份描述面向团队管理员的新每周摘要邮件功能的 PRD，包含详细的用户故事和需求。

你：

  1. 找到 PRD 文件或问题，浏览目标、用户故事和非目标。
  2. 探索代码仓库，找到现有的通知和邮件基础设施。
  3. 提出 3–5 个纵向切片，例如：
    • “用于计算每周管理员指标的引擎（AFK）”
    • “管理员可配置的摘要邮件模板（HITL）”
    • “安排并发送每周摘要邮件（AFK）”
    • “用于预览和启用每周摘要的管理员界面（HITL）”
  4. 列出这些切片的类型、依赖项以及对应的用户故事；根据用户反馈进行完善。
  5. 为每个切片生成最终的 GitHub 问题正文，可直接粘贴或通过 API 创建。

评论

支持 Markdown