如果大家觉得有帮助，欢迎点个 star 支持一下。

Motivation

这个 project 的初衷，源于我读到的 Anthropic 的 skills 设计，对这种即插即用、可组合的范式产生了强烈兴趣，觉得在抽象层面非常优雅。由此引出了一个问题：能否像搭积木一样，通过编排 skills 来完成科研流程（好吧，我承认其实是懒癌犯了，想走捷径了，想把 codex 当成拉磨的驴 Agent 来用）？进一步来说，能否用 skills 的组合与调度，替代一部分原本依赖重型编码、耗时执行的复杂研究任务？在这一想法的驱动下，随着 skills 体系逐渐成形、效果开始显现，项目便沿着这个方向持续推进，逐步系统化地构建和打磨这套以 skills 为核心的 Pipeline。其核心理念是：将研究流程显式建模为可组合的语义单元（skills with contracts），使研究任务能够像软件工程一样实现可编排、可复用、可演化、可审计。

System Design

1. skills 层面
   一开始我先入为主地把 skills 理解成 “函数”，但后来发现它更接近于一个自包含的执行单元，skill 描述的不是 “怎么调用”，而是 “在什么条件下、以什么方式完成一件事，并如何判断它是否完成”，这里推荐看 anthropic 的官方 Github 或者 doc。

• What: 输入是什么，输出是什么（显式依赖）
• How: 怎么做，有哪些边界情况（notes + procedures）
• When done: 完成标准是什么（acceptance criteria）
• What NOT to do: 边界约束（guardrails，比如 NO PROSE）

2. pipeline 层面
   在设计上对 skills 做了解耦 (不想重复造轮子了，另外改原子化组成的 Pipeline 只需增删改 skills)：不再为每一个研究任务编写一条固定流程，而是将研究过程拆解为一组原子化的 skills（如 retrieval、taxonomy、outline、evidence、writing、validation），再通过 UNITS.csv 显式描述它们的执行顺序与依赖关系。这样一来，不同类型的任务（survey、systematic review、tutorial）可以复用同一套 skills，仅通过不同的编排方式完成，流程本身不再与具体任务强绑定。
   整个流程被拆解成了 C0-C5 阶段，每一阶段有阶段性的产物（说多了都是泪，end2end 固然优雅，还是要保留中间产物便于回滚），会有隐式或者显示的规则 / 代码确保产物没有特别大的遗漏，在关键性节点引入确定性质量门（如 placeholder leakage、citation health、evidence binding 检查）用来兜底。
   同时这套 Pipeline 也可以高度个性化，个人比较倾向于设计 Pipeline 的时候让模型自己头脑风暴考虑怎么组合 skills，然后作为参考设计完整的 Pipeline，当然存在 garbage in garbage out 的风险，需要自己校正。

3. 具体实现
   配合 claude code 和 codex 开启了 self-loop 的开发（工具改变生活），抽象出一堆 skills，约束 Pipeline 渐进式执行

Usage

打开 terminal 开始指挥手下，启动 codex --sandbox workspace-write --ask-for-approval never （记得要把 sandbox 里面的 network 打开）

[sandbox_workspace_write]
network_access = true

模拟 example

你：给我写一个 agent 的 latex-survey
↓ [C0-C1] 检索 800+ 篇论文 → 去重到 150+ 核心集 arxiv 会补全 meta 信息
↓ [C2] 构建 taxonomy + outline + mapping（NO PROSE）→ 停在 C2 等审批

你：C2 同意，继续

↓ [C3-C4] 构建证据底座（paper notes + evidence packs + citations）（NO PROSE）
↓ [C5] 基于 evidence 开始写作 → 质量门检查

【如果 PASS】→ output/DRAFT.md + latex/main.pdf ✓
【如果 FAIL】→ output/QUALITY_GATE.md 告诉你改哪个中间产物

你（如果 FAIL）：按报告修复对应文件（如 outline/evidence_drafts.jsonl），然后说"继续"
→ 从失败 unit 恢复执行，不需要全部重跑

示例产物（v0.1，包含完整中间产物）全在 example 里面

该版本由 codex 中的 gpt-5.2-xhigh 运行约 2 小时 生成，过程中仅进行过 一次 human-in-the-loop（C2 阶段） 介入。
路径：example/e2e-agent-survey-latex-verify-****时间戳/（pipeline：pipelines/arxiv-survey-latex.pipeline.md）。
配置摘要：draft_profile: lite / evidence_mode: abstract / core_size: 220（详见 queries.md）。

Limitation

写作部分 self-loop 了 N 次，迭代思路是选取一些写的比较好的 survey，让 cc 或者 codex 学习下写作风格和结构，然后了解 workspace 中的实际产物分析和优秀 survey 的差距，把暴露出的问题和改进意见写到某个 md 里面，再根据改进意见头脑风暴，反向调整重构 skills 和 Pipeline

写作还是门艺术活，高度依赖审美和经验，现在这套流程离从 0 到 1 写出顶会级别的描述还是有不少距离的，另一方面，写作技巧可能很难被精确的量化，目前更多是通过将其转化为 “受约束的优化问题”，给出正反例，给出一些引导性句子，杜绝一些模型的写作怪癖 / 特殊表达，这样的方式虽然提升了下限，也不可避免会落入俗套，模板化。

Future work

当然最终目标还是希望同时提高上下限，fighting，也希望能够加入一些可解释性。

如果大家有好的建议，欢迎多多提出；趁着现在热情还没降下去，这个 repo 会持续更新，也欢迎点个 star 支持一下。

Reference

1. GitHub - anthropics/skills: Public repository for Agent Skills
2. helloagents/Codex/Skills at main · hellowind777/helloagents · GitHub
3. GitHub - renocrypt/latex-arxiv-SKILL: A .codex SKILL for issue-driven ML/AI arXiv review papers: scaffold LaTeX + verify BibTeX citations end-to-end.
4. https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview

Todo

1. 加入多 cli 协作，multi-agent design
2. 继续完善写作技巧

antigravity 也支持 skills 了，skills 逐渐成为大家的共识。随之而带的带来一个问题，每个工具的 skills 都是在自己的文件结构中去创建和 copy，而且 skills 也是可能需要优化和更新的，导致管理起来挺烦，所以想到基于主工具 claude code 来自动同步 skills 到其它各 ai 工具的想法。

opencode 自身就会加载 claude code 的 skills，所以没必要同步

Step 1

准备好 fswatch，监听 ~/.claude/skills 的变化

brew install fswatch

Step 2

准备一个 sync_skills.sh:

#!/bin/bash
fswatch -o ~/.claude/skills | while read f; do
    rsync -a --delete --exclude-from=～/.codex/skills/.exclude-list ~/.claude/skills/ ~/.codex/skills/
    rsync -a --delete --exclude-from=～/.gemini/skills/.exclude-list ~/.claude/skills/ ~/.gemini/skills/
    rsync -a --delete --exclude-from=～/.gemini/antigravity/skills/.exclude-list ~/.claude/skills/ ~/.gemini/antigravity/skills/
done

其中 --exclude-from 是为了在某些工具中想要排除一些 skills 的同步，比如有一些 skills 只能用于某个工具里，就可以创建一个.exclude-list 文件，把要排除的 skills 文件夹名丢进去，一行一个。

Step 3

如果想每次重启后自动运行，还可以创建一个 ~/Library/LaunchAgents/com.user.sync_claude_codex_skills.plist：

里面的 xxx 换成自己的

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.user.sync_claude_codex_skills</string>

    <key>ProgramArguments</key>
    <array>
        <string>/bin/bash</string>
        <string>/Users/xxx/sync_skills.sh</string>
    </array>

    <key>RunAtLoad</key>
    <true/>

    <key>KeepAlive</key>
    <true/>

    <key>StandardOutPath</key>
    <string>/tmp/sync_skills.stdout</string>

    <key>StandardErrorPath</key>
    <string>/tmp/sync_skills.stderr</string>

    <key>EnvironmentVariables</key>
    <dict>
        <key>PATH</key>
        <string>/opt/homebrew/bin:/usr/local/bin:/bin:/usr/bin</string>
    </dict>
</dict>
</plist>

然后终端执行：

launchctl load ~/Library/LaunchAgents/com.user.sync_claude_codex_skills.plist

之前一直没有体验 codex，最近空下来了，我来一个一个 cli 工具拷打一下，接入我真实的开发任务。一看这个 Codex 读写文件的原理我 TM 头的大了。他使用指令读取文件的时候，居然不携带我的 profile.ps1。网上那篇点击率贼高的文章没个用。

我系统是
Microsoft Windows 10 专业工作站版
版本 10.0.19045 内部版本 19045

powershell 版本：

PS C:\Users\Administrator> $PSVersionTable Name Value ---- ----- PSVersion 5.1.19041.5965 PSEdition Desktop PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.19041.5965 CLRVersion 4.0. WSManStackVersion 3.0 PSRemotingProtocolVersion 2.3 SerializationVersion 1.1.0.1 

原理也没什么好说的，就是 codex 调用工具的时候告诉他要用 utf8 读。

好像直接使用编辑器贴 Skill 有问题我就留下个 git 链接吧。

也不用点 Star，我很社恐…

Zxyy-mo/Get-It-Done: 没什么大道理，全是自用的 LLM 实操小技巧。记录平时用 OpenAI 和 Claude 时比较顺手的提示词、Skills、插件配置，以及一些摸索出来的 Vibe Coding 瞎搞经验

缘起是受𝕏上某个大佬的启发（忘记名字了，只能匿名感谢）：要开发给小白用的工具。

所以 Vibe-Coding 了这个帮用户快速安装 Claude Code 并管理技能包（Skills）的桌面应用程序。

工具实现没啥难度，给 L 站大佬们一些启发。

工具可以：

