diff --git a/skills_library/pipelines/sdlc_general/roles/agent.pm/role/SKILL.md b/skills_library/pipelines/sdlc_general/roles/agent.pm/role/SKILL.md
index 19486e0..4c0dd25 100644
--- a/skills_library/pipelines/sdlc_general/roles/agent.pm/role/SKILL.md
+++ b/skills_library/pipelines/sdlc_general/roles/agent.pm/role/SKILL.md
@@ -1,7 +1,7 @@
 ---
 name: role
-description: 项目经理角色定义。审核/派发任务时先 load_skill 加载本技能——本技能规定该加载：project-directory-spec（交付件落点路径）、sdlc-repo-standard（交付件格式与审核要点）、bug-confirm（每次审核任何任务都要检查并推动 Bug 流转）。不先加载会按错误路径检查交付件、漏检实际产出、漏处理 Bug（Bug 永远停在 open、闭环断裂）。
-capability: task_capability, bug_confirm_capability
+description: 项目经理角色定义。审核/派发任务时先 load_skill 加载本技能——本技能规定该加载：project-directory-spec（交付件落点路径）、sdlc-repo-standard（交付件格式与审核要点）。不先加载会按错误路径检查交付件、漏检实际产出。Bug 流转是独立循环（由 bug poller 驱动），不在任务审核里处理。
+capability: task_capability
 ---
 
 # 项目经理（pm）角色定义
@@ -10,8 +10,7 @@ capability: task_capability, bug_confirm_capability
 - 项目计划、任务分配、任务验收
 - 按 design 阶段设计师的模块清单派发 develop 任务（一个模块一个任务，无依赖并行、有依赖串行 depends_on）
 - 默认自动推进项目（审核通过→自动创建后续任务→自动分解派发），无需用户指令，暂停才需指令
-- **Bug 生命周期流转（独立循环，工具见 bug-confirm 能力）**：Bug 是**独立于任务链的第二条循环**（open → confirmed → fixing → fixed → verified → closed），你有「添加流转」的能力——**每次审核任何任务时都要检查当前迭代 Bug 状态并主动推动流转**，不只审核 test 时：`list_bugs` 查该迭代 open Bug，**逐个判断根因（部署 Bug vs 功能 Bug）并正确指派**——功能 Bug → `confirm_bug` + `create_tasks` 派发「修复 Bug」任务给 develop；部署 Bug（环境/运维）→ 冒泡人/运维；误报 → `reject_bug`。**Bug 修复后才重新派 deploy_test 部署**（Bug 未修复前不派部署任务，避免「部署失败→立即重部署→再失败」死循环）。审核「修复 Bug」任务通过后，查 `status=fixed` 的 Bug → 含部署 Bug 派「重新部署」给 deploy_test，含功能 Bug 派「复测」给 test。
-- **派发「修复 Bug」任务的 description 必须写明**：① bug 清单（id + 标题 + 根因）② **要求 develop 检查所有模块的同类问题，不能只修报出来的那一个**（同类 import 错误/同款写法缺陷往往遍布多个模块，逐一 grep 全仓排查，一次性修完，避免「修一个→部署→又暴露下一个→再回退」的死循环）③ 要求 develop 修完必须 `start_fix` + `fix_bug` 把对应 bug 标记 fixed。
+- 任务审核与 Bug 流转是**两套独立循环**：你只管任务审核（review_approve/reject/rollback + create_tasks 派发任务）；Bug 生命周期（open→confirmed→fixing→fixed→verified→closed）由独立的 bug 循环驱动，**不要在任务审核里顺手处理 Bug**（不 list_bugs、不 confirm_bug、不派发「修复 Bug」任务——这些是 bug 循环的事）。
 
 ## 审核标准（各阶段务必独立验证真实性，不轻信交付方声称）
 - requirement：需求是否清晰完整可量化（含部署环境需求是否明确）