CreateSkill

自定义

执行前，请检查用户自定义项是否位于： ~/.claude/LIFEOS/USER/CUSTOMIZATIONS/SKILLS/CreateSkill/

如果此目录存在，请加载并应用其中的 PREFERENCES.md、配置或资源。这些内容优先于默认行为。如果目录不存在，请使用技能默认设置。

🚨 强制要求：语音通知（执行任何操作前必须完成）

调用此技能时，必须先发送此通知，然后才能执行任何其他操作。

1. 发送语音通知：

   curl -s -X POST http://localhost:31337/notify \
     -H "Content-Type: application/json" \
     -d '{"message": "Running the WORKFLOWNAME workflow in the CreateSkill skill to ACTION"}' \
     > /dev/null 2>&1 &
   

2. 输出文本通知：

   Running the **WorkflowName** workflow in the **CreateSkill** skill to ACTION...
   

此步骤不可省略。调用技能后，请立即执行此 curl 命令。

CreateSkill

完整的技能开发生命周期：结构（创建、验证、规范化）+ 有效性（测试、改进、优化触发条件）。结构工作流确保技能遵循 LifeOS 规范。有效性工作流受 Anthropic 的 skill-creator 启发，确保技能真正有效且能可靠触发。

权威来源

创建任何技能前，必须阅读： ~/.claude/LIFEOS/DOCUMENTATION/Skills/SkillSystem.md

规范示例： ~/.claude/skills/ 中任意格式规范的公开技能（例如 Research/SKILL.md、Daemon/SKILL.md、CreateSkill/SKILL.md 本身）。

命名规范——公开与私有

技能名称决定其公开/私有状态。只有以下两种有效形式。

技能类型	目录格式	示例	允许的内容
公开	TitleCase	Blogging、Daemon、CreateSkill	模板化、安全、通用，且可直接公开发布
私有	_ALLCAPS（下划线前缀，全部大写）	_MYSKILL、_MYINBOX、_MYINFRA	个人专用的功能；正文可公开发布且不含敏感信息，所有敏感数据均从 LIFEOS/USER/ 引用

前导下划线是公开发布的界限。 发布工具会完全跳过 _* 技能——它们永远不会离开 ~/.claude。公开技能（不带下划线）会镜像到 LifeOS 公开发布版本中，且必须仅包含通用、模板化的内容。

子文件命名（适用于公开和私有技能）：

组件	格式	示例
工作流文件	TitleCase.md	Create.md、UpdateDaemonInfo.md
参考文档	TitleCase.md	ProsodyGuide.md、ApiReference.md
工具文件	TitleCase.ts	ManageServer.ts
帮助文件	TitleCase.help.md	ManageServer.help.md

错误示例（绝对不要使用）：

• 技能目录：createskill、create-skill、CREATE_SKILL（公开技能不能无下划线且全大写；私有技能不能使用 kebab/snake 格式）
• 文件：create.md、update-info.md、SYNC_REPO.md

如何选择公开或私有——判断规则

请问自己：“能否将此技能原样放入陌生人的 ~/.claude/skills/ 并直接使用？”

• 可以 → 公开技能（TitleCase）。正文必须通用；用户专属配置通过 LIFEOS/USER/CUSTOMIZATIONS/SKILLS/<SkillName>/ 加载。
• 不可以，因为它引用了我的身份、联系人、业务、客户、付费 API、私有基础设施、域名、私有仓库、伴侣或财务/健康/安全数据 → 私有技能（_ALLCAPS）。

如有疑问，先创建为私有技能（_ALLCAPS）。之后将 _FOO 改为 Foo 很容易；而发现公开技能泄露了你的生活，则无法挽回。

---

公开发布就绪度（强制要求）

公开技能（TitleCase）会发布给所有人。私有技能（_ALLCAPS）永远不会离开本地仓库。 敏感性由技能名称决定，而非在分享时逐个文件检查。

明确界限

公开技能（TitleCase）——内容规则：

只能包含经过模板化处理、安全、公开且可直接使用的内容。仅此而已。

