mcpField
M
mb-from-prd

mb-from-prd

github.com/mrvladd-dAgent 工作流5640 次安装21 周前更新
代码仓库

关于 mb-from-prd

mb-from-prd 是一项技能，可将已明确的绿地项目 PRD 转为结构化的 Memory Bank 产品、需求、史诗和功能文档，并安排设计与逐功能任务规划的审核流程。

主要功能

  1. 01创建产品与需求记录
  2. 02将需求映射到史诗、功能和测试
  3. 03起草含验收标准的史诗与功能
  4. 04安排 SDD 设计和功能规划
  5. 05更新 Memory Bank 索引及支持文档

适用场景

  1. 01根据已澄清的 PRD 建立规划文档
  2. 02追踪需求与实施规划的对应关系
  3. 03生成任务前准备逐功能规划

安装

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

$npx skills add https://github.com/mrvladd-d/memobank --skill mb-from-prd

安装后在 Claude Code 中输入/mb-from-prd确认已加载。

附带文件references/epic-template.mdreferences/feature-template.md

详细介绍

mb-from-prd — PRD → Memory Bank（从零开始）

  • 功能： 将 PRD 转换为结构化的项目信息和可追溯的规划产物。
  • 适用场景： 项目从零开始，且已有 prd.md 或同等要求文档。
  • 输入： prd.md 或用户提供的 PRD 文本，以及已初始化的 .memory-bank/。
  • 输出： 产品、RTM、Epic、Feature 和 SDD 设计路由，供必需的 /spec-design 和各 Feature 的 /spec-improve 执行后，再运行 /prd-to-tasks。

前置条件

  • 当前位于仓库根目录。
  • .memory-bank/prd.md 存在，且包含 type: prd、clarification_status: complete 和 constitution_checked: true；否则先运行 /write-prd。
  • .memory-bank/spec-index.md 在运行 /spec-init 后存在，作为 PRD 分解所需的轻量级 SDD 路由图。在 /prd 之后，必需的 /spec-design 会使用该路由图，记录最小或完整的骨干门槛；如果多个 Feature 共用领域、模型、契约、状态、安全或运行时设计，还可能更新骨干 SDD 规范和 spec-index。
  • 可选的分析产物（例如产品简报）可以存在；将其用作上游 PRD 输入，但不强制要求。
  • .memory-bank/ 存在。如果不存在，先运行 mb-init（或手动创建目录骨架）。

流程

1) 加载已澄清的 PRD
  1. 读取 .memory-bank/prd.md。
  2. 确认 frontmatter 包含 type: prd、clarification_status: complete 和 constitution_checked: true。
  3. 如果 PRD 中包含影响分解的未解决 NEEDS CLARIFICATION 标记，则停止。
  4. 将 .memory-bank/spec-index.md 作为轻量级 SDD 路由图读取。如果索引缺失、过时、仅含占位内容、链接失效、含义模糊，或无法安全识别相关现有规范及计划中/候选/未知/不适用领域，则停止并运行 /spec-init。
  5. 根据 PRD 章节、受影响的产品领域、需求、参与者、数据/领域模型、契约/API、状态/生命周期、安全/合规、运行时/运维及验证策略，确定相关的权威规范。
  6. 仅解析并读取 .memory-bank/spec-index.md 路由到的相关权威规范文件。默认不要加载所有 SDD 规范。
  7. 如果相关权威规范与 PRD 冲突，则停止，并要求通过修改规范或 PRD 明确解决。
  8. 启动任务协议文件夹：
    • .protocols/PRD-BOOTSTRAP/
    • plan.md（步骤）
    • decision-log.md（问答和选择）
2) 技能 / 工具发现（可选但推荐）

如果 PRD 提到“使用技能 / 工具 / CLI”：

  • 运行 /find-skills（优先使用项目已安装的技能，其次使用 marketplace）
  • 提出一组精简的相关技能供使用（未经确认不要安装）
3) 此处不进行深入提问

PRD 层面的歧义由 /write-prd 处理。本技能中不要进行多轮深入提问。 可选的分析（/analysis、/brainstorm、/brief）可以改进 /write-prd 的输入。

如果目标模式为完全自主：

  • 可以将非阻塞的缺口记录为明确的 Assumptions
  • 阻塞性缺口（安全/合规/外部契约/数据丢失风险）必须使流程停止
4) 编写 L1 产品简报

更新 .memory-bank/product.md（使用用户的措辞）。

5) 需求 + RTM

更新 .memory-bank/requirements.md：

  • 枚举 REQ-ID。
  • 定义“范围之外”的内容。
  • 填写 RTM：REQ → Epic → Feature → Test。
6) 创建 Epic（L2，优先起草）

