把重复工作整理成一个小而专注的 Skill

每次发布文档都要检查链接、生成目录、确认页面标题；每次处理表格都要统一列名、核对重复项、输出结果。如果这些步骤已经稳定，可以把它们整理成 Skill，减少重复说明。

先确认流程真的值得固化

适合沉淀的工作有明确输入、相对稳定的步骤和可检查的结果。一个还在不断变化的需求，先保留为任务说明更灵活。不要把“处理所有开发工作”写成一个技能，那样很难判断什么时候应该使用它。

官方文档把 Skill 定义为包含 SKILL.md 的目录，可附带脚本和参考资料；文件需要 name 和 description。Codex 会先看到名称和描述，在选中技能后读取完整说明，因此描述中的适用范围很重要。[1]

描述清楚什么时候触发

“帮助用户完成任务”过于宽泛。更具体的描述是：“检查静态博客的内部链接、文章元数据与站点地图，用于发布前验证；不负责上传或发布。”它告诉使用者技能的输入、任务和边界。

这也是给未来的自己留下的一张说明卡。几个月后回来看，仍应能快速判断这个 Skill 是否适合当前任务。

把流程写成可执行的说明

---
name: blog-release-check
description: 检查静态博客的内部链接、文章元数据与站点地图，用于发布前验证，不执行上传或发布。
---

1. 确认待检查的输出目录和站点域名。
2. 列出 HTML 页面，检查标题、描述与 canonical。
3. 检查站内链接和资源路径，报告不存在的目标。
4. 对照文章列表检查 sitemap.xml 和 RSS。
5. 输出通过项、失败项和未完成检查。
6. 保留源文件，仅在用户要求修复时修改。

这是一个可以按项目约定调整的完整起点。文件放入仓库的 .agents/skills/blog-release-check/ 目录后，可在支持本地技能的 Codex 环境中发现。具体加载范围以当前客户端文档为准。

确定性的检查交给小脚本

路径是否存在、XML 是否可以解析、标题是否重复，适合交给脚本。文案是否清楚、信息层级是否合理，则需要结合页面和目标判断。两者分工后，Skill 的主文件可以保持简洁。

脚本应明确失败退出状态，不要在发现问题后仍输出“全部通过”。如果脚本会写文件，应把修改范围、备份方式和恢复方法写清楚；只读检查则保持只读。

验证触发，也验证结果

准备两类请求：应该触发的“帮我检查博客发布内容”，以及不应该触发的“帮我写一篇文章”。再用一个包含坏链接的目录确认检查能够失败，用正常目录确认它不会误报。

一个可靠的 Skill 不只是保存一段提示词。它让输入、行为和结果保持一致，同时允许在流程改变时被小范围更新。先做小，再随着真实使用补足规则，维护起来通常更轻松。