• ✅ 任何 LifeOS 用户都能遵循的通用说明
• ✅ 使用占位符表示用户专属值的模板化模式
• ✅ 公开 API 参考资料，以及对公开工具的依赖
• ❌ 真实姓名（个人、产品、公司、客户）
• ❌ 真实域名、主机名、IP、内部 URL
• ❌ API 密钥、令牌、凭据、会话 Cookie、OAuth 密钥——即使看起来像示例也不行
• ❌ 私有仓库路径或引用（github.com/<org>/<private-repo>）
• ❌ 客户数据、客户专属工作流、客户互动背景
• ❌ 与特定事件、项目或个人有关的第一人称亲历故事
• ❌ 用户专属文件系统路径（/Users/<name>/...、/home/<name>/...）
• ❌ 与身份绑定的偏好（DA 姓名、委托人姓名、合作伙伴姓名、宠物姓名、财务数据、健康数据）

私有技能（_ALLCAPS）——内容规则（2026-07-23 分离指令）：

必须达到与公开技能相同的可发布洁净标准。下划线仍是发布边界（发布工具会跳过 _*——这层安全网仍然保留），但它不再允许嵌入个人内容。私有技能的正文——SKILL.md、工作流、工具——只能包含通用代码和说明；所有敏感内容都放在 LIFEOS/USER/ 下，技能通过路径读取：

• 个人数据（语料库、清单、偏好、登记表、状态）→ LIFEOS/USER/CUSTOMIZATIONS/SKILLS/<SkillName>/——除非已有规范的 USER 主目录存放该数据（GEAR.md、FINANCES/、TELOS/、CONTACTS.md）；此时应指向该位置，绝不重复存放。
• 个人配置（你的域名、账户 ID、仓库路径、端点）→ 同一 CUSTOMIZATIONS 目录中的 Config.md/.yaml，由技能在运行时加载。
• 凭据 → 技能中使用环境变量名称，实际值放在 ~/.claude/.env 中。绝不写入实际值，URL 中也绝不包含令牌。
• 正文使用“委托人”称呼，绝不使用真实姓名；不写入字面形式的主目录路径（只能使用相对于 ~ 的路径或由配置解析的路径）。

原因：在这种状态下，私有技能只需重命名就能转为公开技能，整个目录树都能通过同一项卫生检查，而且即使技能目录树泄露，也不会泄露个人数据。技能之所以私有，是因为其功能限定于个人场景（你的收件箱、你的客户、你的基础设施），而不是因为其文件存放着你的数据。

执行检查： LIFEOS/TOOLS/SkillHygieneGate.ts（拒绝名单检查，通过 /ic 运行）以及 SystemFileGuard 写入关卡。只要关卡仍报告该技能存在违规，新技能就不能算完成。

判断标准

如果你发现自己想在技能正文中写入以下任何内容，该技能就必须使用 _ALLCAPS：

如果技能提及……	技能必须使用
某个具体人物的姓名（你、你的伴侣、你的团队成员或客户）	_ALLCAPS
你拥有或销售的某个具体产品名称	_ALLCAPS
某个具体客户	_ALLCAPS
某个具体的付费 API 账户、计费主体或订阅	_ALLCAPS
某个具体的私有域名、主机名、内部 IP 或 VPN	_ALLCAPS
某个具体的私有仓库、点文件位置或本地基础设施	_ALLCAPS
与你的公司相关的某个具体业务流程	_ALLCAPS
某个具体的财务、健康、安全或法律背景	_ALLCAPS
某个具体事件或一次性的亲历故事	_ALLCAPS
任何写入其他人的 ~/.claude/ 会不准确、令人尴尬或不安全的内容	_ALLCAPS

如果以上情况均不适用，且技能完全通用——则可使用 TitleCase（公开）。

公共技能的个性化配置放在哪里

公共技能可在运行时通过 ~/.claude/LIFEOS/USER/CUSTOMIZATIONS/SKILLS/<SkillName>/PREFERENCES.md 设置为因用户而异。技能正文保持通用；用户的自定义文件会叠加针对具体实例的上下文。当技能本身是通用的，但受益于因用户而异的调整（首选语气、默认格式、个人偏好）时，请使用此方式。

