TTokenySpace
返回 Skills 列表

Muniu Liumia

Spec-Driven Development:解析 PRD 需求、设计系统架构、拆解开发任务、生成实现指导、审计交付质量——覆盖从原始需求到可交付代码全流程的 Skill 包。当用户需要分析需求文档、做架构设计、准备开发或检查需求完成情况时使用,通过 /mnlm 命令触发。

#中文
0

安装到 Tokeny(自动)

下载 ZIP
安装"muniu-liuma"技能
技能信息:
- 名称: Muniu Liumia
- 标识: muniu-liuma
- 描述: Spec-Driven Development:解析 PRD 需求、设计系统架构、拆解开发任务、生成实现指导、审计交付质量——覆盖从原始需求到可交付代码全流程的 Skill 包。当用户需要分析需求文档、做架构设计、准备开发或检查需求完成情况时使用,通过 /mnlm 命令触发。
- 版本: 1.0.0
下载地址:
https://www.tokeny.space/api/skills/muniu-liuma/download
继续

复制上方内容到 Tokeny 客户端并在会话中发送即可自动安装;也可直接 下载 ZIP并拖动到技能窗口安装。

SKILL.md

MuniuLiuma(木牛流马)

将原始需求文档高效转化为可交付代码的全流程 Skill 包。5 个 Phase 按数据依赖串联,根据用户意图和上下文状态自动决策执行范围。

命令

/mnlm           触发 Skill,Agent 根据用户意图和上下文自动决策执行范围

用户也可通过自然语言触发(如"解析这份需求"、"做架构设计"、"拆任务"、"检查完成情况"),Agent 自动识别对应的执行范围。

触发判断

第一步:开发意图检测

意图类型示例是否触发
显式命令/mnlm✅ 触发
解析请求"分析/解析/拆解这份需求"✅ 触发
开发动作前置"根据这个需求做架构"、"基于PRD排任务"✅ 触发
质量审查"检查PRD有没有遗漏"、"需求有什么模糊点"✅ 触发
仅分享无动作"你看下这份需求"、"先看看"❌ 不触发
无附加说明直接甩链接/文件,无附加文字❌ 不触发
闲聊"这PRD写得太长了"❌ 不触发

第二步:自动触发建议

在开发意图检测过程中,如果用户没有主动要求结构化分析,但检测到以下信号,Agent 主动建议是否使用 MuniuLiuma:

信号Agent 建议
用户描述了复杂需求但未要求结构化分析"检测到你的需求涉及多个功能点,建议先走 /mnlm 结构化梳理,确保不遗漏。"
用户开始编码但未做需求梳理"检测到当前需求尚未结构化梳理,建议先运行 /mnlm 解析。"
用户对话中累积了多个零散需求点"检测到对话中已累积多个需求点,建议统一走 /mnlm 梳理。"
  • 用户拒绝后不再重复建议,除非需求复杂度显著增加(如新增 3 个以上功能点)
  • 用户主动说"不用""直接做"时,尊重用户选择

不触发时保持静默,等待用户进一步指示。

第三步:输入内容验证(仅 Phase 1)

触发后判断文档类型:

  • 是 PRD / 需求文档 / 功能描述 → 进入解析流程
  • 是其他类型(API 文档、设计稿、会议纪要等) → 告知"这不是需求文档(检测到类型:XX)",询问意图
  • 无法判断 → 主动询问"这是需求文档吗?需要我解析吗?"

范围评估

触发后、进入决策流程前,评估需求规模是否适合走全流程:

评估结果判定标准Agent 行为
太大涉及多系统重构、跨团队架构迁移、完整产品从零搭建建议用户拆分为多个独立需求,逐个走流程
太小修改单个变量、调整一行配置、修复一个明确的 bug建议用户直接实现,无需走全流程
刚好一个完整功能的需求、一个用户故事、一个模块的新增或重构进入决策流程

用户坚持走全流程时尊重用户选择,但在输出中标注范围评估结果。

项目模式识别

根据上下文判断当前属于哪种开发模式:

模式识别信号流程差异
Greenfield(新项目)项目目录为空、无已有代码、用户明确说"从零开始"标准流程:Phase 1 → 5
Brownfield(已有项目)项目目录有代码、用户提到现有功能、"给XX加个功能"、"重构XX模块"Phase 2 必须先扫描现有架构,做增量设计而非全量设计
Retrofit(逆向补文档)用户说"帮我理解这段代码"、"给这个模块补 Spec"Phase 1 从代码反向生成 Spec,而非从 PRD 正向提取

