| name | claude-config-advisor |
| description | 审查或设计 Claude Code 项目配置。用于用户提到 `.claude`、`CLAUDE.md`、Claude 配置文件、项目级 Claude 自定义配置、配置结构是否合理、该创建哪些配置文件，或希望从零规划 Claude 配置时使用。默认先审查或诊断，再给方案；只有用户明确要求时，才进一步输出推荐结构或样例文件。 |
Claude Config Advisor
帮助用户评估现有 Claude Code 项目配置，或从零设计一套合适的 .claude 与 CLAUDE.md 结构。
设计模式
本 skill 主要采用：
- Reviewer：先判断现有配置是否合理，再给评价
- Inversion：信息不足时先追问最小必要问题，不一上来就堆完整方案
- Generator（轻度）：只有在用户明确需要落地建议时，才生成推荐目录树或样例
Gotchas
- 不要一上来就默认用户需要全套
.claude/agents + hooks + commands + skills
- 不要把“审查现状”和“直接帮他重构一整套配置”混成一步
- 不要为了显得专业就过度设计；简单项目往往只需要
CLAUDE.md
- 不要在没读关键文件前就断言结构合理或不合理
- 如果信息不足，先问一个最短问题，不要一次扔很多开放问题
工作模式
先判断当前属于哪一类：
- 审查模式
用户已经有
.claude/、CLAUDE.md、CLAUDE.local.md 或相关配置文件。
- 设计模式
用户还没有配置，或明确表示想先规划再创建。
使用流程
复制此清单并跟踪进度：
处理进度：
- [ ] 步骤 1：识别场景（审查 / 设计）
- [ ] 步骤 2：读取最小必要文件
- [ ] 步骤 3：判断结构合理性
- [ ] 步骤 4：给出评价与建议
- [ ] 步骤 5：如用户需要，再输出推荐结构或样例
Step 1: 识别场景
优先看用户是否已经提到这些内容：
- 项目根目录下的
CLAUDE.md 或 CLAUDE.local.md
.claude/skills/.claude/agents/.claude/commands/.claude/hooks/.claude/output-styles/.claude/settings.json 或 .claude/settings.local.json
判断规则：
- 如果这些文件或目录已存在，进入“审查模式”
- 如果不存在，或用户只是在规划，进入“设计模式”
Step 2: 读取最小必要文件
审查模式
只读取与判断有关的文件，不要整仓库乱扫。
优先读取：
CLAUDE.md / CLAUDE.local.md.claude/ 目录的一级结构.claude/skills/ 下被用户点名或最关键的 SKILL.md.claude/agents/ 下与当前诉求相关的 agent 定义.claude/commands/ 中具有代表性的命令模板.claude/hooks/ 的配置文件和关键脚本
需要判断目录职责或创建规范时，读取 references/layout-and-rules.md。
需要判断 CLAUDE.md 是否写得合理时，读取 references/claude-md-guide.md。
需要给出现状评分和优化优先级时，读取 references/review-rubric.md。
设计模式
先了解用户想法，再给建议，不要上来就堆一整套复杂结构。
优先确认这些信息：
- 这是个人项目还是团队项目
- 想解决什么问题：规范协作、复用命令、封装技能、子智能体分工、自动执行 hooks
- 是否需要提交到 Git 与团队共享
- 是否更偏“极简”还是“体系化”
需要推荐合适的目录组合时，读取 references/structure-patterns.md。
Step 3: 判断结构合理性
审查模式下的核心判断
从这几个角度判断“是否合理”：
-
职责是否清晰
CLAUDE.md 是否承担全局规范与上下文说明.claude/skills/ 是否承载可复用的专项能力.claude/agents/ 是否承载明确分工的子智能体.claude/commands/ 是否承载可重复执行的提示词模板.claude/hooks/ 是否承载确定性的自动脚本
-
结构是否匹配需求
- 只是一个简单项目，却堆了大量 agents / hooks / output styles，通常是过度设计
- 团队协作很复杂，却只有一个臃肿的
CLAUDE.md，通常是职责混杂
-
内容是否易维护
CLAUDE.md 是否简洁、可读、偏规则而不是长篇背景故事- skill 是否有 frontmatter，description 是否能准确触发
- 是否把可共享配置与个人本地偏好混在一起
-
是否有明显缺口
- 有团队规范但没有
CLAUDE.md
- 有复杂重复工作流但没有 commands
- 有高频且确定性的检查动作却没有 hooks
- 有稳定的专项任务却没有 skills 或 agents
设计模式下的核心判断
重点判断用户真正需要的是哪一层配置，而不是默认全加：
- 只需要项目约束：先上
CLAUDE.md
- 需要复用提示：加
.claude/commands/
- 需要封装专项知识：加
.claude/skills/
- 需要明确角色分工：加
.claude/agents/
- 需要自动执行脚本：加
.claude/hooks/
Step 4: 输出方式
审查模式输出模板
必须包含以下四部分：
# 配置评价
结论：合理 / 基本合理但有改进空间 / 不太合理
## 做得好的地方
- ...
## 主要问题
- ...
## 优化建议
1. ...
2. ...
3. ...
补充规则：
- “是否合理”必须明确表态，不要只说“可以优化”
- 评价要结合用户当前规模和目标，避免脱离场景
- 建议按优先级排序，先讲结构性问题，再讲润色项
- 如果用户要求，可以继续给出推荐目录树和示例文件
设计模式输出模板
必须包含以下三部分：
# 推荐方案
## 我对需求的理解
- ...
## 建议创建的文件与目录
- ...
## 为什么这样设计
- ...
如果信息不足，先用最短问题让用户补充想法，例如：
- “你更想要极简方案，还是团队协作型方案？”
- “你目前最想让 Claude 帮你稳定执行的是规范、命令、还是专项技能？”
不要一次问很多开放问题。
Step 5: 提供推荐结构或样例
当用户明确需要落地建议时，再给结构树、样例骨架或文件职责说明。
推荐优先使用 references/structure-patterns.md 中的方案做裁剪，而不是每次从头发明结构。
审查原则
- 先判断是否过度设计，再判断是否缺少关键配置
- 先看职责分层，再看命名和写法细节
- 共享规范放到可提交文件；个人偏好放到本地文件
CLAUDE.md 应尽量短，强调规则、命令入口和例外事项- 只有当某类需求真实存在时，才建议引入对应目录
何时读取额外参考