不要使用 CUSTOMIZATIONS/SKILLS 将私人内容偷偷塞进公共技能。 如果技能需要私人上下文才能运行（真实客户名称、真实 API 账号、真实内部基础设施），它就是私人技能——将其命名为 _ALLCAPS，并到此为止。

公共技能中允许的内容

• 通用 ~/ 路径（~/.claude/skills/、~/Projects/<tool>/）——按用户解析
• 技能所依赖工具的公共仓库 URL
• 属于惯例而非机密的公共 API 端点（例如，localhost:31337/notify）
• 明确标记为占位符的示例值（<url>、<SESSION_ID>、[email protected]）
• 通用环境变量名称（绝不包含值）：STRIPE_API_KEY、OPENAI_API_KEY

预检门禁（所有技能——公共和私人）

发布或修改任何技能前，运行卫生检查：

bun ~/.claude/LIFEOS/TOOLS/SkillHygieneGate.ts --skill <SkillName>

该检查会根据规范拒绝列表（LIFEOS/USER/SECURITY/DENY_LIST.txt——该列表属于身份数据，因此存放在 USER 树中）以及主目录路径格式进行扫描。退出码为 0 = 检查通过。任何违规内容 = 将数据移至 LIFEOS/USER/CUSTOMIZATIONS/SKILLS/<SkillName>/（或其规范的 USER 主目录），并通过路径引用。自 2026-07-23 起，私人技能不再享有豁免——_ALLCAPS 决定技能发布到哪里（无处发布），而不是其文件可以包含什么。

---

扁平文件夹结构（强制）

重要：保持文件夹结构扁平——最多 2 层深。

规则

最大深度： skills/SkillName/Category/

✅ 允许（最多 2 层）

skills/SkillName/SKILL.md                    # Skill root
skills/SkillName/Workflows/Create.md         # Workflow - one level deep - GOOD
skills/SkillName/Tools/Manage.ts             # Tool - one level deep - GOOD
skills/SkillName/QuickStartGuide.md          # Context file - in root - GOOD
skills/SkillName/Examples.md                 # Context file - in root - GOOD

❌ 禁止（层级过深或位置错误）

skills/SkillName/Resources/Guide.md              # Context files go in root, NOT Resources/
skills/SkillName/Docs/Examples.md                # Context files go in root, NOT Docs/
skills/SkillName/Workflows/Category/File.md      # THREE levels - NO
skills/SkillName/Templates/Primitives/File.md    # THREE levels - NO
skills/SkillName/Tools/Utils/Helper.ts           # THREE levels - NO

允许的子目录

允许使用以下子目录：

• Workflows/ - 仅用于执行工作流
• Tools/ - 仅用于可执行脚本/工具
• References/ - 用于大型技能的扩展参考资料（API 文档、详细指南）

上下文文件（文档、指南、参考资料）应放在技能根目录或 References/ 中。

何时使用 References/： 当 SKILL.md 超过约 500 行，且包含大量参考内容（API 签名、详细示例、故障排除指南）时。让 SKILL.md 作为路由指南；将百科全书式内容移至 References/。

原因

1. 易于发现 - 文件易于查找
2. 简单 - 减少导航开销
3. 速度 - 加快文件操作
4. 一致性 - 每个技能都遵循相同模式

如果需要整理多个工作流，请使用清晰的文件名，而不是子目录：

参见： ~/.claude/LIFEOS/DOCUMENTATION/Skills/SkillSystem.md（扁平文件夹结构部分）

---

动态加载模式（大型技能）

对于 SKILL.md 超过 100 行的技能： 使用动态加载，以减少调用技能时的上下文。

加载方式

会话启动时： 仅加载 frontmatter，用于路由
调用技能时： 加载完整 SKILL.md
上下文文件： 仅在工作流引用时加载

模式

SKILL.md = 精简（30-50 行）——调用技能时加载

