diff --git a/skills_library/pipelines/sdlc_general/common/bug-fix/SKILL.md b/skills_library/pipelines/sdlc_general/common/bug-fix/SKILL.md
index eb728ec..2373009 100644
--- a/skills_library/pipelines/sdlc_general/common/bug-fix/SKILL.md
+++ b/skills_library/pipelines/sdlc_general/common/bug-fix/SKILL.md
@@ -17,9 +17,10 @@ tools: [classify_task, start_fix, fix_bug, list_bugs]
 | classify_task 结果 | 含义 | 是否走 bug 状态机 |
 |---|---|---|
 | `bug_fix` | PM 派发的「修复 Bug」任务 | 必须：开始 start_fix → 改代码 → 完成 fix_bug |
-| `rework` | 回退重做（修复导致上游失败的缺陷） | 必须：list_bugs 查对应 open bug → start_fix → 改代码 → fix_bug |
-| `new_dev` | 纯新开发（应用脚手架/模块开发） | 不必；但过程中自己 report 的新 bug 若修了也要 fix_bug |
+| `rework` | 回退重做（QC/PM 退回重做交付件） | 否，不调 bug 工具，只重做交付件 |
+| `new_dev` | 纯新开发（应用脚手架/模块开发） | 否；但过程中自己 report 的新 bug 若修了也要 fix_bug |
 
 ## 状态机
 完整流转见 `bug` 技能（open → confirmed → fixing → fixed → verified → closed）。
-修复/回退重做任务里，修完代码必须 `start_fix` + `fix_bug` 把对应 bug 标记 fixed，不能只交代码。
+**只有 bug_fix 任务走 bug 状态机**：修完代码必须 `start_fix` + `fix_bug` 把对应 bug 标记 fixed。
+rework/new_dev 不调 bug 工具（start_fix/fix_bug 仅用于 PM 派发的「修复 Bug」任务）。
diff --git a/skills_library/pipelines/sdlc_general/roles/agent.develop/role/SKILL.md b/skills_library/pipelines/sdlc_general/roles/agent.develop/role/SKILL.md
index c5bdbb7..50f71b4 100644
--- a/skills_library/pipelines/sdlc_general/roles/agent.develop/role/SKILL.md
+++ b/skills_library/pipelines/sdlc_general/roles/agent.develop/role/SKILL.md
@@ -9,9 +9,9 @@ capability: feature_dev_capability, bug_fix_capability
 ## 接到任务第一步（必做）
 - **先调用 `classify_task` 判断任务来源**（new_dev / bug_fix / rework），再决定后续动作：
   - `bug_fix`（PM 派发的「修复 Bug」任务）：任务开始先 `list_bugs` 定位 bug → `start_fix` 标记修复中 → 改代码 → 完成时 `fix_bug` 标记 fixed
-  - `rework`（回退重做任务）：修缺陷前 `list_bugs` 查当前迭代 open bug，找出本次要修的 → `start_fix` → 改代码 → `fix_bug`
+  - `rework`（回退重做任务）：重做交付件（修复 QC/PM 退回的问题），**不调 bug 工具**——它不是修 bug，是重做
   - `new_dev`（纯新开发）：正常开发，不走 bug 状态机
-- **不判断来源直接闷头改代码，是导致 bug 永远 open、PM 派不出重新部署、任务链断的根因**——修复代码和推进 bug 状态是一体的。
+- **只有 bug_fix 任务才走 bug 状态机**；rework/new_dev 不调 start_fix/fix_bug。判断错来源会导致 bug 状态机错乱或 bug 永远 open。
 
 ## 职责
 
@@ -30,12 +30,9 @@ capability: feature_dev_capability, bug_fix_capability
 - 修复流程：`list_bugs` 查 bug → `start_fix`（confirmed/open→fixing）→ 改代码 → `fix_bug`（fixing→fixed，附 fix_description + fix_commit）
 - 状态迁移只用工具（start_fix/fix_bug），不直接改 sd_bugs 库
 
-### 回退重做任务（params 带 rollback_from/rollback_comment，说明部署/测试发现的缺陷）
-- 这类任务本质是「修复导致上游失败的缺陷」，修完代码后**必须走 bug 状态机**，不能只交 code_files 了事：
-  1. `list_bugs` 查当前迭代 `status=open`（或 confirmed/fixing）的 Bug
-  2. 找出本次修复已解决的 Bug，逐个 `start_fix`（open/confirmed→fixing）→ 改代码 → `fix_bug`（fixing→fixed，附 fix_description + fix_commit）
-  3. 若无对应 Bug 记录，说明缺陷还没被 report_bug，本次修复视为普通代码修复即可，不强行造 Bug
-- **为什么必须 fix_bug**：若只交代码不 fix_bug，bug 永远 open，PM 审核修复任务通过后按 bug 闭环规则「查 status=fixed 的 Bug 派重新部署」查不到 fixed bug → 无从派发 → 任务链断在 approved。修复代码和推进 bug 状态是一体的，缺一即断链。
+### 回退重做任务（params 带 rollback_from/rollback_comment，说明 QC/PM 退回原因）
+- 这类任务是**重做交付件**（修复退回的问题），**不调 bug 工具**（start_fix/fix_bug 只用于 bug_fix 任务）
+- 认真读 rollback_comment 里的退回原因，逐条响应修复，重新产出合格交付件
 
 ## 应遵守的规范（开发前先 load_skill 加载对应全文，不要凭记忆瞎写）
 - `module-development-spec`：模块目录结构（Python 包目录=模块名、非 src）、init.py 三处同步注册、pyproject.toml、scripts/load_path.py