| name | project-backlog |
| description | 项目待办管理器（两种模式）。【收集模式】接收任意混合输入 → 解析追加到「项目待办.md」文档，不立即执行；【处理模式】读取文档 → 前置决策收集 → 按优先级逐条路由执行 → 更新状态 → 批次报告。触发词：【收集】「有几个问题先记到待办」「加到项目待办」「先存到待办文档」「记录这些待办」；【处理】「处理项目待办」「按待办文档逐条修复」「开始处理待办文档」。⚠️ 触发词必须含「待办」关键词才激活，避免与 issue-tracker / bug-fix-loop 混淆。 |
项目待办管理器（project-backlog）
核心原则：文档即状态，不依赖 AI 记忆。
任何输入先存文档；执行状态写在文档里；进程中断后可从文档恢复，不丢失。
认知根
认知根：_内部总控/认知结构/L1_系统性文档/系统架构思维维度/Skill体系设计原则_v1.0.md
关联：「文档即状态」是本 Skill 的核心执行范式。
待办文档规范（项目待办.md）
位置：项目群/[项目名]/产品经理/项目待办.md
（优先用 project-config.md 中的 PATH_待办 字段覆盖）
标准格式：
# 项目待办
> 所有类型的输入先到这里。说「处理项目待办」可触发自动处理流程。
| ID | 类型 | 内容摘要 | 来源日期 | 优先级 | 状态 |
|----|------|---------|---------|--------|------|
| B-01 | Bug | [描述] | YYYY-MM-DD | P0/P1/P2 | 🔲 |
| F-01 | Feature | [描述] | YYYY-MM-DD | — | 🔲 |
| U-01 | UX | [描述] | YYYY-MM-DD | P1 | 🔲 |
| P-01 | 原则 | [描述] | YYYY-MM-DD | — | 🔲 |
| R-01 | 规范偏差 | [描述] | YYYY-MM-DD | — | 🔲 |
| D-01 | 设计建议 | [描述] | YYYY-MM-DD | — | 🔲 |
状态标记：🔲 待处理 / 🔄 处理中 / ✅ 已完成 / ❌ 执行失败 / ⏸️ 搁置（待决策）/ 📬 已移交
ID 前缀：B=Bug / F=Feature / U=UX / P=原则 / R=规范偏差 / D=设计建议 + 两位流水号
架构层标签（B-xx Bug 可选，AI 平台项目推荐填写）：
L0=部署模型 / L1=状态管理 / L2=并发模型 / L3=LLM调用 / L4=数据隔离 / L5=Agent框架 / L6=可观测 / L7=安全 / L8=性能 / L9=扩展 / FE=前端
示例：B-01 | Bug | [L1] 更新认知显示构建中 | ...
知识导航表（执行前读取）
| 层级 | 文档 | 读取目的 |
|---|
| D0 | .cursor/project-config.md（若存在） | 获取 PATH_待办 和 PATH_技术追踪台 |
| ① | _内部总控/元项目导航.md | project-config 不存在时确认当前活跃项目 |
可用 Skill 速查表（P-2 生成激活命令时的唯一参考）
⚠️ 生成激活命令时必须参考此表，不得凭记忆猜测触发词
| 待办类型 | 触发词（【X】格式） | 对应 Skill | 该 Skill 处理什么 | 前置条件 |
|---|
| P-xx 原则类 | 【立原则】：[原则描述] | engineering-principle-recorder | 新工程/执行原则录入到 Rule/Role Skill 执行层，并审计现有违规 | 无 |
| B-xx P0/P1 Bug（需立即修复） | 【修复循环】 | bug-fix-loop-coordinator | 读技术追踪台，P0→P1 循环 TDD 修复，直至清零。⚠️ 需要 Bug 已在追踪台中（P-2-1 写入追踪台后再激活） | 技术追踪台已有条目 |
| B-xx P2 Bug（仅记录） | 【记录问题】[Bug描述] | issue-tracker | 拆分并记录到产品/技术追踪台，不立即修复 | 无 |
| F-xx Feature（新功能需求） | 【协调者】：[需求描述 + 用户决策] | role-产品开发协调者 | 判断任务类型并编排完整产品开发流水线（PM→关卡A→架构师→关卡B→开发→关卡C→DevOps） | 无 |
| U-xx UX 问题（体验问题） | 【协调者】：[UX问题 + 用户决策] | role-产品开发协调者 | 同上，协调者判断走产品修复还是前端/UI修复 | 无 |
| R-xx 规范偏差（已有规范被违反） | 【规范修复】：[规范偏差描述] | project-convention-resolver | 接收–分类–路由–验证；已知规范的偏差修复（与「立原则」的区别：这里处理已有规范的违反，不是立新规范） | 无 |
| D-xx 设计建议（纳入迭代） | 【协调者】：评估设计建议：[描述] | role-产品开发协调者 | 产品/技术层面评估并纳入开发计划 | 无 |
| D-xx 设计建议（仅存档） | 无需激活 Skill，project-backlog 直接写入 | — | 直接追加到技术架构.md「设计建议存档」节 | 技术架构.md 已存在 |
B-xx P0/P1 Bug 的两步流程说明：
P-2-1 生成激活命令时，Bug 条目额外执行两步（在生成【修复循环】命令之前）：
Step A: Read [PATH_技术追踪台]（默认：技术架构师/技术问题追踪台.md）
Step B: StrReplace 追加 issue 条目：
| [日期] | [Bug描述] | P0/P1 | [复现步骤/文件] | 🔲 待修复 |
（若追踪台不存在则先创建）
然后生成激活命令：【修复循环】
激活后：判断操作模式
⚠️ 首先判断触发的是哪种模式
收集模式信号：
消息含「待办」+「记录/存/先放着」等延迟动词
「加到项目待办」「先存到待办文档」「记录这些待办」
含编号列表 + 延迟信号词 → 收集模式
处理模式信号：
「处理项目待办」「按待办文档逐条」「处理待办文档里的」
→ 处理模式
⚠️ 必须含「待办」关键词才触发本 Skill（防止与 issue-tracker / bug-fix-loop 冲突）
⚠️ 两种模式同时出现（「记到待办然后马上处理」）→ 先完整执行收集（C-0~C-3），再询问是否立即处理
⚠️ 不确定时 → 问用户：「您是要先记录到待办文档，还是立即开始处理？」
收集模式（COLLECT）
Step C-0 【确认待办文档路径】
① Read: .cursor/project-config.md（若存在）→ 读 PATH_待办
② 若无 config → Read: _内部总控/元项目导航.md → 识别当前项目
③ 若仍不确定 → 问用户：「当前操作哪个项目？」
⚠️ 禁止用 IDE 打开的文件推断项目（ide-context-guard 规则）
默认路径：项目群/[项目名]/产品经理/项目待办.md
若文件不存在 → 创建文件，写入标准表头（见上方规范）
Step C-1 【解析输入为结构化条目】
逐条扫描用户消息中的独立意图：
对每个独立意图提炼：
- 摘要：一句话（≤40字，说清「什么东西 + 什么问题」）
- 类型（参考可用Skill速查表）：
Bug = 有明确错误行为（系统报错/功能失效/数据错误）
Feature = 新功能需求
UX = 体验/交互问题（不是 Bug，但影响使用感受）
原则 = 「以后都要」「这是原则」「系统应该怎样运行」
规范偏差= 「这不符合规范」「这违反了规范」（已有规范被违反）
设计建议= 架构思路/技术方向/产品建议（非强制需求）
- 优先级（仅 Bug 类）：P0=阻塞 / P1=影响核心流 / P2=次要
⚠️ 若解析出 0 条独立意图 → 不执行 C-2，输出：
「未识别到独立条目，请分条列出（如用编号或换行分隔）」→ 等待用户重新输入
宁多勿少：有疑问时保留条目；重复的意图合并为一条
Step C-2 【追加到待办文档】
Read: [PATH_待办]（先读，获取当前最大 ID 编号，确认表格完整）
⚠️ 若表格格式异常（缺表头/非标准列）→ 告知用户并先修复表头，不追加
StrReplace 在表格末尾追加新行（每条一行，ID 继续编号）
Step C-3 【确认输出】
输出格式：
「✅ 已记录 N 条待办：
[B-01/P1] 更新认知时显示「正在构建中」
[P-01] LLM 调用不截断上下文（原则）
[B-02/P0] 对话历史消失
[R-01] 日志截断违反不截断原则（规范偏差）
[F-01] 实时显示AI思考过程（新功能）
[D-01] 状态管理按生命周期分层（设计建议）
...
文档路径：[PATH_待办]
说「处理项目待办」可触发自动处理流程。」
处理模式（PROCESS）
Step P-0 【读取待办文档 + 构建执行队列】
Read: [PATH_待办]（全文读取，不截断；若文件不存在 → 告知「待办文档不存在」→ 停止）
解析所有 🔲 条目（按 | 分隔的表格行）：
⚠️ 若解析失败（格式混乱）→ 输出原文片段，告知用户修复格式或重新用收集模式录入
⚠️ 若无 🔲 条目 → 告知「当前没有待处理条目」→ 停止
按以下规则排序（数字小的先执行）：
第一轴：类型（最高优先）
1. P-xx 原则类 — 影响所有后续修复方向，必须最先处理
2. B-xx Bug 类 — 技术问题，按第二轴（架构层）细化排序
3. U-xx UX / F-xx Feature — 功能/体验问题，按架构层或产品决策排序
4. D-xx 设计建议 — 最低优先，通常只存档
第二轴（仅 B-xx Bug 类内部）：架构层（AI 平台项目）
若条目 ID 含架构层标签（如 [L1]）：
L1（状态管理）> L2（并发）> L3（LLM调用）> L4（数据隔离）> L5（Agent框架）> FE（前端）
若无层标签：按 P0 > P1 > P2 排序（传统方式，兜底）
第三轴（同层内）：AI 确定/不确定
AI 确定（唯一明确修法）先执行
AI 不确定（需设计决策）在 P-1 前置决策中收集
同优先级按 ID 编号顺序
Step P-1 【前置决策收集（Feature/UX/设计建议类）】
扫描队列，找出需要用户判断的项：
- F-xx Feature 类：有多种实现方案 → 询问方案选择
- U-xx UX 类：设计方向不明 → 询问期望体验
- D-xx 设计建议 → 询问「纳入当前迭代 / 下个迭代 / 仅存档」
⚠️ 一次性集中提问，不分散：
「处理前需确认 N 个决策点：
[F-01] 实时显示AI思考过程
→ A: SSE 推送节点状态 B: 前端轮询
[D-01] 状态管理分层重构
→ 纳入当前迭代 / 仅存档
请依次回答（如「A, 存档」）」
用户回答 → 记录决策到对话上下文 → 进入 P-2
某条用户说「跳过」或不回答 → 该条标记 ⏸️ 搁置，激活队列中排除
若全部为 A 类（原则/Bug，无需决策）→ 跳过 P-1 直接进 P-2
Step P-2 【生成激活队列并输出（不自行执行，交由专业 Skill）】
⚠️ 核心设计原则：project-backlog 只负责「收集」和「排队」，不执行具体任务。
每条待办必须由对应的专业 Skill 正式激活后执行，才能保证：
- D0 认知根读取（产品定义/技术架构等前置文档）
- 完整的流程门控（关卡/测试/文档同步）
- 正确的角色视角（后端开发 ≠ 测试工程师 ≠ 产品经理）
⚠️ project-backlog 自行执行 = 绕过所有规范 = 等于没有规范
Step P-2-1 为每条 🔲 条目生成对应的激活命令
（⚠️ 必须参照上方「可用 Skill 速查表」，不得凭记忆）：
[P-xx 原则类]
→ 激活命令：「【立原则】：[原则精确描述]」
[B-xx P0/P1 Bug]（⚠️ 两步，先写追踪台再生成命令）
Step A: Read [PATH_技术追踪台]（不存在则 Write 创建）
Step B: StrReplace 追加 issue 行到追踪台
→ 激活命令：「【修复循环】」
（bug-fix-loop-coordinator 会读追踪台，追踪台必须先有条目）
[B-xx P2 Bug]
→ 激活命令：「【记录问题】：[Bug描述]」
（issue-tracker 仅写入追踪台，不触发修复）
[F-xx Feature]
→ 激活命令：「【协调者】：[需求描述 + P-1中用户决策]」
（role-产品开发协调者 编排完整产品开发流水线）
[U-xx UX 问题]
→ 激活命令：「【协调者】：[UX问题描述 + 用户决策]」
（同上，协调者判断走产品修复还是前端/UI修复路线）
[R-xx 规范偏差]
→ 激活命令：「【规范修复】：[规范偏差描述]」
（project-convention-resolver 分类路由验证已有规范的违反）
[D-xx 设计建议（用户决策：纳入迭代）]
→ 激活命令：「【协调者】：评估设计建议：[描述]」
[D-xx 设计建议（用户决策：仅存档）]
→ 无需激活其他 Skill
→ 直接：StrReplace 追加到技术架构.md「设计建议存档」节
→ 状态直接改为 ✅（已存档）
Step P-2-2 输出执行计划（仅展示，立即进入 P-2-3 执行）：
「📋 开始按优先级逐条执行（N 条）：
1. [P-01] 原则 → 激活 engineering-principle-recorder
2. [B-01/P0, B-02/P1] Bug → 写入追踪台 → 激活 bug-fix-loop-coordinator
3. [F-01] Feature → 激活 role-产品开发协调者
...
⏸️ [D-01] 搁置（等待您决策）
──────────────────」
Step P-2-3 逐条完整执行（无需用户确认，自动推进）：
⚠️ 「完整执行」的定义（与 v1.0 的「按其步骤执行」本质不同）：
Read [目标 SKILL.md]
→ 切换为对应角色视角
→ 执行「激活后立即执行」序列中的 EVERY step，包括：
· D0 认知根读取（所有 Read 操作，不跳过）
· 知识导航表中列出的所有前置文档读取
· 每个 Step 的所有工具调用（Write/StrReplace/Shell/浏览器等）
→ 不简化、不跳步
→ 与用户直接说「【X】：[内容]」触发的效果完全等同
对每条 🔲 条目，按排序顺序：
── P-xx 原则类 ──
StrReplace 状态 → 🔄
Read: .cursor/skills/engineering-principle-recorder/SKILL.md
完整执行其所有 Step（含 Step 0 读元项目导航、Step 1 分类、Step 2-B/C/D 写入、Step 3 报告）
完成 → StrReplace 状态 → ✅
── B-xx P0/P1 Bug ──
StrReplace 状态 → 🔄
Read [PATH_技术追踪台]（不存在则 Write 创建）
StrReplace 追加 issue 条目到追踪台
Read: .cursor/skills/bug-fix-loop-coordinator/SKILL.md
完整执行其所有 Step（含 Step 0 读追踪台、Step 1.5 读产品定义、循环修复等）
⚠️ Bug 修复完成后必须执行关卡C（不等用户，自动推进）：
Read: .cursor/skills/role-测试工程师/SKILL.md
完整执行其所有 Step（含 D0、Step 0.4 基线建立、五类测试、Step 6.4 覆盖门禁、Step 6.6 写凭证）
关卡C通过 → StrReplace 状态 → ✅
关卡C发现新 Bug → 写入追踪台 → 继续修复循环（不标 ✅，标 🔄 继续中）
── B-xx P2 Bug ──
StrReplace 状态 → 🔄
Read: .cursor/skills/issue-tracker/SKILL.md
完整执行其所有 Step（澄清现象、分类、写入追踪台）
完成 → StrReplace 状态 → ✅（已记录）
── F-xx Feature / U-xx UX ──
StrReplace 状态 → 🔄
Read: .cursor/skills/role-产品开发协调者/SKILL.md
完整执行其所有 Step（含任务类型判断、briefing生成、编排后续角色）
完成（协调者完成其briefing输出）→ StrReplace 状态 → 📬 已移交
── R-xx 规范偏差 ──
StrReplace 状态 → 🔄
Read: .cursor/skills/project-convention-resolver/SKILL.md
完整执行其所有 Step（接收-分类-路由-验证）
完成 → StrReplace 状态 → ✅
── D-xx 仅存档 ──
StrReplace 状态 → 🔄
Read: [项目路径]/技术架构师/技术架构.md（若存在）
StrReplace 追加到「设计建议存档」节
StrReplace 状态 → ✅（已存档）
每条完成后输出进度：「✅ [ID] 已完成（N/Total）」→ 继续下一条
若某条执行失败 → StrReplace 状态 → ❌（原因）→ 继续下一条，不中止
Step P-3 【所有条目处理完成后的总结报告】
⚠️ 此步骤在激活队列全部为非🔲状态时执行
Read: [PATH_待办]（读取最终状态）
输出格式：
「📊 待办处理完成
──────────────────────────────────────
✅ 已完成：N 条
📬 已移交：M 条（等待对应 Skill 后续处理）
⏸️ 已搁置：K 条（需后续决策）
──────────────────────────────────────
详细记录见：[PATH_待办]」
常见失败模式
失败1：触发词「有几个问题」被 A1 产品开发域抢占
→ 根因：消息含「问题/bug」特征被路由到协调者，本 Skill 不被激活
→ 预防：用户需使用含「待办」的触发词；session-bootstrap 排除条件中已加「项目待办/待办文档」
失败2：执行目标 Skill 时走捷径（跳过 D0 读取或知识导航表）
→ 根因：AI 认为「我已经知道这个 Skill 做什么了」，省略了 Read 步骤
→ 预防：P-2-3 明确「完整执行」定义——EVERY step，包括所有 Read 操作；看到跳步立即重新执行
失败3：处理模式中途停止（P-3 未执行）
→ 根因：某条引导过程中断，AI 以为任务结束
→ 预防：P-3 是强制步骤；队列中有 🔲 条目时不能输出 P-3
失败3：Feature 移交后标 ✅（错误）
→ 根因：Feature 设计流程未完成，仅移交给协调者
→ 预防：Feature/UX 移交后标 📬 已移交，不标 ✅
失败4：零条可解析时写入空行
→ 预防：C-1 后若 N=0，不执行 C-2，输出提示请用户分条列出
失败5：内部触发子 Skill 变成伪造用户消息（导致嵌套触发）
→ 根因：AI 发新用户消息包含触发词，再次命中 A1 路由
→ 预防：P-2 明确「内部 dispatch：Read SKILL.md 按其步骤执行，禁止伪造用户触发句」
注意事项
- 收集不执行：收集模式只写文档，不触发任何修复或设计流程
- 文档是状态：所有状态写在
项目待办.md，AI 进程中断可从文档恢复
- P2 Bug 只记录：写入追踪台但不修复，控制批次执行范围
- Feature 只移交：Feature/UX 移交协调者后标 📬，等待协调者完整处理
- 触发词必须含「待办」：防止与 issue-tracker / bug-fix-loop 的触发词冲突
变更记录
v1.3 — 2026-03-25 — P-2 改为自动逐条完整执行（移除手动确认流程）
根因：v1.1/v1.2 的「输出激活命令 → 等用户复制发送」设计过于保守，用户需要手动
复制粘贴每一条命令，体验极差。用户的正确预期是：一句「处理项目待办」→ 系统自动完整执行。
关键洞察：
- v1.0 的问题是「完整执行」指令不明确，AI 走捷径跳步骤
- 解决方案不是「让用户手动触发每条」，而是「给出足够明确的完整执行指令」
- P-2-3 新增「完整执行」精确定义：EVERY step + 所有 Read 操作 + 所有工具调用 + 不跳步
修改内容：
- 移除 P-2-4/P-2-5（手动确认和逐条引导流程）
- P-2-2 改为展示执行计划（立即开始，无需确认）
- P-2-3 改为「逐条完整执行」，含对每类 Skill 的精确执行指令
备份路径：history/SKILL_v1.0_20260325_before_dispatch-fix.md
v1.2 — 2026-03-25 — 可用Skill速查表 + 规范偏差类型 + P-2-1 精确路由
根因：v1.1 的 P-2-1 激活命令映射基于推断，未核实真实 Skill 触发词和处理范围；
缺少规范偏差（R-xx）类型；B-xx Bug 未考虑「需先写追踪台再激活修复循环」的前置步骤。
修改内容：
- 新增：「可用 Skill 速查表」章节（基于读取全部真实 SKILL.md 文件后整理）
- 新增：R-xx 规范偏差类型（→ 【规范修复】/ project-convention-resolver）
- 更新：C-1 类型分类加入「规范偏差」和更准确的类型描述
- 更新：P-2-1 路由为两步流程（B-xx P0/P1 先写追踪台，再生成【修复循环】命令）
- 更新：D-xx 纳入迭代 → 【协调者】（原为【架构师】，协调者才是入口）
数据来源：逐一读取 role-产品开发协调者/issue-tracker/bug-fix-loop-coordinator/
engineering-principle-recorder/role-测试工程师/role-产品经理/role-技术架构师/
role-前端开发/role-后端开发/role-AI工程师/role-DevOps/fixer/project-convention-resolver 的 SKILL.md 原始文件
备份路径：history/SKILL_v1.0_20260325_before_dispatch-fix.md
v1.1 — 2026-03-25 — P-2 重构：内部dispatch → 激活队列输出
根因：v1.0 的 P-2「内部 dispatch」= AI 自己模仿 Skill 行为，跳过了 D0 读取、
文档守门、关卡等所有规范步骤，导致任何被「内部调用」的 Skill 实际上没有被真正执行。
Bug 修复没有读产品文档、功能需求没有走关卡、原则录入没有搜索违规——完全不符合规范。
设计原则更新：
- project-backlog 只负责「收集」和「排队」，不执行具体任务
- 所有任务必须通过「激活队列 → 用户显式触发 → A0.5 正式激活对应 Skill」完成
- 这样每个 Skill 都能完整走 D0 读取 + 完整流程步骤
修改内容：
- P-1：保留前置决策收集逻辑
- P-2：完全重写为「生成激活队列 + 输出 + 引导逐条执行」
- P-3：改为「队列全清空后的总结报告」
- 新增失败模式：AI 自行执行而非生成队列
配套说明：
通用设计原则（对所有 Skill 有效）：
「任何 Skill 不应尝试内部执行另一个 Skill，应输出显式激活命令交给 A0.5 处理」
备份路径：history/SKILL_v1.0_20260325_before_dispatch-fix.md
v1.0 — 2026-03-24 — 初始创建（关卡A/B 修复后版本）
根因：缺少前置收集层，混合输入被立即路由，意图遗漏且无法积累待办。
关卡A 修复：
- P-1 标题修正为「Feature/UX/设计建议类」（非「B类」）
- P-2「等待完成」改为「Read SKILL.md 按其步骤执行，完成后更新状态」
- Feature/UX 状态改为 📬 已移交（不标 ✅）
- C-1 零条解析时不写文件
- 触发词新增「待办」作为必要关键词，与 issue-tracker 区分
关卡B 修复：
- 触发词改为「处理项目待办/按待办文档逐条」（含「待办」强绑定，与 bug-fix-loop 区分）
- 模式判断段明确「必须含待办关键词才激活」
- P-2 明确「内部 dispatch，禁止伪造用户触发句」
- role-menu + session-bootstrap 已在部署步骤中更新（见下方）
产品定义草稿：.cursor/skills/skill-designer/draft-project-backlog.md
Level 3 集成型：依赖 engineering-principle-recorder / bug-fix-loop-coordinator / role-产品开发协调者