• 包含触发条件的 YAML frontmatter
• 简要说明
• 工作流路由表
• 快速参考
• 指向上下文文件的链接

其他 .md 文件 = 上下文文件——针对特定方面的 SOP（按需加载）

• 这些是标准操作流程，而不只是文档
• 它们提供具体的处理说明
• 可以引用 Workflows/、Tools/ 等

🚨 重要：不要创建 Context/ 子目录 🚨

绝不要创建 Context/ 或 Docs/ 子目录。

其他 .md 文件就是上下文文件。它们直接放在技能根目录中。

错误：

skills/Art/
├── SKILL.md
└── Context/              ❌ NEVER CREATE THIS
    └── Aesthetic.md

正确：

skills/Art/
├── SKILL.md
├── Aesthetic.md          ✅ Context file in skill root
├── Examples.md           ✅ Context file in skill root
└── Tools.md              ✅ Context file in skill root

技能目录本身就是上下文。

结构示例

skills/Art/
├── SKILL.md              # 40 lines - minimal routing
├── Aesthetic.md          # Context file - SOP for aesthetic
├── Examples.md           # Context file - SOP for examples
├── Tools.md              # Context file - SOP for tools
├── Workflows/            # Workflows
│   └── Essay.md
└── Tools/                # CLI tools
    └── Generate.ts

最简 SKILL.md 模板

---
name: SkillName
description: Create, test, and optimize LifeOS skills — scaffolding, effectiveness testing, description optimization. USE WHEN create skill, new skill, validate skill, test skill, improve skill, optimize description.
---

# SkillName

Brief description.

## Workflow Routing

| Trigger | Workflow |
|---------|----------|
| "trigger" | `Workflows/WorkflowName.md` |

## Quick Reference

**Key points** (3-5 bullet points)

**Full Documentation:**
- Detail 1: `SkillSearch('skillname detail1')` → loads Detail1.md
- Detail 2: `SkillSearch('skillname detail2')` → loads Detail2.md

适用场景

✅ 适合使用动态加载的情况：

• SKILL.md 超过 100 行
• 包含多个文档章节
• API 参考内容较多
• 示例详尽

❌ 不适合使用的情况：

• 简单的技能（少于 50 行）
• 纯工具封装（请改用 LIFEOS/TOOLS.md）

优势

• 节省令牌： 调用技能时可减少 70% 以上的令牌消耗（无需完整文档时）
• 组织清晰： SKILL.md 负责路由，上下文文件负责特定方面的标准操作流程
• 高效： 工作流只加载实际需要的内容
• 易于维护： 更容易更新各个章节

参见： ~/.claude/LIFEOS/DOCUMENTATION/Skills/SkillSystem.md（动态加载模式章节）

---

工作流路由

结构工作流（脚手架和规范）

工作流	触发词	文件
CreateSkill	“创建新技能”	Workflows/CreateSkill.md
ValidateSkill	“验证技能”、“检查技能”	Workflows/ValidateSkill.md
UpdateSkill	“更新技能”、“添加工作流”	Workflows/UpdateSkill.md
CanonicalizeSkill	“规范化”、“修复技能结构”	Workflows/CanonicalizeSkill.md

效果工作流（测试和优化）

工作流	触发词	文件
TestSkill	“测试技能”、“这个技能是否有效”、“技能无法正常工作”	Workflows/TestSkill.md
ImproveSkill	“改进技能”、“技能质量”、“修复技能说明”	Workflows/ImproveSkill.md
OptimizeDescription	“优化描述”、“技能未触发”、“触发准确性”	Workflows/OptimizeDescription.md

技能类型（构建前选择）

创建任何技能之前，请先确定其属于 9 种类型中的哪一种（引自 Anthropic 内部技能分类法，Thariq Shihipar，2026 年 3 月）。类型会影响结构和测试决策。

