diff --git a/.agents/skills/unidesk-oa/SKILL.md b/.agents/skills/unidesk-oa/SKILL.md
index fca1ba82..d8c2f55a 100644
--- a/.agents/skills/unidesk-oa/SKILL.md
+++ b/.agents/skills/unidesk-oa/SKILL.md
@@ -37,14 +37,14 @@ Use this skill to keep HWLAB Cloud M1 project management centered on a stable ma
 3. When writing GitHub issues/PR comments, also use `unidesk-gh`; all writes must go through `bun scripts/cli.ts gh ...` from `/root/unidesk`.
 4. When editing long-lived HWLabOA project docs, keep stable planning content in master/spec files and use phase-report docs only for dated summaries.
 
-## Required Hierarchy
+## Required Hierarchy And Responsibility
 
 Use this task tree unless the user gives a stricter one:
 
-- L0: Major project / master specification.
-- L1: Direction.
-- L2: Topic.
-- L3: Subtopic / validation slice.
-- L4: Execution task / PR / CaseRun / smoke / doc closeout.
+- L0: Major project / master specification. Owns mission, non-goals, current center, L1 direction tree, global acceptance, and drift rules.
+- L1: Direction. Owns a stable capability domain that serves L0, its scope boundary, success criteria, and L2 topic list.
+- L2: Topic. Owns a concrete program of work inside one L1 direction, including deliverables, blockers, and validation plan.
+- L3: Subtopic / validation slice. Owns one bounded acceptance path, such as one CaseRun line, Web check, CLI smoke, or deployment/control-plane validation.
+- L4: Execution task / PR / CaseRun / smoke / doc closeout. Owns concrete execution and evidence collection; it cannot redefine parent scope.
 
 Every non-trivial issue should state its parent links, target branch/lane, acceptance criteria, validation entry, and closeout writeback target.
diff --git a/.agents/skills/unidesk-oa/references/project-planning.md b/.agents/skills/unidesk-oa/references/project-planning.md
index eefaf9e4..0b80e9df 100644
--- a/.agents/skills/unidesk-oa/references/project-planning.md
+++ b/.agents/skills/unidesk-oa/references/project-planning.md
@@ -68,6 +68,26 @@ Prefer one master file first. Split only when the master becomes too large or wh
 
 ## L0-L4 Rules
 
+### Responsibility Boundaries
+
+Use the hierarchy as a responsibility split, not only a numbering scheme:
+
+| Level | Owns | Does not own | Writes back to |
+| --- | --- | --- | --- |
+| L0 | Mission, non-goals, current center, L1 direction tree, global acceptance, drift rules | PR details, CaseRun logs, daily status, implementation design | HWLabOA master spec and L1 issues |
+| L1 | Capability-domain scope, success criteria, L2 topic list, original validation class | Single PRs, one-off smokes, repository/tool/runtime names, project-management mechanics | L0 issue and HWLabOA when direction scope changes |
+| L2 | Concrete program of work inside one L1, deliverables, blockers, validation plan | Broad capability domains or implementation minutiae | L1 issue, then L0 for material movement |
+| L3 | Bounded validation slice with one acceptance path | Roadmaps, multi-topic programs, parent-scope changes | L2/L1 issue with evidence |
+| L4 | Concrete execution: PR, CaseRun, smoke, deployment, doc closeout | New requirements, new direction scope, acceptance-rule changes | Nearest L3/L2/L1 with original-entry evidence |
+
+Classification rule:
+
+- If it changes mission, current center, L1 list, or global acceptance, it belongs to L0.
+- If it defines a durable capability domain that can contain multiple topics, it belongs to L1.
+- If it plans a concrete program of work inside one direction, it belongs to L2.
+- If it can be validated through one bounded path, it belongs to L3.
+- If it is one PR, one CaseRun, one smoke, one deployment, or one document closeout, it belongs to L4.
+
 ### L0 Major Project
 
 The L0 item defines:
diff --git a/.agents/skills/unidesk-oa/references/templates.md b/.agents/skills/unidesk-oa/references/templates.md
index 2bc70ca9..2ae56e9f 100644
--- a/.agents/skills/unidesk-oa/references/templates.md
+++ b/.agents/skills/unidesk-oa/references/templates.md
@@ -92,6 +92,16 @@ One paragraph describing the product and research objective.
 
 编号规则: 项目编号格式为 PJ<立项年份>-<层级路径>；PJ 表示项目，HWLAB L0 为 PJ2026-01；L1 为 PJ2026-0101；L2 继续追加两位，例如 PJ2026-010102 表示 HWLAB L1 第 1 个方向下的第 2 个 L2 课题；更深层级继续每级追加两位。短名一般控制在 8 个中文汉字以内，解释写入正文说明。
 
+## 职责边界
+
+| 层级 | 负责定义 | 不负责 | 回写对象 |
+| --- | --- | --- | --- |
+| L0 | 项目使命、当前中心、L1 方向树、全局验收、偏离规则 | PR 细节、CaseRun 日志、日报流水 | HWLabOA 总规格、L1 issue |
+| L1 | 能力域范围、成功标准、L2 课题清单、原入口验收类型 | 单个 PR、一次 smoke、仓库/工具/runtime 名称、项目管理动作 | L0 issue、HWLabOA |
+| L2 | 单个方向内的具体课题、交付物、阻塞、验收计划 | 总方向定义、实现细节流水 | L1 issue，重大移动再回写 L0 |
+| L3 | 一个有界验收切片和单一验收路径 | 路线图、跨课题计划、父级范围变化 | L2/L1 issue |
+| L4 | PR、CaseRun、smoke、部署、文档收口等执行和 evidence | 新需求、新方向、验收规则变化 | 最近的 L3/L2/L1 |
+
 ## 全局验收
 
 - ...