• 一键安装 Claude Code：自动检测环境、安装依赖、配置 npm，适配国内网络环境
• 模型配置：支持配置 API Key、自定义模型端点、选择模型提供商
• 技能管理：
  
  • 从文件夹或 ZIP 包导入技能
  • 选择安装到项目级或全局技能目录
  • 查看安装历史记录
  • 管理全局技能
    
    

Claude Code Multi-Agent

更多详细的介绍内容与文档，请详见：
Claude-Code-Multi-Agent/README.md at master · Prorise-cool/Claude-Code-Multi-Agent

如果有功能上的疑问，请在 github 上提交 PR，此项目已内置 MCP

因为是个人使用的工作流，开源出来如果有无法复现的情况请反馈给我及时优化，欢迎提交 PR，分享更多实用的 SKILLS 技能

这是什么？

Claude Code Multi-Agent 是一个为 Claude Code 设计的智能开发框架，通过 Hooks 系统 在会话生命周期中自动执行智能操作，让 Claude Code 从 “通用聊天助手” 升级为 “懂你项目的专业开发伙伴”。

核心定位

这不是一个插件生态，而是一个 Claude Code 的专属工作空间
你需要将仓库克隆后，将你的项目（或初始化项目）放在此文件夹中，即可享受智能 Hooks 定义以及 300+ Skills 方案。

解决了什么痛点？

痛点 1：Claude Code 缺乏项目感知能力

问题：Claude Code 默认不知道你的项目是什么类型、使用什么框架、有什么依赖。每次都需要你手动描述项目背景。

解决：通过 Ollama 智能引擎 自动检测项目类型（Python/Node.js/Java 等）、识别框架（Django/FastAPI/React 等），并在会话启动时自动注入项目上下文。

痛点 2：需要手动配置各种工具和提示词

问题：每次使用 Claude Code 都需要：

• 手动告诉它项目结构
• 手动配置 Git 工作流
• 手动编写提示词模板
• 手动管理文档更新

解决：零配置启动 - 克隆即用，所有配置通过 Hooks 自动完成。提示词模板化存储在 prompts.json，支持团队协作和版本控制。

痛点 3：缺乏智能的意图分析和技能推荐

问题：Claude Code 不知道什么时候该调用什么工具，也不知道有哪些可用的专家技能。

解决：智能意图分析 - 自动判断任务复杂度，推荐合适的 MCP 工具（Sequential Thinking、Task Manager 等）和 Skills（后端专家、测试专家等）。

痛点 4：文档维护繁琐且容易遗忘

问题：代码改了，文档忘了更新。项目知识散落在聊天记录中，无法沉淀。

解决：自动文档维护 - 每次代码修改后，强制提示更新 DEVELOPMENT.md、KNOWLEDGE.md、CHANGELOG.md，确保文档与代码同步。

核心优势

所有判断逻辑通过本地部署 Ollama 完成，无需编写复杂的规则引擎。提示词模板化存储在 prompts.json，支持持续调优和版本控制。

300+ Skills 专家智能体

会话启动时自动扫描并加载所有 Skills，包括：

• 后端专家 (/backend-specialist) - Django、FastAPI、Spring Boot 等
• 前端专家 (/frontend-specialist) - React、Vue、Next.js 等
• 测试专家 (/testing-specialist) - 单元测试、集成测试、E2E 测试
• 安全专家 (/security-specialist) - OWASP Top 10、安全审计
• 架构专家 (/architecture-specialist) - 系统设计、微服务架构
• DevOps 专家 (/devops-specialist) - CI/CD、容器化、云部署
• … 还有更多

自动文档维护系统

强制维护三个核心文档：

• DEVELOPMENT.md - 开发工作文档（任务状态、进度跟踪）
• KNOWLEDGE.md - 项目知识库（技术决策、代码模式）
• CHANGELOG.md - 变更日志（版本记录、功能变更）

文档在会话启动时自动注入上下文，替代 Memory MCP，避免上下文爆炸。

Git 工作流智能集成

自动检测 Git 仓库配置，提示分支策略（github-flow /git-flow），确保团队协作规范。

零配置启动

基于 uv 的依赖管理，无需手动安装 Python 包。克隆项目 → 配置环境变量 → 启动 Claude Code，即可使用。

使用示例

示例 1：自动项目检测

场景：你打开了一个新的 Python 项目，想了解项目结构。

操作：直接打开 Claude Code，系统会自动：

1. 检测项目类型（Python + FastAPI）
2. 识别框架和依赖
3. 加载相关 Skills（后端专家、测试专家等）
4. 初始化项目文档

结果：Claude Code 立即了解你的项目，无需手动介绍。

示例 2：调用专家 Skills

场景：需要设计 RESTful API，但不确定最佳实践。

操作：在 Claude Code 中输入：

/backend-specialist 设计用户认证的 RESTful API

结果：Claude Code 以 “后端专家” 身份回答，参考 FastAPI/Django 最佳实践，提供：

• RESTful 资源设计
• HTTP 方法选择
• 状态码定义
• 请求 / 响应格式

示例 3：智能意图分析

场景：输入一个复杂任务：“实现用户登录功能”

操作：系统自动分析意图，推荐：

• 推荐工具：Sequential Thinking（复杂任务分解）
• 推荐 Skills：/backend-specialist、/security-specialist
• 执行计划：自动生成任务拆解建议

结果：无需手动思考 “该用什么工具”，系统智能推荐。

示例 4：自动文档维护

场景：修改了 user_service.py，添加了新功能。

操作：系统自动检测代码变更，强制提示更新：

• DEVELOPMENT.md - 记录开发进度
• KNOWLEDGE.md - 记录技术决策
• CHANGELOG.md - 记录变更历史

结果：文档始终与代码同步，项目知识可沉淀。

示例 5：Commands 工作流

Commands 是预定义的工作流，通过 /command-name 触发：

# 创建功能规格（从需求到实施计划）
/kiro/spec 用户认证功能

# 执行完整的代理工作流
/agent-workflow 实现博客系统

# Git 提交（自动生成 Commit Message）
/gh/commit

Command 示例：/kiro/spec

这个 Command 会引导你完成：

1. 需求收集：生成 EARS 格式的需求文档
2. 设计文档：创建架构设计和数据模型
3. 任务列表：拆解为可执行的开发任务

所有文档自动保存到 .kiro/specs/{feature_name}/ 目录。

系统架构

Hooks 工作原理

本项目通过 Python Hooks 系统管理 Claude Code 的会话生命周期。每个 Hook 在特定事件触发时执行，通过 Ollama 进行智能决策。

核心设计理念：

• 文档驱动：强制维护三个核心文档（DEVELOPMENT.md、KNOWLEDGE.md、CHANGELOG.md），会话启动时自动读取并注入上下文
• 配置化提示词：所有提示词模板存储在 .claude/hooks/prompts.json，用户可自由调整和优化
• 去 Memory 中间层：不再依赖 Memory MCP，直接通过文档维护项目知识，避免上下文爆炸导致的指令失效

Hook 触发时机

Hook 执行流程

每个 Hook 通过 exit_code 控制后续操作：

返回值格式：

{ "exit_code": 0, "message": "操作成功", "data": { "skills": ["backend-specialist", "testing-specialist"], "project_type": "Python", "framework": "FastAPI" } } 

• exit_code=0：允许操作继续
• exit_code=2：阻止操作（如检测到危险命令）

Hook 类型说明

核心 Hook 详解：

1. SessionStart - 会话启动处理器

这是最重要的 Hook，负责项目初始化：

# .claude/hooks/handlers/session_start.py 的核心逻辑 # 1. 调用 Ollama 检测项目类型
project_info = ollama_client.detect_project_type()
# 返回：{"type": "Python", "framework": "FastAPI", "version": "3.11"} # 2. 扫描 skills/ 目录
skills = scan_skills_directory()
# 返回：["backend-specialist", "testing-specialist", ...] # 3. 初始化文档系统
document_manager.init_documents()
# 创建：DEVELOPMENT.md, KNOWLEDGE.md, CHANGELOG.md # 4. 【核心改进】强制读取三个文档并注入上下文
development_content = read_file("project_document/DEVELOPMENT.md")
knowledge_content = read_file("project_document/KNOWLEDGE.md")
changelog_content = read_file("project_document/CHANGELOG.md")
# 将这些内容注入到系统上下文中，替代 Memory MCP # 5. 检查 Git 配置
git_status = check_git_config()
# 检查：.gitignore, 分支策略 

2. UserPromptSubmit - 意图识别处理器

分析用户输入，提供智能建议：

# 用户输入："帮我实现用户登录功能" # Ollama 分析结果：
{
    "intent": "feature_implementation",
    "complexity": "medium",
    "recommended_tools": ["Write", "Edit", "Bash"],
    "recommended_skills": ["backend-specialist", "security-specialist"],
    "suggested_plan": [
        "1. 设计数据库表结构",
        "2. 实现认证逻辑",
        "3. 编写单元测试",
        "4. 添加安全防护"
    ]
}

3. PostToolUse - 工具使用后处理器

在每次代码修改后，强制 更新三个文档：

# 检测到修改了 user_service.py # 【强制】必须更新以下文档： # 1. DEVELOPMENT.md - 记录开发进度和任务状态 # 2. KNOWLEDGE.md - 记录技术决策和代码模式 # 3. CHANGELOG.md - 记录变更历史 # 文档更新提示通过 prompts.json 配置，用户可自定义格式和要求 

提示词配置化：
所有提示词模板存储在 .claude/hooks/prompts.json，支持：

• 自定义提示词内容和格式
• 使用 {变量} 占位符动态替换
• 按 Hook 类型分组管理
• 便于持续调优和版本控制

Skills 触发机制

Skills 是本项目的 “专家团队”，每个 Skill 代表一个专业领域的智能体。

Skills 加载流程

Skill 目录结构