类型	重点	关键结构	示例
1. 库/API 参考	Claude 容易出错的注意事项和边缘情况	轻量、侧重注意事项、参考代码片段	HonoReference、D1Reference
2. 产品验证	测试/验证代码是否有效	状态断言、浏览器自动化、输出记录	Browser
3. 数据获取	连接数据系统	凭证引用、查询模式、仪表板指引	USMetrics、一项业务指标技能
4. 业务流程	自动化重复性工作流	执行日志、一致性跟踪	一项任务跟踪技能、一项内容分发技能
5. 代码脚手架	生成框架样板代码	模板文件、感知项目的脚本	CreateCLI、CreateSkill
6. 代码质量	执行标准、进行审查	确定性脚本、钩子集成	/simplify、/code-review
7. CI/CD 与部署	采用安全模式进行部署	部署前检查、冒烟测试、回滚	（缺失——需要 Deploy 技能）
8. 运维手册	将现象映射到诊断流程	现象 → 工具 → 查询 → 报告	一项站点健康检查技能
9. 基础设施运维	在安全防护措施下进行维护	安全关卡、审计日志、孤立项检测	一项系统管理技能、一项 dotfiles 技能

技能编写指南

编写或改进技能说明时，请遵循 Anthropic 的 skill-creator 方法论以及 Thariq Shihipar 的《构建 Claude Code 的经验》（2026 年 3 月）中的原则：

核心原则

• 不要陈述显而易见的内容。 Claude 擅长编程，也了解代码库。重点提供那些会打破 Claude 默认模式的信息——也就是没有指导时它会做错的事。测试方法：“不告诉 Claude 的话，它会做错吗？”如果不会，就删掉。
• 解释原因，而不只是说明要做什么。 心智理论能力强、推理清晰的模型，表现优于受僵化约束的模型。与其说“始终使用 3 个项目符号”，不如解释项目符号对读者为何重要。
• 保持精简。 上下文窗口是公共资源。删掉不会改善输出的指令。如果测试记录表明 Agent 在无效步骤上浪费时间，就删掉这些步骤。SKILL.md 应少于 500 行。
• 删掉只起强调作用的行。 一条规则说一次就是指令。MANDATORY、CRITICAL、“不可选”以及第三次重申只会增加篇幅，不会增强约束——模型遵循的是具体要求和代码，而不是强调语气。删除任何只是在大声重申其他地方已说明规则的行。留意 ## Best Practices / ## Tips 部分：这些部分容易堆积重述默认要求的赘述（“要全面”“保持简单”“仔细验证”）。对每一行都按照 Prompting/Standards.md § 信噪比中的删除测试进行检查：先删掉，只有在能说出它强制执行的具体非默认行为时才恢复。
• 归纳规律，不要过拟合。 修正底层模式，而不是特定的测试失败。除了测试集中的提示词外，这项技能还会用于许多其他提示词。
• 打包重复工作。 如果测试 Agent 都各自编写了类似的辅助脚本，就把该脚本加入 Tools/，让今后的每次调用都能受益。
• 设置合适的自由度。 根据任务的脆弱程度调整具体程度。数据库迁移需要精确命令；代码审查则需要一般性指导。
• 不要过度约束。 技能会被反复使用。避免过于具体的指令。提供必要信息，同时保留应对不同情境的灵活性。

描述最佳实践

• 描述面向模型，而非人类。 描述会注入系统提示词。Claude 会读取它，以决定是否调用这项技能。
• 描述应稍微积极引导。 模型往往触发不足。即使用户可能不会明确提及这项技能，也要列出具体场景。
• 为容易混淆的技能加入负向触发条件。 如果技能之间共用一些词汇，就添加“NOT FOR”条款："NOT FOR web pentesting (use WebAssessment)"。
• 触发不足的信号： 应加载时技能没有加载，或用户手动调用技能。
• 触发过度的信号： 技能针对无关查询加载，或用户将其禁用。

注意事项部分（必须）

每项技能都必须在工作流路由表后包含 ## Gotchas 部分。Thariq：“在任何技能中，注意事项部分的信息密度最高。”

填写以下内容：

• Claude 不熟悉的 API 特性
• 使用过程中观察到的常见错误
• 不明显的顺序或时序要求
• 会导致静默失败的边缘情况