对于每个 Epic：

  • 创建 .memory-bank/epics/EP-<NNN>-<slug>.md
  • 使用 references/epic-template.md。
  • 确保包含业务价值和成功指标。
  • 仅在有证据依据时，填写 Source artifacts、Normative inputs 和 Constraints / invariants 等可选章节。
  • 默认设置 status: draft，直至解决所有待处理问题。
7) 创建功能（L3，先起草）

对于每项功能：

  • 创建 .memory-bank/features/FT-<NNN>-<slug>.md
  • 使用 references/feature-template.md。
  • 确保功能可自主完成，并明确列出验收标准。
  • 默认不添加澄清元数据。只有当 PRD 明确指出会影响任务拆解的功能级阻塞项时，才添加 clarification_status: pending|blocked。
  • 仅在有证据支持时填写 Source artifacts、Normative inputs、Constraints / invariants 和 Verification targets 等可选部分。
  • 在每项功能中加入 ## SDD Design Gate 部分。该部分会在 /prd-to-tasks FT-<NNN> 前引导至 /spec-improve FT-<NNN>，但不会引入占位符 spec_design_status 或新的阻塞状态。
  • 默认将状态设为 status: draft，直到验收标准和验证计划都足够完善。
8) 任务规划（按功能进行，不要“一次规划所有内容”）

不要一次性“硬来”地为所有功能生成完整任务队列。

请改为：

  1. 确保 .memory-bank/schemas/task.schema.json 和 .memory-bank/tasks/index.json 存在。全新的骨架可以包含 { "version": 1, "tasks": [] }。
  2. 在 /prd 后运行 /spec-design。对于简单且独立的 T0/T1 功能，可将不相关领域标记为 not_applicable，并记录最小主干；对于共享的 T2/T3 问题，则创建或更新所需的主干 SDD 规范和 spec-index。这不是另一个强制的繁重阶段：它不会创建任务，也不会设计功能局部实现。
  3. 对于每项选定的功能，先运行 /spec-improve FT-<NNN>，再运行 /prd-to-tasks FT-<NNN>，生成：
    • .memory-bank/tasks/plans/IMPL-FT-<NNN>.md
    • 按 wave 分组的原子化 .memory-bank/tasks/TASK-*.task.json 记录，每条记录都必须包含 tier: T0|T1|T2|T3

当结构化证据充足时，这些功能级计划和任务记录可包含更丰富的可选字段，例如 source_artifacts、normative_inputs、constraints、invariants 和 verification_targets。 任务路由只能通过 task.tier 确定；旧的 risk / risk.level 模型无效。 标准的 SDD 规划路径为 /write-prd → /spec-init → /prd → /spec-design → /spec-improve FT-<NNN> → /prd-to-tasks FT-<NNN>。/spec-improve 仍是强制主干关卡之后的功能级关卡。只有在某项功能被明确标记为待澄清或受阻时，才运行 /clarify-feature FT-<NNN>。对于类似简单 T0/T1 的功能，/spec-improve 可设置 spec_design_status: not_required，并附上简要理由。

这样可以确保规划准确，并避免任务数量因推测而激增。

9) 关键概念的支持文档

对于任何需要“阅读许多文件”才能理解的概念，都要创建支持文档。

兼容性／默认路径：

  • .memory-bank/architecture/<concept>.md（是什么／为什么）
  • .memory-bank/guides/<concept>.md（如何操作）

可选的扩展支持文档：

  • .memory-bank/contracts/...
  • .memory-bank/states/...
  • .memory-bank/runbooks/...
  • .memory-bank/testing/...

规则：

  • 传统的双文档仍然有效且有用
  • 更丰富的文档属于补充内容，且应有证据依据
  • 如果存在更丰富的文档，应在 .memory-bank/spec-index.md 以及相关功能／概念文档中链接到这些文档
  • 创建新规范前，先通过 .memory-bank/spec-index.md 检查现有规范
10) 更新索引

更新 .memory-bank/index.md，添加指向所有新增内容的说明性链接。

11) 审查关卡

在全新上下文中进行审查（优先使用 mb-review）。

12) 自主交接（可选）

如果目标是“PRD → 完成，期间无需用户进一步交互”：

  • 不要在此处手动执行任务
  • 交接给生成的项目命令 /autonomous

完成定义

  • product.md 与 requirements.md 内容一致。
  • 每个 REQ 都映射到 RTM 中的 Epic/Feature。
  • Epic 和 Feature 均已创建，并包含验收标准。
  • .memory-bank/spec-index.md 为现有／计划中／候选／未知／不适用的 SDD 设计领域提供路由。
  • mb-from-prd 本身不要求创建由 schema 支持的任务记录。
  • 如果通过 /spec-improve FT-<NNN> 和 /prd-to-tasks FT-<NNN> 明确继续进行任务规划，则由 schema 支持的任务记录会编入 .memory-bank/tasks/index.json；每个任务都有 tier。
  • 已更新 index.md。

评论

支持 Markdown