taiyi-plan

Files (1)

• SKILL.md

SKILL.md (first lines)

# taiyi-plan

## 目的

作为 TaiyiForge 的规划阶段，在 `/taiyi:new` 之前运行。把一份大的需求文档（README、PRD、技术方案）拆成一组互不阻塞的 change，每个 change 带推荐 profile、依赖关系和优先级，然后批量创建。

## 何时使用

`/taiyi:plan` 跑在九阶段之前，是整个流程的第一个入口：

```
/taiyi:plan（规划阶段）
       │
       ▼ 产出 PLAN.md + 批量 /taiyi:new
       │
  ┌────┴────┬────┬────┐
  ▼         ▼    ▼    ▼
change  change change change（各自走九阶段）
```

| 信号 | 建议 |
|------|------|
| 新项目拿到 README / PRD，不知道从哪开始 | 必跑 |
| 大功能涉及多个模块，想做并行开发 | 必跑 |
| 需求文档包含 5 个以上独立功能点 | 必跑 |
| 只有一个 typo 或单文件改动 | 跳过 |

## 何时不用

- 单文件改动，直接 `/taiyi:new` 走 micro
- 已经有了完整的 slug 清单
- 纯技术改动（升级依赖、修 lint）直接 micro/nano

## 输入

`/taiyi:plan` 可以接文件路径，支持任何能读出文字的内容：

| 输入 | 用法 | 提取方式 | 工具 |
|------|------|---------|------|
| 本地 Markdown | `/taiyi:plan docs/PRD.md` | `Read` 直接读取 | 内置 |
| 纯文本 | `/taiyi:plan requirements.txt` | `Read` 直接读取 | 内置 |
| PDF | `/taiyi:plan docs/spec.pdf` | `look_at` 或 `pdftotext` 提取文本 | `look_at` / `pdftotext` |
| Word 文档 | `/taiyi:plan docs/设计文档.docx` | `python-docx` 或 `pandoc` 转文本 | `python-docx` / `pandoc` |
| 网页 / 在线文档 | `/taiyi:plan https://wiki.example.com/prd` | `webfetch` 抓取后解析 | `webfetch` |
| 不指定文件 | `/taiyi:plan` | 自动找 README.md，找不到则询问 | `glob **/README.md` |

**执行方式**：
1. 读取指定文件 → 提取全部文字内容
2. 如果是非文本格式（PDF/docx），先用对应工具提取文本（PDF 优先 `look_at`，docx 回退到 `python-docx`）
3. 将提取的文字作为需求输入，进入正常的拆解流程

## 自动模式（`--auto`）

`/taiyi:plan README.md --auto` 与普通模式的核心区别：

| 维度 | 普通模式 | `--auto` 模式 |
|------|---------|---------------|
| 用户确认 | **必须**等用户确认后再创建 | **跳过**用户确认，拆完即创建 |
| 拆解计划 | 写到 `.taiyi/PLAN.md` + 聊天审阅 | 直接写到 `.taiyi/PLAN.md`，不展开聊 |
| Profile 选择 | 按决策树问用户 | 按决策树**自动判断**（拿不准时默认 full） |
| 创建方式 | 用户选"自动创建"才批量 `/taiyi:new` | 立即批量 `/taiyi:new` |
| 交互节奏 | 慢：展示 → 确认 → 创建 | 快：一行命令跑完 |

**执行差异**：

1. 依然需要走完"读取需求 → 识别模块 → 冲突检测 → 拆解计划"全部步骤
2. 拆解计划写完后，**不等用户确认**，直接进入批量创建（Step 6）
3. 创建完成后输出汇总，用户直接进入 `/taiyi:status` 看进度
4. `--auto` 模式下如果遇到模棱两可的选择（如不确定用 full 还是 api），**往大选**（full > api > lite），宁浪费一点流程也不能漏掉关键步骤

> `--auto` 不改变拆解逻辑，只改变确认节奏。用户信任 AI 的拆解判断时可省一次来回。

## 输出

一份结构化拆解计划，写到 `.taiyi/PLAN.md` 或直接在聊天里审阅。

格式：
```markdown
# Decompose: <项目名>

> 来源：<README/PRD 路径> · 日期 · 拆解人

## 拆解清单

| # | Slug | 范围 | Profile | 依赖 (depends_on) | 共享资源 | 可并行 | 优先级 |
|---|------|------|---------|--------------------|----------|--------|--------|
| 1 | user-auth | 注册/登录/权限 | full | — | auth 框架 | ✅ 与 product-crud | P0 |
| 2 | product-crud | 商品增删改查 | full | — | auth 框架 | ✅ 与 user-auth | P0 |
| 3 | order-flow | 下单/支付/状态机 | full | user-auth | user-auth 的 session API | ❌ 等 1,2 | P1 |

## 依赖关系与并行度

```
真并行组：user-auth ⚡ product-crud（不共享业务文件）
     │              │
     └──────┬───────┘
            ▼
       order-flow（依赖 session API，等 user-auth 到 dev）
```

> 并行标记：⚡ = 不共享文件可同时推进，❌ = 有共享资源需排队

## 整体进度追踪

此 PLAN.md 创建后，每次完成一个 change 的归档，手动更新进度行：

```
⏳ 进度: [░░░░░░░░░░] 0/3 change 完成
         user-auth (change) · product-crud (change) · order-flow (pending)
```

格式惯例：
- `pending` — 未创建
- `(当前阶段名)` — 推进中
- `✅` — 已完成归档

## 执行建议

| 规则 | 说明 |

From Dong90/oh-my-taiyiforge, MIT.

More from Dong90/oh-my-taiyiforge