qiaomu-meta-skill

Qiaomu Meta Skill

构建可复用的 Qiaomu 技能包，而非冗长提示词。

路由规则

• 首先根据 frontmatter 中的 description 进行路由。
• 选定后，qiaomu-meta-skill 是唯一的创作权威。除非用户明确要求比较，或此技能不可用，否则不要同时调用通用的 skill-creator。
• 内置的先例检索由此技能负责。不要安装、加载或委派给单独的检索技能。
• 内置的 GitHub 发布由此技能负责。选定此软件包后，不要要求或调用单独的发布技能。
• 软件包根目录中的 SKILL.md 仅保留路由和最精简的工作流。判断依据放入 references/，确定性行为放入 scripts/，回归用例放入 evals/，证据放入 reports/。
• 一个软件包只能有一个可发现的根目录 SKILL.md；嵌入的示例和夹具使用 SKILL.example.md 或 SKILL.fixture.md。
• 不要将一次性的摘要、翻译、解释或头脑风暴转化为技能。
• 根据用户的操作意图处理：创建、重构和打包请求可以编辑；仅审计、评估或诊断的请求保持只读；只有在用户明确要求时才发布。
• 默认使用简洁、中文优先的 qiaomu- 名称，首选不超过三个连字符分隔的部分。
• 添加 Copyright (c) 向阳乔木、X https://x.com/vista8 和 GitHub https://github.com/joeseesun/，除非用户指定了其他所有者。

模式

• Scaffold：探索性或个人用途；只包含最低限度的实用文件。
• Production：团队复用；包含 README、接口、触发评估、输出约定和安装证据。
• Library：共享基础设施；在 Production 的基础上增加 Skill IR、可移植性、信任和审查周期。
• Governed：公开或高信任用途；在 Library 的基础上增加权限、回滚、机密信息、发布和声明门槛。

结合 Operating Modes、Gate Selection 和 QA Ladder 按需选择。

内置先例检索

在创建新技能或进行重大重新设计之前：

1. 根据意图拟定 2–4 个查询，涵盖预期结果、领域操作、质量机制，以及有用时的相近同义词。
2. 优先使用统一运行器：

python3 scripts/research_prior_art.py "<query 1>" "<query 2>" --strict --summary --output reports/prior-art-candidates.json

其底层目录调用仍包括：

npx --yes skills find "<query>"
python3 scripts/search_skillsmp.py "<query>" --limit 20 --sort stars

3. 分开处理各项指标：skills.sh 安装量衡量采用情况；SkillsMP 星标属于源代码仓库；两者都不是用户评分或质量分数。
4. 按规范的 GitHub 仓库和技能路径去重。合并译本、镜像和明显的分支副本，但不要将指标相加。
5. 筛选出真正相关、受欢迎、可信且具有互补性的参考对象。检查源 SKILL.md、维护情况、许可证、权限、安全信号和可用的评分证据；切勿仅为研究而执行不可信候选项的代码。
6. 综合判断“保留 / 调整 / 拒绝 / 创新”。将每项采纳的机制映射到新软件包中，而不是拼贴文字。
7. 对于 Production+ 或经过实质性研究的工作，在 reports/prior-art-research.md 中保留带日期的来源、指标、失败情况、去重结果、经验、拒绝理由和缺失证据。

如果某个目录调用失败，请继续使用其他来源，记录 missing evidence，并降低结论的确定性。完整方法见：Prior-Art Research。

泛化门槛

将单次失败提升为核心规则之前：

1. 将其重新表述为与领域无关的行为
2. 将其归类为核心机制、可选适配器或仅用于评估的夹具
3. 只提升安全、事实或权限方面的不变条件，或在互不相关领域中反复出现的行为
4. 将一次性细节保留在夹具或专业参考资料中
5. 重新运行原始用例和无关边界用例

优先保证意图忠实度、来源忠实度和决策规则，而不是不断扩充主题百科。

Qiaomu Skill OS

1. Intent：重复性任务、用户、输入、输出、排除项、标准和参考资料。
2. Skill IR：与平台无关的含义和证据边界。
3. Package：精简的根指令、接口、README 和经确认有用的资源。
4. Eval：优先检查触发边界；仅在风险足以构成理由时评估输出、运行时或人工表现。
5. Review：检查包、上下文、信任、安装、README 和公开声明。
6. Operate：明确记录反馈、失败、偏差和下一轮迭代建议，不包含原始私密内容。

精简工作流

1. 判断请求是否值得制作可复用的 skill；否则直接回答，不创建包。
2. 记录任务、完成的输出、目标用户、输入、排除项、权限、标准、现有资产、平台和发布意图。
3. 通过前期成果发现环节，或记录其为何不适用或缺少证据。
4. 对基于样例的核心变更，通过泛化关卡。
5. 选择最轻量且有效的模式。
6. 尽早编写 description（包含 : 时加引号或使用 description: |，例如 Excludes:）；扩展结构前先运行 evals/trigger_cases.json。
7. 只创建经确认有用的资源。绝不创建形式主义目录，也不重复 README/SKILL 中的内容。
8. 对 Production+、公开或跨平台的包，导出 reports/skill-ir.json。
9. 若仅靠触发测试无法证明正确性、安全性、说服力或可重复性，则添加输出评估。
10. 将变更限制在请求的操作范围内，并为高风险变更保留回滚方式。
11. 验证包、单元测试、触发行为、上下文预算、机密信息／信任边界和证据声明。
12. 生成创建交接文档，并明确标注缺失的证据。
13. 如请求发布，先阅读 自包含 Skill 发布，然后使用内置发布工具完成：功能分支 → 验证 → PR → 合并 → 发布／安装验证；绝不直接推送到默认分支。

