1、SubAgent
SubAgents 是执行分工。它回答的是谁来做。当任务复杂到需要独立上下文时，子代理承担专职职责，类似团队中的同事
2、Skills 技能系统
怎么做，以及何时做 可操作知识结构
定义：
比较精确的定义：Skills 是一种可被语义触发的能力包，它包含领域知识、执行步骤、输出规范与约束条件，并在需要时渐进式加载到主 Agent 的认知空间中。
一个 Skill，则是一段具备语义入口的标准操作程序。它通过 description 告诉模型：
触发条件：在什么情况下应该加载这项能力。
执行流程：它在正文中定义执行步骤，将抽象原则转化为可执行流程。
质量标准：它通过模板约束输出格式，确保结果标准化。
工具约束：它可以限制可调用工具的范围，防止越权操作。
自动检查：通过 hooks 在完成后自动执行验证逻辑
把文档封装为 Skill，它就不再是参考资料，而成为一种可被调用的行为模式
如果把 Claude Code 的技术栈映射到企业组织结构，我们会发现一种高度对称的关系。Tools 对应员工的操作工具；SubAgents 对应岗位分工；Hooks 对应质量与合规流程；CLAUDE.md 类似企业文化与通用规章；MCP Servers 像外部合作伙伴；Plugins 是对外打包的解决方案。
而 Skills，正是企业的 SOP 体系。
触发原理
和 Sub-Agents 类似，Skills 的触发机制靠 LLM 语义推理，而非精确匹配。Claude 读取所有 Skills 的 description，通过语义理解判断当前对话是否匹配某个 Skill.
输入->扫描所有Skills的description ->通过推理匹配找到最相关的，-找到后加载skill.md 找匹配，找不到正常处理请求
当用户请求可能匹配多个 Skills 时，Claude 会：评估每个 Skill 的 description 与用户请求的相关性。选择最相关的那个。如果不确定，可能会询问用户或使用通用方式处理。
按位置由大到小顺序加载，如全局->项目目录->个人目录
skill类型
两大类型的 Skills：参考型和任务型
参考型： 提供知识，。在什么场景下应用这些知识， 应用举例：API规范，代码风格，领域知识
任务型：执行具体的操作步骤 ： 这个操作做什么， 如：部署流程、提交规范、代码生成
# 参考型——Claude 自动选择是否使用
name: api-conventions
description: API design patterns for this codebase. Use when writing or reviewing API endpoints.
# 任务型——通常由用户手动触发
name: deploy
description: Deploy the application to production
disable-model-invocation: true
参考型SKill
1、没有执行步骤：不是先做 A 再做 B，而是“遵循这些规范”。
2、没有输出模板：不要求 Claude 输出固定格式的报告。
3、没有设disable-model-invocation：Claude 可以自动判断何时需要。
4、只读工具：allowed-tools 限制为 Read/Grep/Glob，因为规范查阅不需要改代码。
它告诉 Claude 在我们的世界里，API 应该长什么样
description 是 Skill 的灵魂，因为它不是给人看的文档，而是给 Claude 看的触发器。Claude 选择是否激活一个 Skill，完全依赖于阅读 description。这不是关键词匹配，而是语义理解。
description 写作公式： description = [做什么] + [怎么做] + [什么时候用]
格式
遵循“导航页 + 详情页”模式
SKILL.md ← 导航页：概述 + 引用（< 500 行）
├── reference.md ← 详情页：详细 API 文档
├── examples.md ← 详情页：使用示例
└── scripts/validate.sh ← 工具：可执行脚本
任务型Skill
/command 已变成skill的子集
简单来说，任务型 Skill 就是设了 disable-model-invocation: true 的 Skill。
什么时候该加上disable-model-invocation: true claude不可自动操作的工程经验：想一下最坏情况，如果你感觉有点紧张，那就加上吧~~
内置命令：
/help 查看帮助
/clear 清空对话
/compact 压缩上下文
/memory 编辑记忆
/status 状态信息
自定义命令：
/commit
/review
。。。
.claude/skills/<name>/SKILL.md # 推荐：Skills 目录（完整能力）
.claude/commands/<name>.md # 兼容：Commands 目录（简单命令）
# 参考型——Claude 自动选择是否使用
name: api-conventions
description: API design patterns for this codebase. Use when writing or reviewing API endpoints.
# 任务型——必须用户手动触发
name: deploy
description: Deploy the application to production
disable-model-invocation: true
当你通过 /skill-name args 调用 Skill 时，args 会通过 $ARGUMENTS 注入到 Skill 内容中。举例来说，当运行 /fix-issue 123 时，Claude 收到的内容是“Fix GitHub issue 123 following our coding standards…”。
---
name: fix-issue
description: Fix a GitHub issue
disable-model-invocation: true
---
Fix GitHub issue $ARGUMENTS following our coding standards.
1. Read the issue description
2. Understand the requirements
3. Implement the fix
4. Write tests
5. Create a commit
Skills Frontmatter
官方：
---
name: my-skill-name # 可选：Skill 标识符（省略则用目录名）
description: What this does # 推荐：触发器（最重要！）
argument-hint: "[issue-number]" # 可选：自动补全时的参数提示
disable-model-invocation: true # 可选：禁止 Claude 自动触发
user-invocable: false # 可选：对用户隐藏 /skill-name
allowed-tools: # 可选：限制可用工具
- Read
- Grep
- Glob
model: sonnet # 可选：指定执行模型
context: fork # 可选：在子代理中隔离执行
agent: Explore # 可选：context: fork 时的代理类型
hooks: # 可选：作用域为此 Skill 的 Hooks
PreToolUse:
- matcher: Write
hooks:
- type: command
command: "echo 'Write called in skill'"
---
其中所有字段都是可选的，但强烈建议提供 description，否则 Claude 无法判断何时使用。
1、name 字段：最大 64 字符，只能使用小写字母、数字、连字符，推荐使用动名词形式：code-reviewing、api-documenting、bug-fixing。如果省略了这个字段（通常不大可能啦），则自动使用目录名（.claude/skills/code-reviewing/ → name 为 code-reviewing）
2、description 字段：这是最重要的字段——它决定 Skill 何时被触发。这个字段应该包含两部分信息：这个 Skill 做什么，以及什么情况下使用它。如果省略了这个字段（也不大可能啦），系统会使用 Markdown 正文的第一段作为 description。
3、argument-hint 字段：自动补全提示，为用户提供参数格式提示，在输入 /skill-name 时系统会自动补全显示：
4、disable-model-invocation 和 user-invocable这两个字段组合起来控制“谁能触发这个 Skill”。
5、allowed-tools 字段用来限制 Skills 被激活时 Claude 能使用的工具。
Skills 支持的工具包括 read,grep,glob（文件匹配）,bash,edit,write,task(创建子代理)
6、context、agent、model——Skills 的执行环境。
7、hooks——Skill 级别的 Hooks，可以为 Skill 定义仅在其生命周期内生效的 Hooks。
allowed-tools:
- Bash(git:*) # 只能执行 git 命令
- Bash(npm test:*) # 只能执行 npm test 相关命令
Skills 是可由用户或 Claude 触发的能力包，Claude 通过语义推理决定何时激活，但目前已经脱离了 Claude Code 本身，形成了 Agent 通用技能生态。Skill 的 description 不是文档，而是触发器，其构建公式为：做什么 + 怎么做 + 什么时候用Claude Code 采用渐进式加载来节省 token——description 常驻上下文，全文仅在触发时加载。
3、Tools 最基本
能做什么。读文件、改代码、执行 Bash 命令……这些是操作层面的能力，类似人的双手
4、hooks 钩子
Hooks 是流程规则。它回答的是什么时候检查。它们在关键节点自动触发质量校验或合规约束，类似企业中的质检流程
headless
unix风格，可以将数据管道到claude
# 分析日志文件
cat server.log | claude -p "找出所有错误并总结原因"
# 解析 JSON
curl https://api.example.com/data | claude -p "提取所有用户的邮箱地址"
# 代码转换
cat old-code.js | claude -p "将这段 JavaScript 转换为 TypeScript"
管道的真正威力在于组合。下面这些例子展示了 Claude Code 如何与 find、git、grep 等经典 Unix 工具协作。每个组合都解决了一个真实的开发场景——批量检查类型提示、总结提交变更、将散落的 TODO 转换为规范的 Issue 格式。
# 结合 find 和 xargs 批量处理
find src -name "*.py" | xargs -I {} claude -p "检查 {} 中的类型提示是否完整"
# 结合 git 工作流
git diff HEAD~1 | claude -p "总结这次提交的变更"
# 结合 grep 预过滤
grep -r "TODO" src/ | claude -p "将这些 TODO 转换为 GitHub Issue 格式"
CLAUDE.md 在 Headless 模式中扮演着关键角色。无论是 pre-commit hook 还是 GitHub Actions 中的 Claude，都会读取项目根目录的 CLAUDE.md 来了解审查规范。这意味着你可以通过一份配置文件，统一所有环节的审查标准。
# 代码审查规范
## 审查重点
1. 代码质量：命名规范、DRY 原则、复杂度
2. 安全问题：输入验证、SQL 注入、XSS
3. 性能问题：N+1 查询、内存泄漏
4. 测试覆盖：关键路径必须有测试
## 输出格式
- Critical: 必须修复
- Warning: 应该修复
- Suggestion: 建议改进
## 禁止操作
- 不要修改 .env 文件
- 不要执行 npm publish
- 不要修改数据库迁移文件
发表于 
