Muniu Liumia

SKILL.md

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

# 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-parser | PRD/需求文档（文本） | 无法补齐，主动询问用户提供 |
| Phase 2：arch-designer | 结构化 Spec | 检查上下文有无原始 PRD → 有则先跑 Phase 1 |
| Phase 3：task-planner | 架构设计方案 | 检查上下文有无 Spec → 有则先跑 Phase 2 |
| Phase 4：implementation | 任务清单 + 架构设计 | 检查上下文有无任务清单 → 有则先跑 Phase 3 → 无则继续回溯 |
| Phase 5：trace | Spec + 架构 + 任务清单 + 实现指导 + 代码 | 逐层回溯补齐全部上游产物 |

### 第三步：执行并输出

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

## Agent 停止规则

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

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

## 执行示例

### 标准路径

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

### 范围评估场景

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

### Brownfield / 已有项目场景

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

### 异常与回退场景

| 用户说 | 上下文状态 | 决策 | 实际执行 |
|--------|-----------|------|----------|
| "Spec 里漏了一个功能，补上" | Phase 2 已执行 | 回退到 Phase 1 补充，再重新执行 Phase 2 | Phase 1（增量更新）→ Phase 2（重跑） |
| "这两份 PRD 有冲突，帮我分析" | 两份 PRD | Phase 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 1 | `prd/specs/` | `SPEC-{文档编号}_{功能名}.md` |
| Phase 2 | `prd/architecture/` | `ARCH-{文档编号}_{功能名}.md` |
| Phase 3 | `prd/tasks/` | `TASK-{文档编号}_{功能名}.md` |
| Phase 4 | `prd/implementation/` | `IMPL-{文档编号}_{功能名}.md` |
| Phase 5 | `prd/audit/` | `AUDIT-{文档编号}_{功能名}.md` |

### 保存后

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

## Phase Reference

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

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