Skill Forge 是一个用于为 Claude Code 创建高质量、生产级技能的技能。它提供技能架构、工作流设计、提示工程和打包方面的专家指导。
核心理念
Skill Forge 的第一原则是「铁律」（IRON LAW）：技能中的每一行都必须证明其 token 成本是合理的。如果一行内容不能让模型的输出更好、更一致或更可靠，就应删去。
Skill Forge 将「技能」定义为 Claude 的「入职指南」——通过流程性知识、领域专长和附带工具，把 Claude 从通用智能体转变为专业智能体。典型技能目录结构如下：
skill-name/
├── SKILL.md # 必需：工作流 + 指令（<500 行）
├── scripts/ # 可选：确定性、可重复的操作
├── references/ # 可选：按需加载到上下文
└── assets/ # 可选：用于输出，不加载到上下文
默认假设是：Claude 已经非常聪明，只添加 Claude 原本不知道的内容。每写一段都应自问：「这段内容能证明它的 token 成本吗？」
工作流
Skill Forge 提供一套可勾选的进度清单：
- 步骤 1：理解技能（⚠️ 必需）——明确目的与具体用例；收集 3 个以上具体使用示例；识别触发场景和关键词。
- 步骤 2：规划架构——识别可复用资源（脚本、引用、资产）；设计渐进式加载策略；设计参数系统（如适用）。
- 步骤 3：初始化（⛔ 阻塞项；如技能已存在则跳过）——运行 init_skill.py。
- 步骤 4：编写描述——加载 references/description-guide.md；应用关键词轰炸技巧。
- 步骤 5：编写 SKILL.md 正文——设定铁律；设计工作流清单；添加确认门；添加参数系统（如适用）；应用写作技巧；添加反模式列表；添加交付前检查表。
- 步骤 6：构建资源——实现并测试脚本；编写引用文件；准备资产。
- 步骤 7：审查（⚠️ 必需）——运行交付前检查表（步骤 9）；向用户展示摘要并确认。
- 步骤 8：打包——运行 package_skill.py。
- 步骤 9：基于真实使用进行迭代。
各步骤要点
步骤 1：理解技能（⚠️ 必需） 需要回答：这个技能解决了 Claude 自己无法很好处理的什么具体问题？用户实际上会输入什么来触发它？3–5 个带有真实输入与预期输出的具体用例是什么？如果仍不清楚，应向用户提问，但不要一次问完所有问题，先从最关键的开始。在获得至少 3 个具体示例前不要继续。
步骤 2：规划架构 对每个具体示例追问：哪些操作是确定性、可重复的？→ scripts/；Claude 在特定步骤需要哪些领域知识？→ references/；哪些文件用于输出但不用于推理？→ assets/。关键约束：SKILL.md 必须保持在 500 行以内，其余内容放入 references/；引用按领域组织，只允许一层嵌套；可加载 references/architecture-guide.md 了解渐进式加载模式和组织策略。
步骤 3：初始化（⛔ 阻塞项） 如处理已有技能则跳过。否则运行：
python3 scripts/init_skill.py <skill-name> --path <output-directory>
该脚本会创建带有铁律占位符、工作流清单和正确目录结构的模板。
步骤 4：编写描述 这是技能中最被低估的部分。描述决定了技能是否会自动触发、用户是否能通过搜索找到它。可加载 references/description-guide.md 了解关键词轰炸技巧和正反面示例。关键规则：绝不要把「何时使用」的信息放在 SKILL.md 正文中——正文是在触发之后才加载的，为时已晚。
步骤 5：编写 SKILL.md 正文 按子步骤加载相应引用文件：
- 5.1 设定铁律：追问「模型最可能犯的那一个错误是什么？」写一条规则来防止它，放在 SKILL.md 最顶部、紧接 frontmatter 之后。可加载 references/writing-techniques.md 了解铁律模式和红旗信号。
- 5.2 设计工作流清单：创建可跟踪清单，用 ⚠️ 标记不可跳过的步骤，⛔ 标记前置条件，复杂步骤可嵌套子步骤，依赖先前选择的步骤标注 (conditional)。可加载 references/workflow-patterns.md。
- 5.3 添加确认门：强制模型在破坏性操作（删除、覆盖、修改）、成本较高的生成操作、基于分析应用更改之前停下来询问用户。可加载 references/workflow-patterns.md。
- 5.4 添加参数系统（如适用）：若技能受益于 --quick、--style、--regenerate N 之类的标志，可加载 references/parameter-system.md 了解 $ARGUMENTS、标志、argument-hint 和部分执行模式。
- 5.5 应用写作技巧：问题式指令（给出问题，而非模糊指令）、反模式文档（列出不该做什么）、铁律 + 红旗（防止模型走捷径）。可加载 references/writing-techniques.md。
- 5.6 添加反模式列表：追问「Claude 在这项任务上的懒惰默认表现会是什么样？」然后明确禁止它。可加载 references/writing-techniques.md。
- 5.7 添加交付前检查表：添加具体、可验证的检查项，每项都应具体到模型能通过查看输出进行核对。不是「确保质量良好」，而是「没有残留占位符文本（TODO、FIXME、xxx）」。可加载 references/output-patterns.md 了解检查表模式和基于优先级的输出。
写作原则
- 简洁：只添加 Claude 原本不知道的内容。
- 祈使句式：「Analyze the input」而非「You should analyze the input」。
- 让自由度匹配脆弱度：狭窄的桥 → 具体护栏；开阔的田野 → 多条路线。
- 高自由度（文本）：多种有效方式。
- 中自由度（伪代码/参数）：偏好模式，允许一定变化。
- 低自由度（具体脚本）：脆弱操作，一致性至关重要。
构建资源（步骤 6）
脚本：封装确定性、可重复的操作；脚本执行不会加载到上下文——可大幅节省 token；打包前测试每个脚本；在 SKILL.md 中只记录命令和参数，不记录源代码。
引用：按领域而非类型组织；只允许一层嵌套；每个文件都从 SKILL.md 引用并附明确的「何时加载」说明；大文件（>100 行）应在顶部放置目录。
资产：用于输出的模板、图片、字体；不加载到上下文，仅通过路径引用。可加载 references/architecture-guide.md 了解详细模式。
审查（步骤 7，⚠️ 必需）
在打包前向用户展示技能摘要并确认。交付前检查表包括：
结构方面：SKILL.md 少于 500 行；frontmatter 只含 name 和 description（以及可选的 allowed-tools、license、metadata）；描述包含触发关键词和使用场景；没有 README.md、CHANGELOG.md 等不必要文件；没有初始化残留的示例/占位文件。
质量方面：顶部有铁律或核心约束；有带 ⚠️/⛔ 标记的可跟踪工作流清单；破坏性/生成性操作前有确认门；使用问题式指令而非模糊指令；列出反模式（不该做什么）；引用渐进式加载，而非一次性全部加载。
资源方面：脚本已测试且可执行；引用按领域组织、一层深度；大型引用有目录；资产用于输出，不加载到上下文。
应避免的反模式
- 把所有内容塞进一个巨大的 SKILL.md（>500 行）。
- 模糊描述，如「A tool for X」。
- 没有工作流——让模型随意发挥。
- 没有确认门——模型一路无人检查地执行到底。
- 模糊指令，如「确保质量良好」，而非具体检查。
- 包含 README.md、INSTALLATION_GUIDE.md 或其他文档文件。
- 把「何时使用」信息放在正文而非 description 字段。
打包与迭代（步骤 8、9）
打包命令：
python3 scripts/package_skill.py <path/to/skill-folder> [output-directory]
打包前会自动校验，修复错误后重新运行。
迭代：在真实使用后，注意模型在何处吃力或不一致，识别哪个工作流步骤需要改进，添加更具体的指令、示例或反模式，然后重新测试并重新打包。
关于收费、价格、平台支持范围等信息，资料暂未提供。