.claude/skills/ ├── backend-specialist/ │ ├── SKILL.md                    # Skill 定义（必需）
│ └── references/                 # 参考文档（可选）
│ ├── cursor_rules_django.md
│ ├── cursor_rules_fastapi.md
│ └── restful_best_practices.md
├── testing-specialist/ │ ├── SKILL.md
│ └── references/ │ ├── pytest_guide.md
│ └── test_patterns.md
└── security-specialist/ ├── SKILL.md
    └── references/ ├── owasp_top10.md
        └── secure_coding.md

为什么需要 Ollama？

Ollama 是本项目的 “大脑”，负责：

• 项目类型检测：自动识别你的项目是 Python/Node.js/Java 等
• 意图分析：理解用户输入，判断是简单查询还是复杂任务
• 提示词优化：将模糊需求转化为清晰的执行计划
• 技能推荐：根据任务类型推荐合适的 Skills

没有 Ollama，系统会降级到基础模式（仅支持手动触发 Skills）。

为什么需要 uv？

uv 是 Rust 编写的超快 Python 包管理器，本项目用它来：

• 自动管理 Python 环境：无需手动创建虚拟环境
• 秒级安装依赖：比 pip 快 10-100 倍
• 零配置运行 Hooks：uv run 自动处理依赖隔离

为什么不用 pip？ uv 会自动创建隔离环境，避免污染全局 Python 环境，且速度快 10 倍以上。

相信各位佬友现在已经或多或少使用过 skills 并且创建了更好用更合适的协助式 skills，今天我以我个人这几天在简单使用中来小小的总结一下 skills 和 commands（希望各位大佬批评指正 ）

Skills 的使用：

1. skills 的基本要素：

首先 skills 分为用户级与项目级，两者的存放位置如下，仅需要把你想要下载的 skills 放在下面的目录中，cc 在每次对话开始前就会自动识别并加载用户级与项目级的 skills，并且可以用 /{skill-name} 的方式调用或者根据你的上下文内容自动调用 skills：

• 用户级：~/.claude/skills/ 用户级的 skills 全局生效，可以在任何目录中调用用户级 skills
• 项目级：<项目根目录>/.claude/skills/ 项目级 skills 仅在当前项目生效，适合针对该项目做专业的工作

skills 的一般目录结构如下，以官方的 skill-creator 中的 SKILL.md 中的内容为例

skill-name/
├── SKILL.md（必需）
│   ├── YAML frontmatter 元数据（必需）
│   │   ├── name:（必需）
│   │   └── description:（必需）
│   └── Markdown 指令（必需）
└── 捆绑资源（可选）
    ├── scripts/          # 可执行代码（Python/Bash 等）
    ├── references/       # 需要时加载到上下文的文档
    └── assets/           # 用于输出的文件（模板、图标、字体等） 

在官方的 skill-creator 中的 SKILL.md 中介绍了每个 skill 所需要的内容

• YAML frontmatter: Claude 会通过上下文中的内容匹配 description 中的应用场景来触发 skill，或者通过 /skillname {描述}l 来触发，需要简短并全面的描述整个 skill 的功能和应用场景。

  ---
  name: <skill-name>
  description: <简要说明技能功能>。当用户请求"<触发短语1>"、"<触发短语2>"、"<触发短语3>"，或涉及<相关领域/任务>时，使用此技能。  
  
  ---
  

• references/：在加载 skill 时会一并加载到上下文中来作为补充思考的参考资料，通常是执行一个 skill 中多个模式时的参考资料补充，也可以是每个模式具体的流程。

• scripts/：skill 可以包含脚本，可以变成一个主动触发的小型 MCP 服务，一些重复性或者规定格式文件生成工作可以以脚本的形式写在 skill 中，比如你可以让它读取数据库指定表并按照模板自动生成全后端的 CRUD 代码。

• assets/：静态的文件，图像、logo 等等，这个应该是写一些前端代码生成时用到的东西，目前我还没用到过。

---
name: skill-creator
description: 创建高效技能的指南。当用户想要创建新技能（或更新现有技能）以扩展 Claude 的能力时，应使用此技能，包括专业知识、工作流程或工具集成。
license: 完整条款见 LICENSE.txt

--- # 技能创建器

本技能提供创建高效技能的指导。

## 关于技能

技能是模块化、自包含的软件包，通过提供专业知识、工作流程和工具来扩展 Claude 的能力。可以将它们视为特定领域或任务的"入职指南"——它们将 Claude 从通用代理转变为配备程序性知识的专业代理，而这些知识是任何模型都无法完全具备的。

### 技能提供的内容 1. 专业工作流程 - 特定领域的多步骤程序
2. 工具集成 - 处理特定文件格式或 API 的指令
3. 领域专业知识 - 公司特定知识、数据模式、业务逻辑
4. 捆绑资源 - 用于复杂和重复任务的脚本、参考资料和资产

## 核心原则 ### 简洁至上

上下文窗口是公共资源。技能与 Claude 所需的其他所有内容共享上下文窗口：系统提示、对话历史、其他技能的元数据以及实际的用户请求。

**默认假设：Claude 已经非常智能。** 只添加 Claude 尚不具备的上下文。对每条信息提出质疑："Claude 真的需要这个解释吗？"以及"这段内容值得消耗这些 token 吗？"

优先使用简洁的示例，而非冗长的解释。

### 设置适当的自由度

根据任务的脆弱性和可变性匹配具体程度：

**高自由度（基于文本的指令）**：当多种方法都有效、决策取决于上下文或启发式方法指导方案时使用。

**中等自由度（伪代码或带参数的脚本）**：当存在首选模式、可接受一定变化或配置影响行为时使用。

**低自由度（特定脚本，少量参数）**：当操作脆弱且容易出错、一致性至关重要或必须遵循特定顺序时使用。

将 Claude 想象为探索一条路径：悬崖边的窄桥需要特定的护栏（低自由度），而开阔的田野允许多条路线（高自由度）。

### 技能的结构

每个技能由一个必需的 SKILL.md 文件和可选的捆绑资源组成：

```

skill-name/

├── SKILL.md（必需）

│   ├── YAML frontmatter 元数据（必需）

│   │   ├── name:（必需）

│   │   └── description:（必需）

│   └── Markdown 指令（必需）

└── 捆绑资源（可选）

    ├── scripts/          - 可执行代码（Python/Bash 等）

    ├── references/       - 需要时加载到上下文的文档

    └── assets/           - 用于输出的文件（模板、图标、字体等）

``` #### SKILL.md（必需）

每个 SKILL.md 包含：

- **Frontmatter**（YAML）：包含 `name` 和 `description` 字段。这是 Claude 用来判断何时使用技能的唯一字段，因此清晰全面地描述技能是什么以及何时应该使用它非常重要。
- **Body**（Markdown）：使用技能的指令和指导。仅在技能触发后加载（如果触发的话）。

#### 捆绑资源（可选） ##### 脚本（`scripts/`）

用于需要确定性可靠性或反复重写的任务的可执行代码（Python/Bash 等）。

- **何时包含**：当相同的代码被反复重写或需要确定性可靠性时
- **示例**：用于 PDF 旋转任务的 `scripts/rotate_pdf.py` - **优点**：节省 token、确定性、可以在不加载到上下文的情况下执行
- **注意**：脚本可能仍需要被 Claude 读取以进行修补或环境特定调整

##### 参考资料（`references/`）

需要时加载到上下文中以指导 Claude 流程和思考的文档和参考材料。

- **何时包含**：用于 Claude 在工作时应参考的文档
- **示例**：用于财务模式的 `references/finance.md`、用于公司保密协议模板的 `references/mnda.md`、用于公司政策的 `references/policies.md`、用于 API 规范的 `references/api_docs.md` - **用例**：数据库模式、API 文档、领域知识、公司政策、详细工作流程指南
- **优点**：保持 SKILL.md 精简，仅在 Claude 确定需要时加载
- **最佳实践**：如果文件较大（>10k 词），在 SKILL.md 中包含 grep 搜索模式
- **避免重复**：信息应该存在于 SKILL.md 或参考文件中，而不是两者都有。除非信息确实是技能的核心，否则优先将详细信息放在参考文件中——这样可以保持 SKILL.md 精简，同时使信息可发现而不占用上下文窗口。仅在 SKILL.md 中保留基本的程序性指令和工作流程指导；将详细的参考材料、模式和示例移至参考文件。

##### 资产（`assets/`）

不打算加载到上下文中，而是用于 Claude 产出的输出中的文件。

- **何时包含**：当技能需要将在最终输出中使用的文件时
- **示例**：用于品牌资产的 `assets/logo.png`、用于 PowerPoint 模板的 `assets/slides.pptx`、用于 HTML/React 样板的 `assets/frontend-template/`、用于排版的 `assets/font.ttf` - **用例**：模板、图像、图标、样板代码、字体、被复制或修改的示例文档
- **优点**：将输出资源与文档分离，使 Claude 能够使用文件而无需将其加载到上下文中

#### 技能中不应包含的内容

技能应仅包含直接支持其功能的必要文件。不要创建无关的文档或辅助文件，包括：

- README.md
- INSTALLATION_GUIDE.md

- QUICK_REFERENCE.md
- CHANGELOG.md
- 等等

技能应仅包含 AI 代理完成手头工作所需的信息。它不应包含关于创建过程的辅助上下文、设置和测试程序、面向用户的文档等。创建额外的文档文件只会增加混乱和困惑。

### 渐进式披露设计原则

技能使用三级加载系统来高效管理上下文：

1. **元数据（name + description）** - 始终在上下文中（约 100 词）
2. **SKILL.md body** - 当技能触发时（<5k 词）
3. **捆绑资源** - 根据 Claude 需要（无限制，因为脚本可以在不读入上下文窗口的情况下执行）

#### 渐进式披露模式

将 SKILL.md body 保持在必要内容且不超过 500 行，以最小化上下文膨胀。接近此限制时将内容拆分到单独的文件中。当将内容拆分到其他文件时，非常重要的是从 SKILL.md 引用它们并清楚描述何时读取它们，以确保技能的读者知道它们的存在以及何时使用它们。

