feat: 支持会话级 Skill 选择与隔离（inherit / none / selected）
背景
Codeg 目前已经支持统一管理多个 Coding Agent 的 Skills，也支持 Global / Project 两种 Skill scope。
但当前 Skill 的启用方式仍然主要是 Agent 全局级别：
Agent
↓
Global / Project Skills
↓
该 Agent 的所有 Session 都能看到
随着安装的 Skills 越来越多，这种方式会带来几个问题：
-
无关 Skill 会进入当前任务上下文
- 很多任务只需要少量 Skills。
- 例如修复一个 Rust bug 时，可能只希望启用 debugging / rust-review，而不希望 frontend、browser、slides、office 等 Skills 同时参与。
-
Skill 过多会增加上下文和 Agent 决策负担
- Codex 本身在 Skill 数量较多时已经会提示 Skill descriptions 因 context budget 被压缩，并建议禁用不需要的 Skills。
- 因此 Skill 管理除了“安装了哪些”，还需要解决“当前任务允许哪些”。
-
不同 Session 无法拥有不同能力集合
- 同一个 Codex / Claude Code 同时运行多个 Session 时，理想状态应该允许：
Session A
Skills: debugging
Session B
Skills: frontend-design + browser-testing
Session C
Skills: none
这些 Session 应该可以同时运行且互不影响，而不是共同修改 Agent 的全局 Skill 目录。
建议
为 Session 增加一个明确的 Skill Policy：
1. inherit
保持当前默认行为：
Global Skills
+
Project Skills
这是默认值，确保现有用户行为完全不变。
2. none
当前 Session 不加载任何用户 Global / Project Skills。
需要做到真正隔离，而不是仅仅在 Prompt 中告诉 Agent：
Do not use skills
Agent 本次 Session 应实际无法发现或调用这些 Skills。
3. selected
当前 Session 只加载明确选择的 Skills，例如：
Selected Skills:
✓ debugging
✓ rust-review
□ frontend-design
□ browser-testing
□ slides
即使其他 Skills 已经全局安装，本 Session 也不应该看到它们。
期望的用户体验
在创建/运行 Session 时提供一个轻量的 Skills 入口：
Agent Codex
Model GPT-5.x
Effort High
Skills Inherit ▼
展开后：
○ Inherit defaults
○ No skills
● Select skills
✓ debugging
✓ rust-review
□ frontend-design
□ browser-testing
普通用户无需修改任何设置，默认仍然是 inherit。
只有有需要时才配置当前 Session。
关键要求
Session 级隔离
最重要的要求是：
不通过临时修改 Agent 全局 Skill 目录来实现。
例如不能使用：
启动 Session A
→ 删除 ~/.codex/skills 中部分链接
→ Session A 运行
→ 再恢复
这种方案无法支持并发 Session。
下面这种场景应该能够正常工作：
Codex Session A
selected = [skill-a]
Codex Session B
selected = [skill-b]
Codex Session C
none
三个 Session 同时运行时：
A 只能看到 skill-a
B 只能看到 skill-b
C 看不到用户 Skills
彼此不能产生污染。
建议的实现边界
建议把这个能力放在 Session Runtime / Agent Adapter 层，而不是写成某个特定功能的特殊逻辑。
抽象可以类似：
SessionSkillPolicy
├── Inherit
├── None
└── Selected(Vec<SkillId>)
│
▼
Skill Runtime Adapter
│
▼
Agent Launch
不同 Agent 可以根据自身原生机制实现。
例如部分 Agent 已经具备类似能力：
Pi
→ --no-skills
→ --skill <path>
Kimi
→ --skills-dir
OpenCode
→ skill permission allow / deny
OpenClaw
→ skills allowlist
DeepSeek Harness
→ includeDefaultRoots=false
→ customSkillDirs
Hermes
→ HERMES_HOME / skills config
其他 Agent 可以通过独立配置目录、Session runtime environment 等方式逐步适配。
不要求第一版一次支持所有 Agent。
可以增加类似：
SkillIsolationSupport
├── Native
├── Adapted
└── Unsupported
对于暂时无法可靠隔离的 Agent，UI 明确显示不支持即可。
与现有 Codeg Skill 管理的关系
当前的：
仍然可以继续作为统一的 Skill Registry / Source of Truth。
区别只是：
当前：
Codeg Skill Store
↓
Agent Global Skill Dir
↓
所有 Session
未来可以支持：
Codeg Skill Store
↓
Session Skill Resolver
↓
Session-specific Runtime
↓
Agent
Global Skill 设置则可以理解为默认能力集合。
为什么这不只是一个特殊场景需求
这个能力对正常 Coding Agent 使用同样有价值：
- 大量安装 Skills 后减少无关上下文；
- 降低 Skill 错误触发；
- 为不同任务提供不同能力集合；
- 更容易控制 Agent 行为；
- 多 Session 并行时拥有独立能力配置；
- 后续可以与 Task / Todo / Automation 等功能复用。
从用户视角来看，Skill 管理最终不应该只有：
“这个 Agent 安装了哪些 Skills？”
还应该能回答：
“这个任务允许它使用哪些 Skills？”
建议的第一阶段范围
V1 可以只实现：
inheritnoneselected- 至少支持 1~2 个主流 Agent
- Session 并发隔离
- Session 创建后保存 Skill Policy，恢复会话时保持一致
暂时不需要同时扩展：
- MCP / Tools Profile
- Prompt Profile
- Arena
- Eval
- Capability Profile
这些能力未来都可以建立在同一个 Session Runtime abstraction 上。
Acceptance Criteria
Related
本 Issue 更关注：
Session 运行时到底暴露哪些 Skills，以及不同 Session 之间的 Skill 隔离。
feat: 支持会话级 Skill 选择与隔离（inherit / none / selected）
背景
Codeg 目前已经支持统一管理多个 Coding Agent 的 Skills，也支持 Global / Project 两种 Skill scope。
但当前 Skill 的启用方式仍然主要是 Agent 全局级别：
随着安装的 Skills 越来越多，这种方式会带来几个问题：
无关 Skill 会进入当前任务上下文
Skill 过多会增加上下文和 Agent 决策负担
不同 Session 无法拥有不同能力集合
这些 Session 应该可以同时运行且互不影响，而不是共同修改 Agent 的全局 Skill 目录。
建议
为 Session 增加一个明确的 Skill Policy：
1. inherit
保持当前默认行为：
这是默认值，确保现有用户行为完全不变。
2. none
当前 Session 不加载任何用户 Global / Project Skills。
需要做到真正隔离，而不是仅仅在 Prompt 中告诉 Agent：
Agent 本次 Session 应实际无法发现或调用这些 Skills。
3. selected
当前 Session 只加载明确选择的 Skills，例如：
即使其他 Skills 已经全局安装，本 Session 也不应该看到它们。
期望的用户体验
在创建/运行 Session 时提供一个轻量的 Skills 入口：
展开后：
普通用户无需修改任何设置，默认仍然是
inherit。只有有需要时才配置当前 Session。
关键要求
Session 级隔离
最重要的要求是：
例如不能使用：
这种方案无法支持并发 Session。
下面这种场景应该能够正常工作：
三个 Session 同时运行时：
彼此不能产生污染。
建议的实现边界
建议把这个能力放在 Session Runtime / Agent Adapter 层，而不是写成某个特定功能的特殊逻辑。
抽象可以类似：
不同 Agent 可以根据自身原生机制实现。
例如部分 Agent 已经具备类似能力：
其他 Agent 可以通过独立配置目录、Session runtime environment 等方式逐步适配。
不要求第一版一次支持所有 Agent。
可以增加类似：
对于暂时无法可靠隔离的 Agent，UI 明确显示不支持即可。
与现有 Codeg Skill 管理的关系
当前的：
仍然可以继续作为统一的 Skill Registry / Source of Truth。
区别只是：
当前：
未来可以支持：
Global Skill 设置则可以理解为默认能力集合。
为什么这不只是一个特殊场景需求
这个能力对正常 Coding Agent 使用同样有价值：
从用户视角来看，Skill 管理最终不应该只有：
还应该能回答：
建议的第一阶段范围
V1 可以只实现：
inheritnoneselected暂时不需要同时扩展：
这些能力未来都可以建立在同一个 Session Runtime abstraction 上。
Acceptance Criteria
inherit，现有行为不变none模式下 Agent 实际无法发现用户 Global / Project Skillsselected模式下 Agent 只看到用户明确选择的 SkillsRelated
本 Issue 更关注：