注意事项会随时间积累。 每次技能失败后，都要添加相应经验。

理想状态提示（WHAT，而非 HOW）——强制性编写风格

编写每个新技能正文和工作流时，都要采用理想状态风格：说明完成的交付物应是什么样子（以可测试的结果呈现）、约束条件和工具——然后相信模型能找到 HOW。 对开放式认知工作，用编号步骤列表编排模型的推理过程，是违反 BPE 原则的脚手架：它会限制能力强大的模型，而且随着模型进步而变得过时。技能中有四类 HOW 是合理且应保留的：安全门控、已验证的陷阱（这正是 ## Gotchas 的用途）、工具契约（工作流中的精确调用方案）、输出格式契约。确定性工具（*.ts）不受此限制。编写或改进技能时，应删去方法论叙述，只保留理想状态、约束条件、工具和这四类内容。完整标准：LIFEOS/DOCUMENTATION/Skills/SkillSystem.md § 编写标准。

BPE（苦涩觉醒式工程）检查

在完成任何技能之前，先问：“更聪明的模型是否会让这项技能变得多余？”

• 抗脆弱（保留）： 验证工具链、数据管道、工具封装、积累的陷阱、确定性脚本
• 脆弱（质疑）： CoT 编排器、格式解析器、重试级联、复杂的推理脚手架

技能应聚焦于 Claude 无法推导出的知识（故障模式、API 特性）、Claude 无法复现的工具（API 调用、自动化），以及能从一致性中获益的工作流。

渐进式披露（来自 Anthropic）

信息加载分为三个级别——用它来管理大型技能：

1. Level 1（YAML frontmatter）： 始终包含在系统提示词中。仅提供触发信息。
2. Level 2（SKILL.md 正文）： 技能被调用时加载。包含路由信息和关键指导。
3. Level 3（参考文件）： 根目录下的 .md 文件或 References/ 子目录，按需加载。

告诉 Claude 有哪些文件；它会在适当的时候读取这些文件。SKILL.md 应少于 500 行——如果超过，就将详细内容提取到参考文件中。

测试最佳实践（来自 Anthropic）

技能的三个测试级别：

1. 手动测试——运行查询并观察行为
2. 脚本化测试——自动化测试用例（使用 TestSkill 工作流）
3. 程序化测试——构建评估套件（使用 Evals 技能）

评估驱动开发： 在构建技能之前，先定义“技能正常运行”是什么样子。围绕单个有挑战性的任务反复迭代，直到 Claude 成功，然后提炼出有效的方法。

按需钩子模式（来自 Anthropic）

技能可以包含仅在调用时激活的钩子，并在会话期间持续生效：

• /careful — 拦截危险命令（rm -rf、DROP TABLE、强制推送）
• /freeze — 阻止编辑特定目录以外的内容
• /audit — 记录所有工具调用，供会话审查

以上指导均源自 Thariq Shihipar 的《构建 Claude Code 的经验教训》（2026 年 3 月）、Anthropic 官方技能指南和平台文档。

版本管理

每个技能都在 SKILL.md 的 frontmatter 中拥有自己的 version: 语义化版本号（Major.Feature.Patch——中间的数字是 Feature，不是“minor”），独立于 OS 版本和其他技能。新技能以 version: 1.0.0 起步。技能变更也属于 OS 变更——skills/ 是 LifeOS 版本系统监视的核心文件范围的一部分——因此编辑技能会同时更新技能自身的版本和（汇总后的）规范 LIFEOS/VERSION。这两行各自独立：技能的 version: 属于其自身的版本沿革；LIFEOS/VERSION 是总版本。CreateSkill 绝不会自行编辑 LIFEOS/VERSION。

对变更进行分类，以确定正确的版本升级级别（同一套规则适用于单个技能的版本升级和汇总版本升级）：

• patch — 添加注意事项、修正错字、微调描述、同步文档。不新增能力。
• feature — 新增工作流或工具（全新技能从 1.0.0 起步，不算自身的 feature 升级）。向后兼容，只做增量添加。
• major — 重命名或移除技能，或破坏其公开契约或路由行为。人工把关：进行任何 major 升级前都要停下并确认；绝不要自行决定升级到 major。

