add-skill 用于在 paldom/noslop 仓库中按“评测优先”流程编写或改进一个生产级 Agent Skill，产出的技能放在 skills/<name>/ 目录。开始前需每会话阅读一次 docs/skill-authoring.md 与 docs/evals.md，它们是该流程执行的规则依据；以 /add-skill <args> 方式调用时，$ARGUMENTS 视为技能名或待界定的想法。
不适用场景：创建新的技能仓库（应在其上层工作区进行）；hooks、CI、校验器、文档等基础设施改动（按普通编辑与 PR 级别审查处理）；仅重复模型已擅长之事的“技能”不应构建，技能须修复具体观察到的失败。
流程：一、界定范围，用一句话说明技能做什么及修复的具体失败，若需“and”则拆分为多个技能并逐个处理，并检查 skills/ 与 README 目录是否存在重叠，调整范围或采用不冲突表述。二、收集资料，递归读取 .local/ 全部内容，再通过网页检索获取最新事实、官方文档与既有做法，对关键事实用一手来源核验，有争议或高风险事实可借 /cross 交叉验证；核验后的事实以清理过的受跟踪文件放入 skills/<name>/references/，不得在技能中引用 .local/ 路径。三、先写评测，按 docs/evals.md 创建 skills/<name>/evals/evals.json，含至少 8 条 should_trigger（变化正式度、错别字、简洁度）、至少 8 条 should_not_trigger（共享关键词的近义误触发），以及 3–5 条带通俗预期行为断言的质量用例；写不出则说明范围不清，回到第一步。四、起草 SKILL.md，frontmatter 的 name 与文件夹名一致，description 单行、第三人称，含[做什么]+[何时使用…]+[不适用…]，150–400 字符，前约 120 字符放触发关键词；正文按 docs/skill-authoring.md 结构：目的→何时/何时不用→编号流程→输出规范→注意事项→指引，控制在 500 行以内，确定性步骤放 scripts/（失败时非零退出），长材料放 references/ 并附目录。五、验证，make check 须以 0 退出，修复所有错误并分类处理每条警告。六、触发自测，对至少 3 条 should-trigger 与 2 条 should-not-trigger 提示显式推理：仅凭 description（而非正文）是否能相对目录中其他技能把该提示路由至此；应改 description 而非改评测，并建议用户对风险最高的用例做 2–3 次新会话探测。七、登记，更新 README 目录表中的该技能行、添加 CHANGELOG.md 条目，并放入 skills.sh.json 中恰好一个分组（一句话的分组描述即该仓库的 skills.sh 列表文案），复查同级技能描述是否产生新重叠；不要提交或推送，全部改动留给所有者审阅。
完成标准：skills/<name>/ 含 SKILL.md 与 evals/evals.json（按需加 scripts/references）；make check 0 错误；README 目录与 CHANGELOG 已更新；提供目的、触发短语示例、已知限制三行摘要。
注意事项：description 必须保持在一个物理行，多行值在部分运行时加载失败且校验器会阻止，不得绕过校验器；不要把失败的评测提示原样粘贴进 description（过拟合），应归纳缺失的动词/名词；过度触发时根据实际误判重叠添加针对性的“Not for …”名词短语，不要删除正向触发；模型升级会改变路由，摘要中需提示在下次模型发布后重跑评测。