核心命令：

python3 scripts/validate_skill.py .
python3 scripts/export_skill_ir.py . --output reports/skill-ir.json
python3 scripts/trigger_eval.py . --cases evals/trigger_cases.json --output reports/trigger-eval.json
python3 scripts/release_check.py . --phase local --run-tests
python3 scripts/publish_skill.py /path/to/skill --dry-run

关卡阶梯

• Scaffold：有效的 frontmatter、有用的 README 引导、自然触发条件、明确的排除项。
• Production：在 Scaffold 基础上，增加接口、触发评估、输出约定、故障排查、根目录隔离和安装验证。
• Library：在 Production 基础上，增加 Skill IR、可移植性、信任、审查周期和证据材料。
• Governed：在 Library 基础上，增加权限／回滚边界、机密扫描、输出证据或保留完整性的人工证据，以及公开声明保护机制。

无法获取的遥测数据、提供方运行结果、审批、安装证明或人工审查必须保留为 missing evidence；计划中的工作不构成证明。参见 审查与发布关卡 和 资源边界规范。

输出约定

对于会生成包的请求，仅提供所选模式要求的内容：

1. 可用的 skill 目录和考虑触发条件的根目录 SKILL.md
2. 与之匹配的 agents/interface.yaml
3. 面向共享／公开 skill 的用户 README
4. Production+ 所需的触发用例和生成的触发报告
5. Production+ 所需的 Skill IR、前期成果报告和创建交接文档
6. 有助于判断、可重复性或证据的可选参考资料、脚本、输出评估、报告和清单
7. 仅在请求发布时提供发布材料

最终的创建交接文档必须列出研究过的参考 skill，提供针对候选项的经验教训，说明有意舍弃的内容和原创贡献，并将每项亮点标记为设计优势、已验证优势或假设。没有经过公平比较，绝不声称整体更优。使用 创建交接。

发布流程

1. 将 README 视为产品页面：介绍价值、安装方式、自然示例、前置条件、输出、配置、风险和故障排查。
2. 适用时，在不修改内容的情况下进行审查：python3 scripts/publish_skill.py /path/to/skill --dry-run。
3. 仅在收到明确的发布请求后，运行 python3 scripts/publish_skill.py /path/to/skill。
4. 随附的发布工具会准备 MIT LICENSE、README 和 Qiaomu 个人资料资源；解析技能与仓库标识；拦截机密信息和重复使用的发行版本；创建或复用 GitHub 仓库；并且只通过功能分支和 PR 发布。
5. 遇到冲突、检查失败或待处理、或收到修改请求时，将阻止合并。发布成功后会创建 vX.Y.Z，验证 npx skills add --list，执行隔离安装，并运行已发布版本的发布门禁。
6. 在验证远程默认版本、GitHub Release、发现情况和干净安装之前，不要报告发布已完成。

详细的 CLI 和安全决策：自包含技能发布。README 编写方法：GitHub README 手册。操作方法：SkillOps 循环。

Qiaomu 默认规范

• 优先提供实用、简洁、可发布的中文输出。
• 保留一个创作者权威源和一个根技能入口。
• 保留平台无关的源内容以及最精简的适配器。
• 公开声明必须与实际存在的触发条件、输出、运行时、安装方式或人工证据相符。
• 技能生成的任何供人查看的内容（安装页面、对话框、生成的文档），都必须先渲染并检查，再称为已验证；结构和签名检查不算数。
• 如果技能包含审美选择（文本样式、颜色、动效、布局），应先用真实的目标内容和真实的渲染器制作至少三个克制的方案原型，并排比较后再编写最终方案；切勿叠加效果来营造“设计感”。只有快速本地检查通过后，才运行耗时或依赖外部环境的门禁（公证、审查队列）。
• 采用上游创意时，应在语义层面加以借鉴并注明出处，而非照搬；先检查许可证，绝不将 copyleft（GPL）代码复制到宽松许可的软件包中。
• 技能记录的机器特定信息（钥匙串配置文件名、本地路径、已安装工具）应说明其存放位置和重建方法；绝不将机密信息和密码写入技能。
• 来自真实项目的经验教训应加入现有技能中相应的参考文档，而非新建技能。
• 视觉输出技能必须通过结构而非外观获得多样性：为每个单元设计视觉隐喻，混合不同的布局拓扑，将风格定义为叙事语法轴，并提供一个以真实失败输出为种子的可运行检查；参见 技能工程方法 的第 20 项。
• 长时间运行且会生成输出的技能必须声明带有时间估算的规模等级，提供分级示例，并设置必须达到零项的检查作为门禁；参见 技能工程方法 的第 17–19 项。

参考索引

• 设计：技能工程方法、技能原型、意图对话、非技能决策树
• 证据：评估手册、输出评估、技能 IR、治理
• 发布：自包含发布、审查与发布门禁、GitHub README、SkillOps