**关键原则：** 当技能支持多种变体、框架或选项时，仅在 SKILL.md 中保留核心工作流程和选择指导。将特定变体的详细信息（模式、示例、配置）移至单独的参考文件。

**模式 1：带参考资料的高级指南** ```markdown

# PDF 处理



## 快速开始



使用 pdfplumber 提取文本：

[代码示例]



## 高级功能



- **表单填写**：完整指南见 [FORMS.md](FORMS.md)

- **API 参考**：所有方法见 [REFERENCE.md](REFERENCE.md)

- **示例**：常见模式见 [EXAMPLES.md](EXAMPLES.md)

```

Claude 仅在需要时加载 FORMS.md、REFERENCE.md 或 EXAMPLES.md。

**模式 2：领域特定组织**

对于具有多个领域的技能，按领域组织内容以避免加载不相关的上下文：

```

bigquery-skill/

├── SKILL.md（概述和导航）

└── reference/

    ├── finance.md（收入、计费指标）

    ├── sales.md（商机、管道）

    ├── product.md（API 使用、功能）

    └── marketing.md（营销活动、归因）

```

当用户询问销售指标时，Claude 只读取 sales.md。

类似地，对于支持多个框架或变体的技能，按变体组织：

```

cloud-deploy/

├── SKILL.md（工作流程 + 提供商选择）

└── references/

    ├── aws.md（AWS 部署模式）

    ├── gcp.md（GCP 部署模式）

    └── azure.md（Azure 部署模式）

```

当用户选择 AWS 时，Claude 只读取 aws.md。

**模式 3：条件性详情**

显示基本内容，链接到高级内容：

```markdown

# DOCX 处理



## 创建文档



使用 docx-js 创建新文档。见 [DOCX-JS.md](DOCX-JS.md)。



## 编辑文档



对于简单编辑，直接修改 XML。



**对于修订跟踪**：见 [REDLINING.md](REDLINING.md)

**对于 OOXML 详情**：见 [OOXML.md](OOXML.md)

```

Claude 仅在用户需要这些功能时读取 REDLINING.md 或 OOXML.md。

**重要指南：** - **避免深层嵌套引用** - 保持引用从 SKILL.md 只有一层深度。所有参考文件应直接从 SKILL.md 链接。
- **结构化较长的参考文件** - 对于超过 100 行的文件，在顶部包含目录，以便 Claude 在预览时可以看到完整范围。

## 技能创建流程

技能创建包括以下步骤：

1. 通过具体示例理解技能
2. 规划可复用的技能内容（脚本、参考资料、资产）
3. 初始化技能（运行 init_skill.py）

4. 编辑技能（实现资源并编写 SKILL.md）

5. 打包技能（运行 package_skill.py）
6. 基于实际使用进行迭代

按顺序执行这些步骤，仅在有明确理由说明不适用时才跳过。

### 步骤 1：通过具体示例理解技能

仅当技能的使用模式已经清楚理解时才跳过此步骤。即使在处理现有技能时，此步骤仍然有价值。

要创建有效的技能，需要清楚理解技能将如何使用的具体示例。这种理解可以来自直接的用户示例或经过用户反馈验证的生成示例。

例如，在构建图像编辑器技能时，相关问题包括：

- "图像编辑器技能应该支持什么功能？编辑、旋转，还有其他吗？"
- "你能给出一些这个技能将如何使用的示例吗？"
- "我可以想象用户会要求'去除这张图片的红眼'或'旋转这张图片'。你还能想象这个技能的其他使用方式吗？"
- "用户说什么应该触发这个技能？"

为避免让用户不知所措，避免在单条消息中问太多问题。从最重要的问题开始，根据需要跟进以获得更好的效果。

当对技能应支持的功能有清晰认识时，结束此步骤。

### 步骤 2：规划可复用的技能内容

要将具体示例转化为有效的技能，通过以下方式分析每个示例：

1. 考虑如何从头开始执行示例
2. 识别在反复执行这些工作流程时哪些脚本、参考资料和资产会有帮助

示例：在构建 `pdf-editor` 技能以处理"帮我旋转这个 PDF"等查询时，分析显示：

1. 旋转 PDF 每次都需要重写相同的代码
2. 在技能中存储 `scripts/rotate_pdf.py` 脚本会有帮助

示例：在设计 `frontend-webapp-builder` 技能以处理"给我构建一个待办事项应用"或"给我构建一个跟踪步数的仪表板"等查询时，分析显示：

1. 编写前端 webapp 每次都需要相同的 HTML/React 样板
2. 在技能中存储包含样板 HTML/React 项目文件的 `assets/hello-world/` 模板会有帮助

示例：在构建 `big-query` 技能以处理"今天有多少用户登录？"等查询时，分析显示：

1. 查询 BigQuery 每次都需要重新发现表模式和关系
2. 在技能中存储记录表模式的 `references/schema.md` 文件会有帮助

要确定技能的内容，分析每个具体示例以创建要包含的可复用资源列表：脚本、参考资料和资产。

### 步骤 3：初始化技能

此时，是时候实际创建技能了。

仅当正在开发的技能已经存在且需要迭代或打包时才跳过此步骤。在这种情况下，继续下一步。

从头创建新技能时，始终运行 `init_skill.py` 脚本。该脚本方便地生成一个新的模板技能目录，自动包含技能所需的一切，使技能创建过程更加高效和可靠。

用法：

```bash

scripts/init_skill.py <skill-name> --path <output-directory>

```

该脚本：

- 在指定路径创建技能目录
- 生成带有正确 frontmatter 和 TODO 占位符的 SKILL.md 模板
- 创建示例资源目录：`scripts/`、`references/` 和 `assets/` - 在每个目录中添加可以自定义或删除的示例文件

初始化后，根据需要自定义或删除生成的 SKILL.md 和示例文件。

### 步骤 4：编辑技能

在编辑（新生成或现有的）技能时，请记住技能是为另一个 Claude 实例使用而创建的。包含对 Claude 有益且非显而易见的信息。考虑什么程序性知识、领域特定细节或可复用资产将帮助另一个 Claude 实例更有效地执行这些任务。

#### 学习经过验证的设计模式

根据技能需求查阅这些有用的指南：

- **多步骤流程**：见 references/workflows.md 了解顺序工作流程和条件逻辑
- **特定输出格式或质量标准**：见 references/output-patterns.md 了解模板和示例模式

这些文件包含有效技能设计的既定最佳实践。

#### 从可复用技能内容开始

要开始实现，从上面确定的可复用资源开始：`scripts/`、`references/` 和 `assets/` 文件。请注意，此步骤可能需要用户输入。例如，在实现 `brand-guidelines` 技能时，用户可能需要提供品牌资产或模板存储在 `assets/` 中，或文档存储在 `references/` 中。

添加的脚本必须通过实际运行来测试，以确保没有错误且输出符合预期。如果有许多类似的脚本，只需测试具有代表性的样本，以确保它们都能工作，同时平衡完成时间。

任何技能不需要的示例文件和目录都应删除。初始化脚本在 `scripts/`、`references/` 和 `assets/` 中创建示例文件以演示结构，但大多数技能不需要所有这些。

#### 更新 SKILL.md **写作指南：** 始终使用祈使句/不定式形式。

##### Frontmatter

编写包含 `name` 和 `description` 的 YAML frontmatter：

- `name`：技能名称
- `description`：这是技能的主要触发机制，帮助 Claude 理解何时使用该技能。
- 包括技能做什么以及何时使用它的具体触发器/上下文。
- 将所有"何时使用"信息放在这里 - 不要放在 body 中。body 仅在触发后加载，因此 body 中的"何时使用此技能"部分对 Claude 没有帮助。
- `docx` 技能的示例描述："全面的文档创建、编辑和分析，支持修订跟踪、批注、格式保留和文本提取。当 Claude 需要处理专业文档（.docx 文件）时使用，用于：(1) 创建新文档，(2) 修改或编辑内容，(3) 处理修订跟踪，(4) 添加批注，或任何其他文档任务"

不要在 YAML frontmatter 中包含任何其他字段。

##### Body

编写使用技能及其捆绑资源的指令。

### 步骤 5：打包技能

技能开发完成后，必须将其打包成可分发的 .skill 文件与用户共享。打包过程会自动先验证技能以确保它满足所有要求：

```bash

scripts/package_skill.py <path/to/skill-folder>

```

可选的输出目录指定：

```bash

scripts/package_skill.py <path/to/skill-folder> ./dist

```

打包脚本将：

1. **自动验证**技能，检查：

- YAML frontmatter 格式和必需字段
- 技能命名约定和目录结构
- 描述的完整性和质量
- 文件组织和资源引用

2. 如果验证通过则**打包**技能，创建以技能命名的 .skill 文件（例如 `my-skill.skill`），包含所有文件并保持正确的目录结构以供分发。.skill 文件是带有 .skill 扩展名的 zip 文件。

如果验证失败，脚本将报告错误并退出而不创建包。修复任何验证错误并再次运行打包命令。

### 步骤 6：迭代

测试技能后，用户可能会要求改进。这通常发生在使用技能后不久，对技能表现有新鲜的上下文。

**迭代工作流程：** 1. 在实际任务中使用技能
2. 注意困难或低效之处
3. 确定应如何更新 SKILL.md 或捆绑资源
4. 实施更改并再次测试

2. skill 的下载与快速创建

你可以在各类网站上找到你相中的 skills，然后直接把他们下载下来放在你的用户级或者项目集的 skills/ 目录中就可以了，你也可以直接用 cc-switch 来下载用户级的 skills

CC-Switch 下载 skills

快速创建：

首先安装官方的 skill-creator，这里需要注意的是 windows 的 cli 中默认编码是 GBK，所以可能会遇见脚本执行编码错误的情况，直接让 cc 帮你修复，也可以直接下载这个修复后的 skill

