mcpField
S
spec-to-plan

spec-to-plan

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

关于 spec-to-plan

spec-to-plan 将 PRD 转化为分阶段实施计划，供工程师和 Agent 使用。它以端到端垂直切片和长期有效的架构决策组织内容，并在确认阶段安排后写入 ./plans/ 中的 Markdown 计划。

主要功能

  1. 01PRD 转实施计划
  2. 02垂直 tracer-bullet 切片
  3. 03分阶段安排交付
  4. 04明确架构决策
  5. 05用户审阅阶段方案
  6. 06写入 ./plans/ Markdown 计划

适用场景

  1. 01为已确定的 PRD 制定计划
  2. 02按风险和价值安排功能切片
  3. 03为后续执行创建交接计划

安装

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

$npx skills add https://github.com/kambleakash0/agent-skills --skill spec-to-plan

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

详细介绍

将 PRD 转化为实施计划

此技能将需要构建的内容（PRD）转化为构建方式（分阶段实施计划）。它会将 PRD 拆分为 tracer-bullet 垂直切片，为切片安排阶段，并将结果写入 ./plans/ 下的 Markdown 计划文件。

使用时机

在以下情况下使用此技能：

  • 你已有 PRD 或同等规格文档，现在需要一份具体的实施计划。
  • 你希望从阶段的角度思考，而不只是列出问题：先构建什么、哪些内容可以延后，以及各个切片如何逐步构建。
  • 你打算从一份统一、持久的规划文档推动后续工作（例如 /slice-the-spec、/incremental-tdd）。

如果需求仍不明确，请先使用 /grill-me 和 /spec-writer。

工作流

如果上下文已经清楚，可以合并步骤，但请保留核心结构：PRD → 切片 → 阶段 → 计划文件。

  1. 确认 PRD 已在上下文中

    • 确保对话或代码仓库中有 PRD。
    • 如果没有，请让用户粘贴 PRD，或提供文件路径或问题链接。
    • 浏览并了解：目标、用户故事、功能需求、非目标和约束。

  2. （简单）探索代码库

    • 如果尚未针对这项功能探索代码库，请快速了解主要模块、集成层和架构模式。
    • 记录可能影响切片划分的约束（例如现有路由、数据模型、身份验证、第三方边界）。

  3. 确定持久的架构决策

    在划分切片之前，先确定那些不太可能随阶段变化、值得提前说明的决策：

    • 路由结构／URL 模式。
    • 数据库架构形态和关键表。
    • 核心数据模型和领域概念。
    • 身份验证／授权方式。
    • 第三方服务边界和集成点。

    将这些内容写入计划中的架构决策部分，供各阶段参考。

  4. 起草垂直切片（tracer bullets）

    • 将 PRD 拆分为 tracer-bullet 切片：贯穿所有相关层（架构、领域、API、UI、测试）的精简端到端部分。
    • 遵循垂直切片规则：
      • 每个切片都要贯穿所有必要层，交付范围精简但完整的路径。
      • 每个切片都可以单独演示或验证。
      • 优先选择多个精简切片，而不是少数几个庞大切片。
      • 不要纳入脆弱的实现细节（文件名、具体函数签名），因为这些可能会发生变化。
      • 要纳入持久的决策，例如路由路径、架构形态和模型名称。

  5. 将切片分组到各阶段

    • 根据风险和价值，将切片安排为 2–5 个合理的阶段。
    • 较早的阶段应：
      • 验证风险最高的假设。
      • 尽快交付可演示的成果。
      • 建立后续阶段可沿用的模式。
    • 后续阶段可以扩大覆盖范围、完善细节，或处理边缘情况和规模扩展。

  6. 征询用户意见

    • 以编号列表的形式展示拟定的阶段。 每个阶段都应列出：
      • 标题：简短、描述性名称。
      • 涵盖的用户故事：该阶段交付 PRD 中的哪些故事。
    • 询问：
      • 粒度是否合适（太粗／太细）？
      • 阶段的顺序是否正确？
      • 是否需要合并或拆分某些阶段？
    • 持续调整，直到用户批准此划分。

  7. 编写计划文件

    • 确保 ./plans/ 目录存在；如果不存在，则创建它。
    • 根据功能为计划文件命名（例如 ./plans/weekly-admin-summary-email.md）。
    • 使用并调整下方模板，填写架构决策，并为每个阶段添加一个部分。

计划模板

默认使用以下 Markdown 结构。

# Plan: <Feature Name>
> Source PRD: <brief identifier or link>

## Architectural decisions

Durable decisions that apply across all phases:

- **Routes:** ...
- **Schema:** ...
- **Key models:** ...
- **Auth:** ...
- **Third-party services:** ...
- (add/remove items as appropriate)

## Phases

### Phase 1: <Title>

#### What to build

A concise description of this vertical slice. Describe the **end-to-end behavior**, not layer-by-layer implementation.[1]

- Which user stories this phase covers.
- Which layers it will touch (data, domain, API, UI, background jobs, etc.).[1]

#### Acceptance criteria

- Criterion 1
- Criterion 2
- Criterion 3

***

### Phase 2: <Title>

#### What to build

...

#### Acceptance criteria

- ...

行为与规则

  1. 停留在计划层面。不要展开详细的实施计划或具体文件修改；这些属于 /tdd 等执行技能的工作。
  2. 权衡风险与价值。前期阶段应降低核心架构风险，并尽快交付可演示的内容。
  3. 保持切片纵向贯通。避免只“搭建数据库”或“构建 UI”却无法端到端交付价值的阶段。
  4. 明确决策。在计划标题中记录持久的架构决策，以便后续技能和人员复用。
  5. 为未来的自己和 Agent 撰写。计划应清晰易读、便于浏览，也易于交接给其他工程师或 AI Agent 作为起点。

评论

支持 Markdown