Brownfield 模式下 Phase 2 的额外步骤:

  1. 扫描项目现有架构(模块划分、技术栈、API 风格)
  2. 分析新需求对现有架构的影响(新增/修改/不变)
  3. 做架构一致性检查(新设计是否与现有模式冲突)
  4. 标注与现有架构不一致的地方,供用户确认

决策流程

收到用户指令后,按以下步骤判断执行范围:

第一步:确定目标 Phase

用户意图目标 Phase
"全流程"或明确要求跑完全部Phase 1 → 5 全链路
"解析需求"、"分析这份 PRD"Phase 1
"做架构设计"、"设计方案"Phase 2
"拆任务"、"排任务"Phase 3
"准备开发"、"实现指导"Phase 4
"检查完成情况"、"审计"Phase 5

第二步:递归检查前置依赖

目标 Phase N 的 [必需] 输入都存在?
  ├── ✅ 全部存在 → 直接从 Phase N 开始执行
  └── ❌ 缺失 → 回溯到 Phase N-1
        ├── Phase N-1 的输入存在 → 执行 Phase N-1 → 输出传给 Phase N
        └── 仍缺失 → 继续回溯...直至 Phase 1

各 Phase 的必需输入:

Phase必需输入缺失时的补齐策略
Phase 1:prd-parserPRD/需求文档(文本)无法补齐,主动询问用户提供
Phase 2:arch-designer结构化 Spec检查上下文有无原始 PRD → 有则先跑 Phase 1
Phase 3:task-planner架构设计方案检查上下文有无 Spec → 有则先跑 Phase 2
Phase 4:implementation任务清单 + 架构设计检查上下文有无任务清单 → 有则先跑 Phase 3 → 无则继续回溯
Phase 5:traceSpec + 架构 + 任务清单 + 实现指导 + 代码逐层回溯补齐全部上游产物

第三步:执行并输出

  1. 按补齐后的链路依次执行,中间产物保留在对话上下文中
  2. 遵循「输出规范」完成最终输出
  3. 每个 Phase 执行完毕后,将关键产物展示给用户确认,用户确认后再进入下一 Phase

Agent 停止规则

以下场景中 Agent 必须暂停执行并向用户确认,而非自行继续:

停止场景触发条件Agent 行为
范围过大需求涉及 5 个以上独立功能域或跨系统重构列出拆分建议,等待用户确认拆分方案
需求矛盾Spec 中发现 3 个以上无法自动解决的需求冲突列出矛盾项和可选方案,等待用户决策
架构风险Phase 2 检测到现有架构存在严重问题(如单点故障、硬编码依赖)标注风险并建议优化,用户决定是否先处理
回退请求用户在任意 Phase 表示上游产物有问题暂停当前 Phase,回退到用户指定的上游 Phase 重新执行
Phase 完成每个 Phase 输出完毕后展示产物摘要,询问用户是否确认继续

执行示例

标准路径

用户说上下文状态决策实际执行
"根据这个 PRD 做架构"有 PRD,无 SpecPhase 2 缺 Spec → 回溯 Phase 1Phase 1 → Phase 2
"解析这份需求" + 文件无上下文Phase 1 有文档输入Phase 1
"检查需求完成情况"全链路产物齐全Phase 5 输入齐全Phase 5
"帮我拆任务"仅有 SpecPhase 3 缺设计 → 回溯 Phase 2Phase 2 → Phase 3
"准备开发"有任务清单Phase 4 有输入Phase 4
"审计一下代码"仅有代码回溯至 Phase 1 也缺 PRD告知用户缺少需求基线,由用户决策

范围评估场景

用户说范围评估Agent 行为
"帮我重构整个电商系统"太大建议拆分为独立模块(用户服务、订单服务、支付服务等),逐个走流程
"把按钮颜色改成蓝色"太小建议直接实现,无需走全流程
"给登录模块加双因子认证"刚好进入决策流程

Brownfield / 已有项目场景

用户说上下文状态决策实际执行
"给现有的用户模块加个权限管理"项目已有代码Brownfield 模式 → Phase 2 先扫描现有架构Phase 1 → Phase 2(含现有架构分析)
"帮我理解这段遗留代码,补个文档"无 PRD,有代码Retrofit 模式 → Phase 1 从代码反向生成 SpecPhase 1(逆向提取)
"这个模块之前做过架构设计,现在要加新需求"有历史架构文档Phase 2 加载历史架构,做增量设计Phase 1 → Phase 2(增量模式)