skill-creator.zip

安装好 skill-creator 后一定要重启 cc 让它加载好这个 skill，然后直接 /skill-creator 帮我创建一个项目级的{什么什么功能}的skill 然后 cc 就一顿操作猛如虎给你建好了，肯定少不了一顿改来改去的，所以一般都是拿现成的过来用。

创建好后的 skills 在正确加载后执行 /skills 命令是会显示的:

甚至还有一个 mcp-builder 可以帮你创建 mcp 服务，我就拿他创建了一个可以连接 mysql 的 mcp，还是挺方便的，总之我觉得 skills 可以理解为各种各样的插件，你缺什么功能了你就拿过来，还是挺有趣的。

Commands 的使用

1. commands 的基本介绍

commands 可以理解为纯提示词版的 skills（貌似 cc 加载的时候也会把自定义的 commands 当作 skills 加载？调用 /skills 可以看到创建的 skills 和 commands）一般内容都是些工作流程的约束，比如项目分析、解释代码、审查代码等简单工作流程，也分为用户级与项目级，但是 cc 不会根据上下文来自动调用，而是需要手动调用 /{command-name} 阿巴阿巴

• 用户级：~/.claude/commands/ 全局生效
• 项目级：<项目根目录>/.claude/commands/

commands 的目录结构（支持命名空间）：

.claude/commands/
├── code/
│   ├── explain-code.md       # /code:explain-code
│   └── review-code.md       # /code:review-code
└── analysis/
    └── analyze-project.md      # /analysis:analyze-project 

正确加载后的样子

在 commands 中同样也会要求规定 YAML frontmatter

--- description: "分析项目结构和技术栈" allowed-tools: ["read", "grep", "bash", "glob"]
model: sonnet ---

• description：命令描述。

• allowed-tools：允许调用的工具。

• model：指定的模型。

2. commands 的快速创建

commands 的创建目前好像没有相应的 skills 支持（也可以使用 skill-creator 来创建一个 commands-builder ），但我们依然可以拜托万能 cc 帮我们创建，他自己知道 commands 的规则，直接让它创建一个项目级的分析代码commands 即可。

貌似也可以在 commands 的工作流程中让其调用多个 skills 和 mcp 协作，实现一个完整的大型工作流程，这个我目前没试过，现在日常的代码工作应该够用了。

以上就是我对于 skills 和 commands 的简单总结啦 ，大家快来鞭策我

应该也有人注意到，skills 和 commands 文件夹中的定义都会被追加到 / 命令列表中。将两者拆分开来的目的，就是为了在结构上保持清晰，便于后续维护与扩展。

说到这里，我也顺便附上一个具体示例

commands 文件夹下的

检测到复杂场景
    ← 调用 sequential-thinking (nextThoughtNeeded=true)
    ← 分析工具返回的思考内容
    ← 判断：是否需要继续推理？
    ← 是  → 调用 sequential-thinking (thoughtNumber+1)
    ← 循环直到 nextThoughtNeeded=false
    ← 输出最终结论

thought: "开始分析：[用户问题]..." thoughtNumber: 1 totalThoughts: [初始估计，可动态调整]
nextThoughtNeeded: true 

# 调用 1/5 thought: "分析目标：评估 API 设计的合理性和潜在问题..." nextThoughtNeeded: true # 调用 2/5 thought: "维度1：接口语义 - 检查 RESTful 规范..." nextThoughtNeeded: true # 调用 3/5 thought: "维度2：安全 - 认证/授权/输入校验..." nextThoughtNeeded: true # 调用 4/5 thought: "维度3：性能 - 分页/缓存/查询优化..." nextThoughtNeeded: true # 调用 5/5 thought: "综合结论：发现 3 个问题（无分页、缺少限流、返回字段冗余），修复建议..." nextThoughtNeeded: false # 输出最终结论给用户 

Thought 1/8: 明确业务需求的核心约束... Thought 2/8: 识别关键模块与依赖关系... Thought 3/8: 评估技术栈选型的优劣势... Thought 4/8: [分支] 探索方案 A：单体架构 Thought 5/8: [分支] 探索方案 B：微服务架构 Thought 6/8: 对比两种方案的可扩展性... Thought 7/8: 验证方案选择的安全性... Thought 8/8: 综合结论：推荐方案及实施步骤 

Thought 1/6: 复现问题并收集症状... Thought 2/6: 假设生成：可能是数据库查询慢... Thought 3/6: 验证假设：检查查询日志... Thought 4/6: [修正] 假设不成立，转向网络层面... Thought 5/6: 发现根本原因：N+1 查询... Thought 6/6: 设计修复方案... 

skills 文件夹下的 code-think 模块的

检测到复杂场景
    ↓
调用 sequential-thinking (nextThoughtNeeded=true)
    ↓
分析工具返回的思考内容
    ↓
判断：是否需要继续推理？
    ↓ 是
    ↓
调用 sequential-thinking (thoughtNumber+1)
    ↓
循环直到 nextThoughtNeeded=false
    ↓
输出最终结论

thought: "开始分析：[用户问题]..." thoughtNumber: 1 totalThoughts: [初始估计，可动态调整]
nextThoughtNeeded: true 

# 调用 1/5 thought: "分析目标：评估 API 设计的合理性和潜在问题..." nextThoughtNeeded: true # 调用 2/5 thought: "维度1：接口语义 - 检查 RESTful 规范..." nextThoughtNeeded: true # 调用 3/5 thought: "维度2：安全性 - 认证/授权/输入验证..." nextThoughtNeeded: true # 调用 4/5 thought: "维度3：性能 - 分页/缓存/查询优化..." nextThoughtNeeded: true # 调用 5/5 thought: "综合结论：发现3个问题（无分页、缺少限流、返回字段冗余），修复建议..." nextThoughtNeeded: false # 输出最终结论给用户 

Thought 1/8: 明确业务需求的核心约束... Thought 2/8: 识别关键模块与依赖关系... Thought 3/8: 评估技术栈选型的优劣势... Thought 4/8: [分支] 探索方案A：单体架构 Thought 5/8: [分支] 探索方案B：微服务架构 Thought 6/8: 对比两种方案的可扩展性... Thought 7/8: 验证方案选择的安全性... Thought 8/8: 综合结论：推荐方案及实施步骤 

Thought 1/6: 复现问题并收集症状... Thought 2/6: 假设生成：可能是数据库查询慢... Thought 3/6: 验证假设：检查查询日志... Thought 4/6: [修正] 假设不成立，转向网络层面... Thought 5/6: 发现根本原因：N+1 查询... Thought 6/6: 设计修复方案... 

他俩实际上作用都是同一个 只是为了举例说明开头说的 这是定义了一套规范 便于维护
如果要使用当前的 任选其中一个也行

claude.zip

说到最后

