diff --git a/.agents/skills/unidesk-subagent/SKILL.md b/.agents/skills/unidesk-subagent/SKILL.md
index 90c45547..6284ac5a 100644
--- a/.agents/skills/unidesk-subagent/SKILL.md
+++ b/.agents/skills/unidesk-subagent/SKILL.md
@@ -12,6 +12,7 @@ description: UniDesk 主代理调度子代理的必读技能。用户提到子
 - 子代理并行只用于成功率高、耦合度低、能放进独立 worktree/branch/issue/PR 的任务；共享架构方向、公共契约和同文件高冲突修改先串行定锚。
 - 正式 GitHub issue/PR/comment/merge 仍走 `$unidesk-gh`；子代理可以提交 PR 和写调查结论，主代理负责 review/preflight/merge，除非用户明确授权某个子代理自上线自验证。
 - 主代理和子代理必须通过 issue/PR/comment 链接传递可复用上下文、调查结论、证据链接和下一步边界；派发前先读既有评论，prompt 中只引用链接和增量任务，不复述长结论，避免不同子代理重复调查同一事实。
+- 每个执行型子代理必须维护自己的子 issue 和该子 issue 的评论作为接续上下文；主 issue 评论区只由主代理写入主线 anchor、阶段汇总、调度决策和最终 closeout。子代理不得把过程日志、单步证据、长调查和 post-task 反馈直接堆到主 issue 评论区，只能在主 issue 需要可见时由主代理引用子 issue/PR/comment 链接。
 - 每个子代理 prompt 必须写清 repo、目标分支、独立 worktree、issue/PR、禁止触碰范围、验收命令、证据字段和是否允许部署；不要让多个子代理共享同一可写 worktree。
 - 用户指定模型（例如 `gpt-5.5`）时，主代理调度子代理必须在任务描述或调度参数中显式遵守。
 - 用户要求或授权“按任务难度分配模型”时，主代理必须按复杂度选择模型与 reasoning effort，并在 prompt 中写明选择理由；默认继承主模型，只有任务难度、风险或延迟收益明确时才显式覆盖。
diff --git a/.agents/skills/unidesk-subagent/references/gh-workflow.md b/.agents/skills/unidesk-subagent/references/gh-workflow.md
index c7c80ac6..11cc6c22 100644
--- a/.agents/skills/unidesk-subagent/references/gh-workflow.md
+++ b/.agents/skills/unidesk-subagent/references/gh-workflow.md
@@ -29,9 +29,11 @@
 ## GitHub Issue 协作
 
 - 大任务先有 GitHub issue 或在既有 issue 中补并行计划：列出子任务、负责人/子代理、目标分支、预期 PR、验证入口、依赖关系和哪些任务可并行。
-- issue/PR/comment 是子代理之间传递上下文的稳定介质。主代理派发前必须先读取既有评论，在 prompt 中用 issue/comment 链接引用已确认事实、证据、阻塞点和禁止重复范围；不要复制粘贴或复述长结论。子代理开始前也要打开这些链接复用结论，除非评论已过期、与新证据冲突或主代理要求复核。
-- 调查型子代理优先把结论写入 issue comment 或 issue 正文的调查段；主代理再根据调查结论决定修复子任务，而不是让调查子代理直接扩大 scope。
-- 调查评论要写成可接力格式：结论、证据来源、未覆盖范围、下一步建议和可直接复用的命令/对象名。不要只写口头判断，也不要把无界日志或大 JSON 贴进评论。
+- 主 issue 评论区由主代理独占维护：只写主线 anchor、阶段汇总、调度决策、已采纳结论、下一批边界和最终 closeout。子代理不得直接在主 issue 评论区堆过程、日志、单步证据或 post-task 反馈；需要让主线可见时，由主代理在主 issue 引用子 issue/PR/comment 链接。
+- 每个执行型子代理必须有自己的子 issue 作为上下文容器。子 issue 标题应能反映父 issue、运行面/模块和子任务；正文必须引用父 issue、目标分支/worktree、允许范围、验收入口和当前接续链接。子代理的调查、单步证据、阻塞、post-task 和后续接力评论都写在自己的子 issue 或关联 PR 中。
+- issue/PR/comment 是子代理之间传递上下文的稳定介质。主代理派发前必须先读取父 issue 的主线 anchor 和相关子 issue/PR/comment，在 prompt 中用链接引用已确认事实、证据、阻塞点和禁止重复范围；不要复制粘贴或复述长结论。子代理开始前也要打开这些链接复用结论，除非评论已过期、与新证据冲突或主代理要求复核。
+- 调查型子代理优先把结论写入自己的子 issue comment 或子 issue 正文的调查段；主代理再根据调查结论决定修复子任务，而不是让调查子代理直接扩大 scope。
+- 调查评论要写成可接力格式：结论、证据来源、未覆盖范围、下一步建议和可直接复用的命令/对象名。不要只写口头判断，也不要把无界日志或大 JSON 贴进评论；长证据放 artifact/drill-down，评论只放 bounded 摘要和链接。
 - 主代理每轮阶段切换时在 issue 中留下短 anchor comment，说明哪些结论已经被采纳、哪些路径不再重复查、下一批子代理只需要补哪一段；后续子代理必须以该 anchor 链接为上下文起点，prompt 里引用该链接即可。
 - 修复型子代理提交 PR，并在 PR body 写明目标合并分支、关联 issue、变更范围、验证命令、风险和证据。除非用户明确授权，子代理不合并自己的 PR。
 - 需要修改 issue/PR 正文时使用 `$unidesk-gh` 或 `trans gh:/... apply-patch`；不得用原生 `gh` 或手写 GitHub API 绕过。
@@ -84,7 +86,7 @@ Prompt 应足够明确，但不要塞入无界日志、长 JSON、完整 issue d
 - 第一次问询仍无结果时，主代理可以只读检查该子代理声明或可推断的 worktree、分支、PR 和 issue comment：只看 `git status`、`git log`、`git diff --stat`、PR body 和最近 comment，不改文件、不抢实现、不重跑运行面验证。
 - 只读检查后再发一次更窄的问询，把已观察到的 worktree/branch/diff 事实告诉子代理，并要求它确认或继续最小下一步。
 - 多次问询仍无响应时，关闭旧子代理，避免长期占用并发和上下文；随后在原 worktree/原分支/原 issue/原 PR 边界上重开新子代理接续。若原 worktree 已被 merge closeout 清理，新子代理应从最新目标分支创建同任务名 worktree；若原 worktree 仍在且有未提交改动，新子代理必须先读取并保护这些改动，不得 reset、checkout 或删除。
-- 重开的子代理 prompt 必须引用旧子代理的最后 issue/PR/comment 链接、原 worktree 路径、当前分支/HEAD 和主代理只读观察结论；不要复述长日志，也不要让新子代理重复已经由 issue/comment 确认的调查。
+- 重开的子代理 prompt 必须引用旧子代理的子 issue、最后 PR/comment 链接、原 worktree 路径、当前分支/HEAD 和主代理只读观察结论；不要复述长日志，也不要让新子代理重复已经由子 issue/comment 确认的调查。
 
 ## 常见错误