异常与回退场景

用户说上下文状态决策实际执行
"Spec 里漏了一个功能,补上"Phase 2 已执行回退到 Phase 1 补充,再重新执行 Phase 2Phase 1(增量更新)→ Phase 2(重跑)
"这两份 PRD 有冲突,帮我分析"两份 PRDPhase 1 逐份解析 + 交叉对比矛盾Phase 1 × 2 + 矛盾报告
"需求变了,之前的设计要改"已有 Spec + 架构标注变更影响范围,增量更新 Spec 和架构Phase 1(增量)→ Phase 2(增量)
Phase 2 扫描发现现有架构有严重问题Brownfield 项目暂停 Phase 2,报告架构风险输出架构风险报告,等待用户决策

错误处理与降级

遇到异常时采取降级而非中断:

异常场景处理策略
无法读取项目代码跳过代码扫描,仅基于已有产物做部分审计,标注"代码审计未执行"
WebFetch 抓取失败告知用户,请求手动粘贴内容或导出文件
Spec 质量不确定标注置信度低的条目,建议用户人工审核关键功能点
上下文接近窗口极限建议将已完成的产物保存为文件,在新对话中通过文件引用继续
输入文档格式异常告知支持的格式,请求提供可解析的版本

降级原则

  • 即使降级也要输出部分结果,而非直接失败
  • 降级输出必须标注哪些环节被跳过或简化,以及原因
  • 始终提供可操作的下一步建议

上下文管理

  1. 按需加载:只加载目标 Phase 对应的 reference 文件,不预加载下游 Phase
  2. 产物传递:上游输出直接作为下游输入,不重复生成或复述
  3. 大文档分段:PRD 过长时按章节/模块分段处理,独立提取后合并
  4. 输出精简:只包含结构化结果,不包含分析过程和备选方案论述
  5. 产物外部化:每个 Phase 输出末尾建议用户保存为文件(遵循「产物保存规则」,不主动创建)
  6. 溢出降级:优先保证目标 Phase 的必需输入和结构化输出完整,可裁剪分析过程

输出规范

所有 Phase 遵循以下规则:

  • 输出为纯 Markdown,不依赖特定渲染器
  • 输出语言默认中文,可通过自然语言指令切换英文(如"用英文输出")
  • 只输出目标 Phase 的结果(中间 Phase 的产物不单独展示,除非用户要求)
  • 产物末尾附"建议保存为文件"的提示(仅提示,不主动写入)
  • 上游 Phase 在本次调用中重新执行过时,标注"⚠️ 下游产物可能已过期"

产物保存规则

产物默认输出到对话上下文,不主动创建文件。文件保存遵循以下规则:

触发条件

仅在以下情况才创建或写入文件:

  • 用户明确要求"保存到文件"、"写入文件"、"导出"等
  • 上下文接近窗口极限时,提示用户是否需要保存(仍需用户确认后才执行)

禁止在无用户授权的情况下自行创建文件。

保存路径

  • 首次保存:询问用户希望保存到哪个目录,并给出建议路径(如 prd/specs/
  • 后续保存:复用同项目中已确认的目录,无需重复询问
  • 如用户未指定,使用以下默认建议路径:
Phase默认建议路径文件命名建议
Phase 1prd/specs/SPEC-{文档编号}_{功能名}.md
Phase 2prd/architecture/ARCH-{文档编号}_{功能名}.md
Phase 3prd/tasks/TASK-{文档编号}_{功能名}.md
Phase 4prd/implementation/IMPL-{文档编号}_{功能名}.md
Phase 5prd/audit/AUDIT-{文档编号}_{功能名}.md

保存后

  • 告知用户文件已保存的完整路径
  • 询问用户是否继续执行下一步(如架构设计、任务拆解等),用户确认后 Agent 自动执行

Phase Reference

执行对应 Phase 时,加载以下 reference 文件获取详细指令:

PhaseReference 文件职责
Phase 1references/phase-1-prd-parser.md原始文档 → 结构化 Spec + 追问清单
Phase 2references/phase-2-arch-designer.md结构化 Spec → 架构设计方案
Phase 3references/phase-3-task-planner.md架构设计 → 可执行任务清单
Phase 4references/phase-4-implementation.md任务清单 → 实现指导规范
Phase 5references/phase-5-trace.md全链路产物 → 完工审计报告

评论

加载中…