技能介绍

为什么需要专门的 CLI 配置审计

Codex、Antigravity（Gemini CLI）和 Claude Code 的配置分散在 ~/.codex/、~/.gemini/、~/.claude/ 以及项目内的 CLAUDE.md、AGENTS.md、settings.json 等文件中。设置层叠（插件 → 用户 → 项目 → 本地 → 托管）容易互相覆盖；MCP 服务器的 PAT 范围、OAuth 传输和 RFC 8707 资源绑定一旦配错，可能把 Shell 访问和数据外泄风险放大。Hooks 在 -p 非交互模式下行为与文档预期不一致、wire_api = "chat" 已弃用等问题，单靠「凭感觉改配置」很难系统对齐官方最佳实践。

Hone 如何工作

Hone 扮演 AI CLI 配置审计员：只读配置、只出建议，永不直接编辑任何配置文件，也不读取认证令牌与会话历史。

工作流固定为 FETCH → AUDIT → PROPOSE：

FETCH：用 Web 检索对照 Codex / Antigravity / Claude Code 官方文档与发布说明，对引用来源做 T1–T4 层级标注。
AUDIT：按目标 CLI 读取全部相关配置，对照 reference/audit-checklist.md 逐项检查（模型与信任级别、MCP 健康度、权限 allow/deny、hooks 结构与退出码、CLAUDE.md 行数与指令密度等）。
PROPOSE：用 Before/After 差异格式输出改动建议，并为每条标注 P0–P3 优先级与 safe / ask-first / risky 安全分类。

子命令可按范围收窄：codex（含 wire_api 弃用）、agy（Antigravity 安全与 GEMINI.md）、claude（权限、MCP、hooks）、或默认 audit 做全面审计。涉及 hooks 设计/调试会路由到 Latch；纯 Shell/编辑器环境则交给 Hearth。

边界与注意点

涉及信任级别变更、MCP 增删、权限或 hooks 改动类建议，Hone 会先询问再推进。它不做代码 review（Judge）、不做 OWASP/WCAG 合规（Canon）、也不替代 Latch 做 hook 实现。审计前必须先 FETCH 官方文档；不会仅依据 T4 来源给出核心建议。对超过 300 行 的 CLAUDE.md、宽范围 MCP PAT、第三方插件自动更新等会按 SKILL 内阈值标为 P0/P1，便于你按风险排序处理。