• 至少对于我是有一定可用性的 (使用它们能大大降低全局 token 的消耗 毕竟可以按需使用嘛
• 至于 commands 通常只负责一个明确的动作，而 skills 则能包含更复杂、可复用的功能

距离 Anthropic 发布 Skills 也过去将近两个月的时间了，其中 Anthropic 提到了一个术语渐进式披露 (Progressive Disclosure)，这到底是什么东西？解决了什么问题？

其实在我的 Vibe Coding 流程中，我很少使用 MCP。因为我觉得 MCP 实现质量层次不齐，本质是上下文注入 (工具的本质也是上下文注入)，我不确定别人写的提示词会不会影响到我的工作流，干脆直接不用。现在的 MCP 实现基本上就是把所有的功能全都包装成工具暴露给 Agent (一个功能包装成一个工具，给定详细的描述，告诉 agent 在什么时候进行调用，参数格式是什么)，这就导致了现在的提示词爆炸。

直到 Anthropic 发布了 Skills，研究了一下发现本质仍然是提示词注入。如果说 MCP 是提供了一套注入工具的规范，那么 Skills 所提倡的则是 “离经叛道”。Skills 给了一个 Markdown 文档用于描述该 skill 的用途和最佳用法，附带提供了一些脚本 (与 MCP 不同)。

由于这些脚本直接在用户本地运行，存在极大的安全风险。如果用户不能对脚本代码进行 review，很容易造成数据泄露、感染病毒等严重安全性问题。相比于 MCP 提供一个标准化的接口，Skill 提供一系列的脚本文件，不同的 skill 可能拥有不同类型的脚本文件，比如有些脚本使用 node.js 实现，有些脚本使用 Python 实现，要使用这些脚本还需要用户安装对应的运行时和脚本所需要的依赖。这也是我说 “离经叛道” 的原因所在。

这真的是最佳实践吗？

关于渐进式披露，Anthropic 是这样描述的：

渐进式披露是使代理技能灵活且可扩展的核心设计原则。就像一本组织良好的手册，从目录开始，然后是具体章节，最后是详细的附录一样，技能允许 Claude 仅在需要时加载信息：

拥有文件系统和代码执行工具的智能体在执行特定任务时，无需将技能的全部内容读取到上下文窗口中。这意味着技能中可以包含的上下文信息量实际上是无限的。

下图是使用 Skill 的上下文窗口变化

我们真的需要这样去实现吗？

在我们平时使用 CLI 工具时，一般的 CLI 工具都会带有一个 --help 参数，用于查看该工具的用法和说明，这不就是该工具的使用手册吗？比如：

>npm --help
npm <command>

Usage:

npm install        install all the dependencies in your project
npm install <foo>  add the <foo> dependency to your project
npm test           run this project's tests
npm run <foo>      run the script named <foo>
npm <command> -h   quick help on <command>
npm -l             display usage info for all commands
npm help <term>    search for help on <term>
npm help npm       more involved overview

All commands:

    access, adduser, audit, bugs, cache, ci, completion,
    config, dedupe, deprecate, diff, dist-tag, docs, doctor,
    edit, exec, explain, explore, find-dupes, fund, get, help,
    help-search, hook, init, install, install-ci-test,
    install-test, link, ll, login, logout, ls, org, outdated,
    owner, pack, ping, pkg, prefix, profile, prune, publish,
    query, rebuild, repo, restart, root, run-script, sbom,
    search, set, shrinkwrap, star, stars, start, stop, team,
    test, token, uninstall, unpublish, unstar, update, version,
    view, whoami

Specify configs in the ini-formatted file:
    /Users/xxx/.npmrc
or on the command line via: npm <command> --key=value

More configuration info: npm help config
Configuration fields: npm help 7 config

这份手册也不会返回所有的命令所有的用法，它只会返回它有哪些命令可以实现什么功能，对于命令的具体用法你仍然可以通过 --help 参数获得：

>npm install --help
Install a package

Usage:
npm install [<package-spec> ...]

Options:
[-S|--save|--no-save|--save-prod|--save-dev|--save-optional|--save-peer|--save-bundle]
[-E|--save-exact] [-g|--global]
[--install-strategy <hoisted|nested|shallow|linked>] [--legacy-bundling]
[--global-style] [--omit <dev|optional|peer> [--omit <dev|optional|peer> ...]]
[--include <prod|dev|optional|peer> [--include <prod|dev|optional|peer> ...]]
[--strict-peer-deps] [--prefer-dedupe] [--no-package-lock] [--package-lock-only]
[--foreground-scripts] [--ignore-scripts] [--no-audit] [--no-bin-links]
[--no-fund] [--dry-run] [--cpu <cpu>] [--os <os>] [--libc <libc>]
[-w|--workspace <workspace-name> [-w|--workspace <workspace-name> ...]]
[-ws|--workspaces] [--include-workspace-root] [--install-links]

aliases: add, i, in, ins, inst, insta, instal, isnt, isnta, isntal, isntall

Run "npm help install" for more info

这是不是很像上面的渐进式披露的定义？

我们是不是可以按照这种风格去实现一个 MCP 来实现无需 skill 的工具渐进式披露？我使用 Codex 将官方的 PDF Skill 转换成了一个 MCP，只暴露一个工具：

{ "name": "mcp__pdf__pdf", "description": "Comprehensive PDF manipulation toolkit for extracting text and tables, creating new PDFs, merging/splitting documents, and handling forms. When Claude needs to fill in a PDF form or programmatically process, generate, or analyze PDF documents at scale.You need to pass in the --help parameter to obtain the usage of this tool first.", "input_schema": { "type": "object", "properties": { "params": { "$ref": "#/$defs/PdfCommandInput" } }, "required": [ "params" ], "$defs": { "PdfCommandInput": { "additionalProperties": false, "properties": { "argv": { "description": "Command tokens excluding the leading 'pdf' executable name", "items": { "type": "string" }, "title": "Argv", "type": "array" }, "command": { "anyOf": [ { "type": "string" }, { "type": "null" } ], "default": null, "description": "Optional command string; if set, it will be split like a shell", "title": "Command" } }, "title": "PdfCommandInput", "type": "object" } }, "title": "pdfArguments" } } 

下面是使用该 MCP 的上下文窗口变化

User: Extract all the text from test.pdf and write it into result.txt
Agent: Tool(name="pdf", args=["--help"])
Tool: pdf - Comprehensive PDF manipulation toolkit for extracting text and tables, creating new PDFs, merging/splitting documents, and handling forms. When Claude needs to fill in a PDF form or programmatically process, generate, or analyze PDF documents at scale在使用之前你需要先传入--help参数以获取该工具的用法\n\nUsage:\n  pdf [--help] <domain> <command> [options]\n\nDomains:\n  forms      Fill, extract, and validate PDF form fields.\n  documents  Create, merge, and split PDFs.\n  text       Extract text content from PDFs.\n  tables     Extract tables (heuristic, whitespace-based).\n  images     Render PDF pages to PNG images.\n\nRun `pdf <domain> --help` for domain help.\nRun `pdf <domain> <command> --help` for command help.
Agent: Tool(name="pdf", args=["text", "--help"])
Tool: text - Extract text content from PDFs.\n\nUsage:\n  pdf text <command> [options]\n\nCommands:\n  extract  Extract text content from a PDF.\n\nRun `pdf text <command> --help` for details.
Agent: Tool(name="pdf", args=["text", "extract", "--help"])
Tool: usage: pdf text extract --pdf PDF_PATH [--pages PAGES] [--out OUTPUT_PATH]\n                        [--format {text,json}] [--overwrite]\n\nExtract text content from a PDF.\n\noptions:\n  --pdf PDF_PATH        Input PDF\n  --pages PAGES         Page selection like 1,3-5 or 'all' (default: all)\n  --out OUTPUT_PATH     Write extracted text to a file\n  --format {text,json}  Output format (default: text)\n  --overwrite           Overwrite output file if it exists\n
Agent: Tool(name="pdf", args=["text", "extract", "--pdf", "test.pdf", "--out", "result.txt", "--overwrite"])
Tool: {"result": {"stdout": "xx","data": {"pdf_path": "test.pdf","page_count": 6,"pages": [xxx],"format": "text","output_path": "result.txt"}}}
Agent: xxx

从上下文变化情况来看，完全实现了渐进式披露，该 MCP 代码开源 (代码完全由 codex 编写，只验证想法，未做任何审查): GitHub - musistudio/pdf-skill-mcp: pdf-skill-mcp

如果你有什么想法也欢迎与我进行交流

昨晚心血来潮，阅读了一下 skills 的更多细节内容，发现 Anthropic 给出的 skills 存在这些问题：

• 只能传入文本，无法动态的决定传入的 tools 工具
• skill 在被 ai 调用后，其内容部分会持久的记录在上下文里
• mcp 和 skills 是割裂的两个系统，Anthropic 没有给出直接的转换或者兼容工具
• skills 工具本身没有强制判断参数是否可用

追其根本，是因为 Anthropic 在 claude code 实现 skills 时是下面这样实现的

• 首先定义了一个 skills 工具，然后你定义的 skills 描述会作为 skills 外层的工具整体描述传入进去
• 没有给 skills 工具的获取 skill 内容参数传入定义的 skills 的名称作为 enum 可选项，这导致 ai 输出 skills 工具时，可能会传入不存在的参数
• skills 文件结构里，虽然定义了一个 allowed_tools 参数，但是 Anthropic 在实现时有点问题，他这里指的是该 skills 可以用的工具，但是是在现有的 tools 基础上的，而且只是作为一个提示词提示 ai，类似于：你可以使用 xxx 工具。而不是说会动态的根据该 skills 注册新工具
• ai 要阅读某个 skills 时，会调用 skills 工具，然后 cc 会把这个 skills 内容作为工具结果发给 ai，然后后续即便该任务完成了，这个 skills 的内容也不会从上下文里删除。这会导致：如果 ai 使用了多个 skills，会导致这些 skills 的内容同时影响着 ai，即便你不需要某个 skills。而一个 skills 往往又有几百行内容，很吃 ai 的注意力和上下文

那么我们该怎么优化上述系统呢，其实只需要使用动态系统提示词 + 动态 tools 列表即可
具体工作机制如下：

• 首先在系统提示词里专门划开两个部分，其中一个是各种 skills 的描述，另一个是某某 skills 的内容部分，这两个实际上可以合并到一个里面，或者分开也行。描述总是会加到系统提示词里，内容会根据 ai 需要动态加载
• 各种 skills 的描述放在系统提示词里，而不再放在 skills 工具定义描述里
• ai 使用 skills 工具获取描述时，历史上下文里只会记录：你调用了 xxx skills。然后应用此时会把该 skills 的内容加到系统提示词里的内容部分
• 后续对话就会是 ai 已经掌握了该 skills 的内容前提下进行，如果 ai 需要，可以继续阅读更多的 skills
• 当 ai 认为某个任务结束后，可以主动调用 skills 工具，关闭该 skills，这样一个 skills 的完整生命周期就完成了
• 用户当然可以主动手动关闭或者添加某个 skills，因为 skills 是直接写入系统提示词里的，会很方便配置

mcp 工具在 skills 的前提下，也会变成动态的，而不再是固定：

• 如果某个 skills 绑定了 mcp 工具（同样通过 allowed_tools），那么该工具不会被直接添加到调用 api 时的 tools 参数里
• 当 ai 决定读取某个 skills，而该 skills 又定义了某些 tools，应用应该先检查是否已经注册了这些工具，会在 tools 参数里加上没有启用的 mcp 工具，采取合并的策略，动态的维护一个 tools 列表
• 当 ai 决定不再需要某个 skills 时，也会动态的根据配置项来关闭这些工具，不再添加到 tools 列表里发给 ai，具体是这样的：如果该工具不再固定工具里，且不在任何一个启用的 skills 里，那么就注销，采用一种最最小的减法
• 用户当然依旧可以自己维护一个固定的工具列表，以便让 ai 总能使用到某些工具，比如常用的 bash，read 等工具

感觉上面这些方式才会是我想象的 skills 升级版 + mcp 的结合方式
目前 skills 更像是给一堆文档添加了一个文字摘要库，ai 需要时就阅读文档，而不是说根据需求动态的维护自身 skills

话说这种方式应该很早就有人想到了才对，也没见有火起来，反而是更次一级的 skills 火了。。。

后续我会给我自己的插件加上上面的功能试试水
话说目前有什么 ide 或者插件已经实现了这些功能的吗？

文章是自己查官网，然后与 AI 对话校验自己理解的正确性，然后自己总结的，为啥被举报说 AIGC 未截图？这也能被举报？？？？？

Commands

斜杠命令，需要用户自己主动触发；本质是把重复的提示词存储起来，直接通过命令调用提示词。

使用方法： 用户可以通过在项目的 .claude/commands/ 目录下创建 Markdown 文件 (.md) 来定义自定义命令。

• 文件名：决定命令的触发词（例如 analyze.md 对应 /analyze）。

• 文件内容：包含你希望 Claude 执行的具体 Prompt（提示词）。

• 参数：支持使用 $1, $2 或 $ARGUMENTS 接收用户输入。

官方 / 社区示例：/security-review 这是一个常见的自定义命令，用于让 Claude 按特定标准审查代码安全。

文件路径：~/.claude/commands/security-review.md (全局命令) 或 .claude/commands/security-review.md (项目命令)

文件内容示例：

--- description: Review the current code for security vulnerabilities --- Please review the code in the current context for security vulnerabilities. Focus specifically on: 1. SQL injection risks 2. XSS vulnerabilities 3. Hardcoded secrets If you find issues, please suggest specific fixes. 

如何使用：在终端输入 /security-review

Agents

Agent 本质上是拥有独立上下文和特定系统提示词（System Prompt） 的 Claude 实例

减小主流程上下文的占用，子代理上下文隔离，可以更好的聚焦任务；

使用方法： 你可以通过 CLI 交互式创建，或者通过配置文件定义。Agent 本质上是拥有独立上下文和特定系统提示词（System Prompt） 的 Claude 实例。

• 交互式创建：在 Claude Code 中输入 /agents，然后选择 “Create new agent”。

• 配置定义：通常定义在配置文件中，指定其 role（角色）、description（描述）和 tools（可用工具）。

官方示例：Code Reviewer (代码审查员) 这是官方文档中常用来演示如何通过子代理分担任务的例子。

配置逻辑（概念性描述）：

• 名称：code-reviewer

• 角色描述：你是一位资深的代码审查专家，通过严格的标准审查代码变更。你只关注代码质量、可读性和潜在 bug，不要直接写代码，只提供建议。

• 工具权限：限制为 Read（只读）权限，防止它意外修改代码。

如何使用： 在对话中，主 Agent 可能会根据任务自动调用它，或者你可以显式指派任务（如果配置允许）。

“Please ask the code-reviewer to check my latest changes.”

Skills

按需加载，只有需要该技能的时候才会加载文件内容。

都可以对业务及开发流程进行规范

使用方法： Skill 是赋予 Claude 新能力的 “知识包”，通常由一个 SKILL.md 文件和相关的脚本 / 文档组成。

• 核心文件：SKILL.md。

• 原理：Claude 启动时会加载 Skill 的元数据（Metadata）。只有当它判断当前任务需要该技能时（例如用户要求 “处理 PDF”），它才会读取 SKILL.md 的完整内容并执行其中的步骤。

官方示例：PDF Processing Skill (PDF 处理技能) 这是 Anthropic 工程博客中介绍的一个经典案例，教 Claude 如何读取 PDF 表单。

目录结构示例：

skills/pdf-skill/
├── SKILL.md          # 告诉 Claude 如何使用这个技能
├── extract.py        # 实际执行提取工作的 Python 脚本
└── README.md

SKILL.md 内容摘要：

“When the user asks to extract data from a PDF, run the extract.py script provided in this directory. Do not try to read the PDF raw bytes directly. Interpret the JSON output from the script.”

如何使用：用户无需显式调用。只需说 “Read the contract.pdf and tell me the date”，Claude 会自动激活 PDF Skill。

Plugins

Plugin 是上述所有内容（Commands, Agents, Skills）的分发容器。

接下来说一下比较容易混淆的地方，commands，agents，skills 确实有功能重叠的地方，但是他们的侧重点是不一样的，只有明白了他们各自的侧重点之后才能更好的决定使用哪一个。

1. 最大的重叠区：Command vs. Skill

这是最容易混淆的一对。它们都可以用来封装一段 Prompt 或脚本。

• 重叠点：它们本质上都是 “预定义的指令 / 脚本”。

• 核心区别：谁掌握 “扳机”？

  • Command (命令) 是显式的。你（用户） 是控制者。你必须输入 /review，Claude 才会去审查。

  • Skill (技能) 是隐式的。Claude (模型) 是控制者。你只需要说 “帮我看看这代码咋样”，Claude 会自己判断：“哦，用户需要审查代码，我应该调用 CodeReviewSkill。”

例子：

如果你写了一个 Python 脚本 format_code.py。

• 做成 Command (/fmt)：你每次必须手动输入 /fmt 才能运行它。

• 做成 Skill：当你对 Claude 说 “这代码太乱了” 时，Claude 会自动运行这个脚本。

2. 逻辑重叠区：Agent vs. Skill

这两者都涉及 “特定领域的专业能力”。

• 重叠点：都能让 Claude 变得更专业（例如都懂 SQL）。

• 核心区别：上下文是不是独立的？

  • Skill (技能) 是工具。它在当前对话中被加载。它就像给了当前的 Claude 一本《SQL 手册》，它现学现卖，但还是同一个 Claude 在跟你说话，上下文是混在一起的。

  • Agent (代理) 是分身。它拥有独立的上下文。当你调用 Agent 时，就像是 Claude 把任务转包给了坐在旁边的 “数据库专家”。这个专家有自己的记忆和设定，处理完后只把结果告诉主 Claude，避免了主对话窗口被大量的中间步骤污染。

3. Plugin (插件) 的特殊地位

Plugin 没有任何功能上的重叠，因为它不是功能本身，而是包装盒。

• 你不能把 Plugin 和 Command 并列比较。

• Plugin 包含 Command、Skill 和 Agent。

• 就好比：Command 是苹果，Agent 是橙子，而 Plugin 是水果篮。

一个场景看懂所有区别

假设你想实现一个功能：“将代码翻译成中文文档”。你可以通过三种方式实现，侧重点不同：

总结：我该选哪个？

如果你在尝试扩展 Claude Code，可以用这个简单的决策树：

1. 这个功能需要用户手动且精确地触发吗？

   • 是 \rightarrow$\to$ Command (/foo)

   • 否 \rightarrow$\to$ 下一步

2. 这个任务是否非常复杂，需要大量步骤，且容易污染当前的聊天记录？

   • 是 \rightarrow$\to$ Agent (独立的子脑)

   • 否 \rightarrow$\to$ Skill (教会当前大脑新知识)

3. 你想把这些功能打包发给同事用吗？

   • 是 \rightarrow$\to$ 把做好的 Command/Agent/Skill 放到一个文件夹里，做成 Plugin。

如果内容有误，欢迎指出

Commands

斜杠命令，需要用户自己主动触发；本质是把重复的提示词存储起来，直接通过命令调用提示词。

使用方法： 用户可以通过在项目的 .claude/commands/ 目录下创建 Markdown 文件 (.md) 来定义自定义命令。

• 文件名：决定命令的触发词（例如 analyze.md 对应 /analyze）。

• 文件内容：包含你希望 Claude 执行的具体 Prompt（提示词）。

• 参数：支持使用 $1, $2 或 $ARGUMENTS 接收用户输入。

官方 / 社区示例：/security-review 这是一个常见的自定义命令，用于让 Claude 按特定标准审查代码安全。

文件路径：~/.claude/commands/security-review.md (全局命令) 或 .claude/commands/security-review.md (项目命令)

文件内容示例：

--- description: Review the current code for security vulnerabilities --- Please review the code in the current context for security vulnerabilities. Focus specifically on: 1. SQL injection risks 2. XSS vulnerabilities 3. Hardcoded secrets If you find issues, please suggest specific fixes. 

如何使用：在终端输入 /security-review

Agents

Agent 本质上是拥有独立上下文和特定系统提示词（System Prompt） 的 Claude 实例

减小主流程上下文的占用，子代理上下文隔离，可以更好的聚焦任务；

使用方法： 你可以通过 CLI 交互式创建，或者通过配置文件定义。Agent 本质上是拥有独立上下文和特定系统提示词（System Prompt） 的 Claude 实例。

• 交互式创建：在 Claude Code 中输入 /agents，然后选择 “Create new agent”。

• 配置定义：通常定义在配置文件中，指定其 role（角色）、description（描述）和 tools（可用工具）。

官方示例：Code Reviewer (代码审查员) 这是官方文档中常用来演示如何通过子代理分担任务的例子。

配置逻辑（概念性描述）：

• 名称：code-reviewer

• 角色描述：你是一位资深的代码审查专家，通过严格的标准审查代码变更。你只关注代码质量、可读性和潜在 bug，不要直接写代码，只提供建议。

• 工具权限：限制为 Read（只读）权限，防止它意外修改代码。

如何使用： 在对话中，主 Agent 可能会根据任务自动调用它，或者你可以显式指派任务（如果配置允许）。

“Please ask the code-reviewer to check my latest changes.”

Skills

按需加载，只有需要该技能的时候才会加载文件内容。

可以对业务知识及开发流程进行规范

使用方法： Skill 是赋予 Claude 新能力的 “知识包”，通常由一个 SKILL.md 文件和相关的脚本 / 文档组成。

• 核心文件：SKILL.md。

• 原理：Claude 启动时会加载 Skill 的元数据（Metadata）。只有当它判断当前任务需要该技能时（例如用户要求 “处理 PDF”），它才会读取 SKILL.md 的完整内容并执行其中的步骤。

官方示例：PDF Processing Skill (PDF 处理技能) 这是 Anthropic 工程博客中介绍的一个经典案例，教 Claude 如何读取 PDF 表单。

目录结构示例：

Plaintext

plugins/pdf-skill/
├── SKILL.md          # 告诉 Claude 如何使用这个技能
├── extract.py        # 实际执行提取工作的 Python 脚本
└── README.md

SKILL.md 内容摘要：

“When the user asks to extract data from a PDF, run the extract.py script provided in this directory. Do not try to read the PDF raw bytes directly. Interpret the JSON output from the script.”

如何使用：用户无需显式调用。只需说 “Read the contract.pdf and tell me the date”，Claude 会自动激活 PDF Skill。

Plugins

Plugin 是上述所有内容（Commands, Agents, Skills）的分发容器。

接下来说一下比较容易混淆的地方，commands，agents，skills 确实有功能重叠的地方，但是他们的侧重点是不一样的，只有明白了他们各自的侧重点之后才能更好的决定使用哪一个。

1. 最大的重叠区：Command vs. Skill

这是最容易混淆的一对。它们都可以用来封装一段 Prompt 或脚本。

• 重叠点：它们本质上都是 “预定义的指令 / 脚本”。

• 核心区别：谁掌握 “扳机”？

  • Command (命令) 是显式的。你（用户） 是控制者。你必须输入 /review，Claude 才会去审查。

  • Skill (技能) 是隐式的。Claude (模型) 是控制者。你只需要说 “帮我看看这代码咋样”，Claude 会自己判断：“哦，用户需要审查代码，我应该调用 CodeReviewSkill。”

例子：

如果你写了一个 Python 脚本 format_code.py。

• 做成 Command (/fmt)：你每次必须手动输入 /fmt 才能运行它。

• 做成 Skill：当你对 Claude 说 “这代码太乱了” 时，Claude 会自动运行这个脚本。

2. 逻辑重叠区：Agent vs. Skill

这两者都涉及 “特定领域的专业能力”。

• 重叠点：都能让 Claude 变得更专业（例如都懂 SQL）。

• 核心区别：上下文是不是独立的？

  • Skill (技能) 是工具。它在当前对话中被加载。它就像给了当前的 Claude 一本《SQL 手册》，它现学现卖，但还是同一个 Claude 在跟你说话，上下文是混在一起的。

  • Agent (代理) 是分身。它拥有独立的上下文。当你调用 Agent 时，就像是 Claude 把任务转包给了坐在旁边的 “数据库专家”。这个专家有自己的记忆和设定，处理完后只把结果告诉主 Claude，避免了主对话窗口被大量的中间步骤污染。

3. Plugin (插件) 的特殊地位

Plugin 没有任何功能上的重叠，因为它不是功能本身，而是包装盒。

• 你不能把 Plugin 和 Command 并列比较。

• Plugin 包含 Command、Skill 和 Agent。

• 就好比：Command 是苹果，Agent 是橙子，而 Plugin 是水果篮。

一个场景看懂所有区别

假设你想实现一个功能：“将代码翻译成中文文档”。你可以通过三种方式实现，侧重点不同：

总结：我该选哪个？

如果你在尝试扩展 Claude Code，可以用这个简单的决策树：

1. 这个功能需要用户手动且精确地触发吗？

   • 是 \rightarrow$\to$ Command (/foo)

   • 否 \rightarrow$\to$ 下一步

2. 这个任务是否非常复杂，需要大量步骤，且容易污染当前的聊天记录？

   • 是 \rightarrow$\to$ Agent (独立的子脑)

   • 否 \rightarrow$\to$ Skill (教会当前大脑新知识)

3. 你想把这些功能打包发给同事用吗？

   • 是 \rightarrow$\to$ 把做好的 Command/Agent/Skill 放到一个文件夹里，做成 Plugin。

如果内容有误，欢迎指出

今天刷微信公众号看到的

Skills 聚合网站

• https://skillsmp.com/

• Claude Code Templates - Supercharge Your AI-Powered Development with Anthropic's Claude Code

• https://claudemarketplaces.com/

开源仓库

1. 官方出品

ChatGPT/Skills

2. 民间开源

• superpowers/skills at main · obra/superpowers · GitHub
• GitHub - ComposioHQ/awesome-claude-skills: A curated list of awesome Claude Skills, resources, and tools for customizing Claude AI workflows
• GitHub - BehiSecc/awesome-claude-skills: A curated list of Claude Skills.
• GitHub - VoltAgent/awesome-claude-skills: The awesome collection of Claude Skills and resources.
• GitHub - travisvn/awesome-claude-skills: A curated list of awesome Claude Skills, resources, and tools for customizing Claude AI workflows — particularly Claude Code
• claudekit-skills/.claude/skills at main · mrgoonie/claudekit-skills · GitHub
• GitHub - K-Dense-AI/claude-scientific-skills: A set of ready to use scientific skills for Claude
• my-skills/skills at master · bear2u/my-skills · GitHub
• GitHub - czlonkowski/n8n-skills: n8n skillset for Claude Code to build flawless n8n workflows
• GitHub - huggingface/skills
• GitHub - yusufkaraaslan/Skill_Seekers: Convert documentation websites, GitHub repositories, and PDFs into Claude AI skills with automatic conflict detection

如何写

先安装官方的 skill-creator 的元 Skill：

然后在会话中，告诉 AI 自己要创建一个什么样的 Skill，它会自自动调用 skill-creator 来和你一起创建一个初稿出来。

但是，但是，不要把初稿当成终稿，要自己多调试、测试使用效果，把效果再反馈给 AI，让他帮忙迭代优化 Skill。

Claude Code 官方文档

https://code.claude.com/docs/zh-CN/overview

Claude Code 安装

npm install -g @anthropic-ai/claude-code

之后在根目录下就会有 ./claude 文件夹，在命令行中输入 claude 后配置自己的账号后就可以使用了。

使用第三方的 api (屯屯鼠的乐趣)

这里建议使用 ccr 或者 CCSwitch 或者 ccNexus.

https://github.com/musistudio/claude-code-router
https://github.com/farion1231/cc-switch
https://github.com/lich0821/ccNexus

Claude 技能增强包

这里我使用 MyClaude 来一键安装。它预先设置了一系列的自定义命令，以方便使用

MyClaude 安装：

git clone https://github.com/username/myclaude.git
cd myclaude

执行命令
mac: python3 install.py --install-dir ~/.claude
win: python install.py --install-dir %USERPROFILE%\.claude

如果上面的命令不行试试下面的
python install.py

使用命令

# 核心开发命令
/dev              # 完整开发流程
/code             # 代码生成
/debug            # 调试
/test             # 测试生成
/review           # 代码审查 # 辅助命令
/refactor         # 重构代码
/optimize         # 优化代码
/docs             # 生成文档
/bugfix           # 修复错误
/ask              # 询问问题
/think            # 思考分析
/enhance-prompt   # 增强提示词 

触发这些命令后 会调用 /agents 目录下的各种代理，使用 /skills 下的各种技能

简单理解：
Commands = 你说的话（用户界面）
Agents   = 执行者（工作流程）
Skills   = 工具箱（技能库）

查看当前有哪些命令工具

方式1：命令查看
python install.py --list-modules

方式2：查看目录
# Mac/Linux ls ~/.claude/commands/    # 查看所有命令 ls ~/.claude/skills/      # 查看所有技能 # Windows dir %USERPROFILE%\.claude\commands\
dir %USERPROFILE%\.claude\skills\


方式3：在 Claude Code 中查看
/help 
或者直接问它：“列出所有可用命令” 

这个项目的规则中已经配置了安全配置，就不用再单独增加了，如果需要可编辑 claude.md 文件

使用 skills.

skills 介绍

这里是官方文档， 简单理解就是预先设置了某个流程的步骤，AI 在使用时判断是否需要加载，如果加载就会按照预先设置的规则按序执行。

skills 为什么会节省 token 呢？

简单来讲就是预先设置了一系列规则后，AI 在遇到这样的逻辑后，从以前的全盘去找改为了根据各自 skills 中的规则去找，不用再读取全盘的数据，这样更快，也更减少 token 的消耗
本站里另一个佬的帖子很好，可以查看 实战 skills - 发票分类查询

自动生成任意网站 / 项目 / 文件且适合自己的 skills

在配置了上面三点后，基本上对绝大多数的使用者的效率都有所提升。对于某个领域的效率提升，就需要自己在各自领域编写适合自己的 skills 了。 这里我使用的 Skill_Seekers 项目。

Skill_Seekers 项目介绍

Skill Seekers 是一个文档转 Claude AI 技能包的自动化工具。它能帮你去读取某个网站的 url, 然后帮你生成对应的 skills 文件：

1. 输入：任何文档网站 URL（如 React、Django、Godot 官方文档）
2. 处理：自动爬取、分类、增强、打包
3. 输出：.zip 文件，可直接上传到 Claude AI

典型流程：
文档网站 → 爬取数据 → 生成 SKILL.md → 打包 .zip → 上传 Claude

使用配置:

安装: 方式1:
pip install skill-seekers

方式2:
uv tool install skill-seekers

这两种是最常用的,还有可以通过源码/脚本来安装,具体可以看github的项目页面.

skill-seekers 参数详解

它需要主命令 + 子命令 + 参数的形式去加载，这里列举几个简单的子命令

skill-seekers <command> [options]

各自子命令的参数都不同 这里我折叠起来方法观看

skill-seekers scrape --config configs/react.json --enhance-local

skill-seekers 参数加载方式

方式 1: 快速模式 直接在命令后面拼接参数
skill-seekers scrape --name myproject --url https://docs.example.com/

方式 2: 交互模式（引导式）
这个模式我没测试，就是 工具会一步步问你哪些参数需要怎么配置
skill-seekers scrape --interactive

方式 3：使用 json 配置文件的方式
skill-seekers scrape --config configs/myproject.json

方式 4: 加载的是 GitHub 仓库
需要提前在环境变量中设置 GITHUBTOKEN, 不然 github 会限制请求
skill-seekers github --repo facebook/react --name react-code

在 AI 增强模块，我测试暂时不能使用本地模型，虽然文档说支持，但我测试下来提示找不到命令，已经给开发者提 bug 了，估计后续版本会修改吧.

当前三方汇总的 Claude skills

第三方网站 (非推广)

https://ss.bytenote.net/
https://skillsmp.com/zh

如果觉得这篇文章对你有用，可否点个赞，评论有用。谢谢

ps: 实在不会好看的排版了 慢慢来吧