メニュー
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/yunshu0909/yunshu_skillshub --skill backlog-managerコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
带用户精读一篇文章/文档并真正学透（不是出摘要）。五步：抽干货 → 切讲次 → 每讲跑「学-考-讲」循环 → 对号入座 → 实操+测验+讲错题+蒸馏。每讲产出 HTML 课件 + 笔记落盘；讲完必考一次，用户复述后必须挑不精确处拧紧；抽象概念上可交互演示（能点能跑）；全程用用户自己的业务场景当案例；学完出多题型自动判分测验卷，最后把收获蒸馏回用户的工具。核心触发条件是用户要的是"学会"而不是"要一份结果"，例如"我们一起学这篇文章/这个链接"、"带我学"、"精读"、"我想学会 X"、"这篇我看不懂你给我讲讲"。有具体材料（链接、本地文件、PDF，或用户自己的 skill/文档/代码）时直接开跑；只有学习意图而没材料时仍走本 skill，但开工第一件事是和用户一起把材料定下来，禁止凭记忆开讲。不适用于：只要一份总结/摘要/教程长文，用户读完就完、不需要答题（用 readable-output）、只是搜集资料做调研（使用可用的网页/平台取材工具）、帮我写 PRD/测试用例（用 prd-test-writer）、以及用户其实是想让你直接把活干了（那就直接做）。
让 Codex 与 Claude Code 通过本机 CLI 组成“主执行者 + 独立审查者”的对称协作闭环。用于用户要求两个模型一起完成、交叉校核、独立审查、修到 ACK，或任务涉及产品需求收敛、复杂方案、跨模块开发、迁移、安全、重要重构和高质量交付时；无论从 Codex 还是 Claude Code 启动，都由当前模型主持，并完整调用另一方完成需求挑战、方案门禁、实现冷审和最终验收。
界面设计探索（开发范式 v1 · 仅限有 UI 的模块）。触发前两个硬条件必须同时成立：①这个东西有用户能看见的界面 ②界面尚不存在。通过"需求收敛 → 技术调研 → ASCII 批量出 5-8 个方案 → HTML 设计稿 → 全状态覆盖 → 需求总结"，产出 3 个交付文件：需求总结.md + {模块}-设计稿.html + {模块}-全状态设计参考.html，作为 PRD 阶段的输入。不适用于：无界面的流程/架构/数据结构/接口/方案设计——"设计"二字不等于本 skill（用 issue-pool 讨论拆解）、界面已经在代码里跑着要改样式（用 ui-design）、照着现成设计图或截图复刻（用 design-replica）、写 PRD 时给单个故事配线框图（用 prd-test-writer，它自带 ASCII 线框能力）、还没决定要不要做的模糊想法（先用 issue-pool 入池）、纯发散不收敛的终局愿景（用 vision-exploration）。
SOC 職業分類に基づく
SKILL.md を表示中
| name | backlog-manager |
| description | 需求池管理。用户随时抛出想法/痛点，AI 负责追问、整理、合并、归档到需求池文件。用户准备开新版本时，协助从池中筛选。痛点驱动，不做提前排期。 |
用户随时会抛出产品想法、使用痛点、功能需求。AI 负责将这些零散输入整理成结构化的需求池， 并在用户准备启动新版本时协助筛选。需求池是一个持续维护的文件，不是一次性产出。
位置：docs/需求池.md
如果文件已存在，在现有内容上更新。如果不存在，按以下模板创建。
# 需求池
> 随手记，随时加，隔段时间过一遍。
>
> 状态说明：
> - **可以做了** — 痛点清晰，知道要做成什么样，随时能进设计/PRD
> - **需要想想** — 方向有了，细节没展开，需要调研或讨论
> - **先放着** — 记着就行，现在不花精力想
> - **已完成** — 做完了，标版本号归档
---
## 总览
| # | 需求 | 状态 | 依赖 | 备注 |
|---|------|------|------|------|
| 1 | xxx | 可以做了 | 无 | xxx |
---
## 可以做了
### 需求名称
- 痛点：xxx
- 方案：xxx
- 备注：xxx
---
## 需要想想
### 需求名称
- 方向：xxx
- 依赖：xxx
- 待展开：xxx
---
## 先放着
### 需求名称
- 想法：xxx
- 备注：xxx
---
## 已完成
### 需求名称（V0.xx）
- 完成时间：yyyy-mm-dd
- 简述：xxx
每个条目根据所在分区使用不同字段：
| 分区 | 必填字段 | 可选字段 |
|---|---|---|
| 可以做了 | 痛点、方案 | 备注 |
| 需要想想 | 方向 | 依赖、待展开 |
| 先放着 | 想法 | 依赖、备注 |
| 已完成 | 完成时间、简述 | — |
总览表每个条目必须有：编号、需求名称、状态、依赖、备注。
用户说了一个想法或痛点后，主动追问：
整理成一句话描述，向用户确认："我理解的是 xxx，对吗？"
禁止：
禁止：
确认后更新 docs/需求池.md：
格式要求：
当用户说"整理一下需求池"或"看看需求池"时：
禁止：
当用户说"下一个版本做什么"或"挑一个来做"时：
| 标准 | 问题 |
|---|---|
| 频率 | 你多久被这个问题卡一次？ |
| 可绕过性 | 不做的话手动能搞定吗？多麻烦？ |
| ROI | 做完之后日常能省多少事？ |
禁止：
当用户说"xxx 做完了"或"标记完成"时：
| 时机 | 问什么 |
|---|---|
| 第 1 步 | 痛点、频率、现在怎么绕 |
| 第 2 步 | 合并是否合理、状态归类是否正确 |
| 第 4 步 | 每条变更建议是否同意 |
| 第 5 步 | 从候选里选哪个 |
| 事项 | 直接做 |
|---|---|
| 文件格式 | 按模板写，不用问 |
| 编号分配 | 自动递增 |
| 总览表同步 | 改了详情就同步总览表 |
| 没变化的条目 | 整理时直接跳过 |