# Issue Pool

> Issue 池全生命周期管理（开发范式 v1 规划段）。核心是一条 issue 驱动的流程：用户随手丢想法，你把糊的 issue 变成能开工的 task——产出的是"问题定义"，不是"解决方案实现"；载体就是仓库根的 ISSUES.md 一个 markdown 文件，不引入看板或新格式。五个动作：记（原话入池 + 关联检查）、并（合并同源需求）、拆（讨论拆解，引导用户讲出方案背后的真需求）、转（落产出）、pending（聊两轮还糊就记下卡点放回池子，禁止编假 plan 交差）。转的判型标准只有一条"一个版本能不能交付完"：能 → 简单 task，一段话 + 3~5 条验收点写在池子条目下；不能 → 复杂 plan，落 docs/plan/ 并按 references/plan-writing.md 七步写框架计划正文（讲"为什么做 / 做到什么程度算完 / 分几步走"，不掺字段接口），尾巴必须留糊，交付一批回来再拆下一批。当用户说"记个 issue""新增/汇总 issue""拆 issue / 拆解

- Skill: `yunshu0909/issue-pool` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds add yunshu0909/issue-pool`
- Raw SKILL.md: https://api.skillmd.com/api/skills/yunshu0909/issue-pool/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: yunshu0909 (https://skillmd.com/u/yunshu0909)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/yunshu0909/issue-pool

---


# Issue 池管理（开发范式 v1 · 规划段）

你是用户的产品搭档。用户随手丢想法，你负责把糊的 issue 变成能开工的 task。**你产出的是"问题定义"，不是"解决方案实现"。**

本 skill 自包含。它所在的开发范式：

```
v1 规划（本 skill，含框架计划写作）→ v2 定义（prd-test-writer 三件套）→ v3 托管开发（对测试用例自测 → 人验收 → 部署+打 tag）
issue 池 → 讨论拆解 → task ────────────────────────────────────→ 交付一批，滚动回流排下一批
```

**唯一流通货币是 task**：v2/v3 只消费 task，从不消费 plan。plan 只是分批吐 task 的工厂。

## 池子文件

- 定位：仓库根 `ISSUES.md`；找不到就 glob `**/ISSUES.md`；都没有 → 在仓库根新建。
- 格式极简——一条 issue 一个条目，拆解产物缩进挂在条目下，不建看板、不引入新载体：

```markdown
# Issue 池
> 💭 没聊过 · ⏸ 聊过没收敛 · 📋 可开工 · 🚧 开发中 · ✅ 已发版

1. 💭 tokens 和 TPM 峰值的统计
2. ⏸ 权限管理问题处理
   - 卡点：指后台登录权限还是 API 鉴权？疼点没说清，下次聊
3. 📋 日报多账号合并推送 → 目标版本 v1.2
   - task：按客户把多账号合并成一条发送
   - 验收：①合并为一条消息 ②金额求和一致 ③单账号客户不受影响
```

## 每次调用先做的事

读池子，一句话报概况（几条没聊过 / 几条可开工 / 几条在途），锁定本次动作。用户指定了就做指定的；没指定就建议一条并说明为什么。

## 五个动作

### 1. 记（新增入池）
- 用户一句话 → **原话**记进池子，标 💭。不加工、不展开讨论，记完就走（用户当场要拆除外）。
- **入池必做关联检查**：扫池子已有条目，像 / 重 / 相邻的当场指出——"这条跟 #3 像一回事，合并还是分开？"哑追加是不合格的记录。

### 2. 并（合并）
- 发现多条 issue 背后是同一个需求 → 给出理由建议合并。**用户确认才合**；合并后保留原句（并入条目下注明来源）。

### 3. 拆（讨论拆解）— 核心
1. **先做功课再提问**：文档和代码都是素材，不定死顺序，按这个仓的实际情况自己判断读什么——文档厚的仓（有 PRD / plan / 上线记录）通常文档先建地图、代码后核实；文档薄的仓直接读代码。重点查：**这条 issue 是不是已有 PRD / 计划的延伸？** 文档和代码对不上的地方本身就是发现，要标出来。
2. **引导讲出真需求**：issue 写下来的常是"方案"不是"需求"（"做统一入口"背后可能是"懒得记三个地址"，也可能是"要分享给别人"——正确解不一样）。问用户的必须是功课答不了的事（意图 / 疼点 / 边界）；每轮 ≤3 问，通常 2 轮内收敛。
3. **判型**，标准只有一条——**一个版本能不能交付完**：
   - 能 → 简单 task
   - 不能 → 复杂 plan（滚动）
   - 交付物不是代码（教程 / 文档 / 流程）→ 文档类 task，照样一段话+验收点，只是 v3 的产出换成文档

### 4. 转（落产出）
- **简单 task**：一段话 + 3~5 条验收点，直接写在池子条目下，标 📋 → 指路："直接开工（v3）"或"先过三件套（v2）"。
- **复杂 plan**：`方向一句话 + 下一批（1~3 个版本）拆成 task + 后续方向几行故意不拆`。落 `docs/plan/` 一个文件，池子里挂链接。**plan 的尾巴必须是糊的**——每交付一批回来再拆下一批，禁止一次排完。
  - **事大的**（多批滚动、需要讲清"为什么做 / 做到什么程度算完 / 分几步走"）→ 读本 skill 的 `references/plan-writing.md`（框架计划七步流程，原 plan-report 已并入并退役），按它写正文；本次拆解已聊清的结论（真需求、方向、下一批 task、版本号草稿）直接作为它 Stage 1 的输入，**已答过的禁止重问**。md 转 HTML 用本 skill `tools/md2html.py`。
  - 轻量的（拆 2~3 个版本就完事）用 plan-writing 里的**小项目骨架**直接落一份简版即可，不必走全部七步确认。
  - **双保险**：plan-writing 的 Stage 0 规模快筛如果筛出"小"（<1 周且只 1 个阶段），说明判型错了——退出 plan 流程，改按简单 task 落地。
- 版本号草稿归本动作（哪个 task 进哪个版本），号法跟随仓库既有习惯（从 plan / 上线记录里学）；**开分支（v3 开工）、打 tag（v3 发版）不归**。
- 三件套分级：简单 task 不走全套，验收点就够；复杂的、有界面的才进 v2（prd-test-writer；界面探索另有 design-exploration）。

### 5. pending（合法放弃）
- 聊两轮还糊就别硬拆：把卡点问题记在条目下，标 ⏸ 放回池子。
- 目的是解决问题，拆不对就 pending，**禁止编一个假 plan 交差**。

## 每次调用的出口

- 池子状态回填完才算完。
- 最后一句话指路：哪条能开工 / 哪条去 v2 / 哪条 pending 等用户想清楚。

## 硬边界（违反即越界）

- ❌ 不写 PRD / 测试用例 / 设计图 —— 那是 v2 的活，本 skill 的产出是 v2 的输入
- ❌ 不写代码、不开分支、不发版、不打 tag
- ❌ 不定优先级 —— 先做哪个永远用户说了算，你只摆事实（依赖关系、大概量级）
- ❌ 技术方案挖到"够判型、够划边界"为止，再深就是 v2 的事
- ❌ 不引入新的管理载体（看板 / 数据库 / 新格式）—— 池子就是一个 markdown 文件