单个技能何时升级版本：在私有同步时，而非编辑时。UpdateKaiRepo 发布流程会运行 BumpSkillVersions.ts——对于自上次 OS 标记以来发生变更的每个 skills/<name>/，它会按 ClassifyChange --path skills/<name> 进行分类，并升级该技能的 version:（major 需等待确认），同时将每项变更记录到 SYSTEMUPDATES 注册表中。这会捕获未经过 CreateSkill 的工作流正文编辑。此处不要手动升级 version:；由发布流程负责。（该发布流程属于维护者工具，不会随公开版本发布——在没有此流程的已安装系统上，应在编辑时按照上述语义化版本规则手动升级 version:。）技能编辑属于私有同步变更——绝不能进行版本发布（仅暂存）或公开发布（公开仓库）。这三种操作要明确区分。

公开技能不带单独的版本行——发布/生成时会原样保留每个技能的私有 version:。

（如果上方存在 Customization 区块，请参阅其中此安装层对应的具体命令/路径。）

示例

示例 1：从头创建新技能

User: "Create a skill for managing my recipes"
→ Invokes CreateSkill workflow
→ Reads SkillSystem.md for structure requirements
→ Creates skill directory with TitleCase naming
→ Creates SKILL.md, Workflows/, Tools/
→ Suggests running TestSkill to verify effectiveness

示例 2：修复路由不正确的现有技能

User: "The research skill isn't triggering - validate it"
→ Invokes ValidateSkill workflow
→ Checks SKILL.md against canonical format
→ Verifies TitleCase naming and USE WHEN triggers
→ Reports compliance issues with fixes

示例 3：测试技能是否确实有帮助

User: "Test the Blogging skill to see if it's effective"
→ Invokes TestSkill workflow
→ Generates 3 realistic test prompts
→ Spawns with-skill and baseline agents in parallel
→ Compares outputs, presents results
→ Iterates with ImproveSkill based on feedback

示例 4：技能未对相关提示词触发

User: "The Security skill doesn't trigger when I ask about pentesting"
→ Invokes OptimizeDescription workflow
→ Generates 20 should/shouldn't-trigger queries
→ Tests description accuracy via subagents
→ Rewrites description, re-tests, reports improvement

示例 5：改进输出质量不佳的技能

User: "The research skill output is too verbose — improve it"
→ Invokes ImproveSkill workflow
→ Reads skill + user feedback
→ Diagnoses root cause (over-specified instructions)
→ Rewrites with reasoning instead of rigid MUSTs
→ Suggests TestSkill to verify improvement

注意事项

• **此文件自身的描述约为 1022 个字符——距离 1024 字符上限还差 2 个。**任何会增加 frontmatter 描述字符数的编辑，都必须在保存前重新测量（2026-06-13 审计）。
• 此文件中有两个 ## Workflow Routing 标题——第一个（约第 276 行）位于嵌入式模板示例中，第二个（约第 315 行）才是真正的标题。标题扫描工具必须采用最后一个匹配项，而非第一个。
• 阅读此技能的工作流并手动执行步骤，是手工仿制的反模式——skills/CLAUDE.md 要求调用技能，而不是模仿它。要求包含 Gotchas 区块的技能此前一直没有该区块，直到 2026-06-13 才补上；请将清单中的项目也视为适用于此技能。

执行日志

完成任何工作流后，追加一条 JSONL 记录：

echo '{"ts":"'$(date -u +%Y-%m-%dT%H:%M:%SZ)'","skill":"CreateSkill","workflow":"WORKFLOW_USED","input":"8_WORD_SUMMARY","status":"ok|error","duration_s":SECONDS}' >> ~/.claude/LIFEOS/MEMORY/SKILLS/execution.jsonl

将 WORKFLOW_USED 替换为执行的工作流，将 8_WORD_SUMMARY 替换为对输入的简要描述，将 SECONDS 替换为大致的实际耗时。若工作流失败，则记录 status: "error"。