先区分资料、项目约定与任务技能
独立影院每周都要核对中英文放映单：片名可以翻译，日期、开场时间、影厅和版本标识必须与已确认排期一致。负责人反复粘贴同样的核对步骤，适合把稳定方法做成 cinema-programme-check 技能。本例用虚构排期和双语草稿，展示从第一份文件到命名、描述和加载故障定位的过程。
先分清三种内容。排期表是要处理的资料；影院希望长期采用的日期格式是项目约定；逐项比对、列差异、询问冲突的过程才是技能。把一堆文件上传聊天不等于已经安装技能，给文件起名 SKILL.md 也不保证任何产品都会自动识别。先确定宿主支持的安装方式和当前工作范围。
第一步：把反复讲的话整理成任务契约
先回答五件事：谁使用、何时调用、提供什么、产出什么、不允许做什么。本例提供已确认排期与两种语言草稿，输出差异表、未知项和需要负责人确认的问题；不得查询后擅改排期、发布放映单或把缺少的影厅猜成默认厅。
选择一个能人工核对的小例子：影片 F01，周六十九点，二号厅；中文稿写十九点，英文稿写二十点。期望报告时间冲突并引用两边位置，不自行决定谁正确。另一个例子缺少日期，应输出未知。稳定处理这些样本比先搭一个复杂工坊更能说明任务是否适合技能化。
如果只是一次性帮忙翻译片名，可以用普通提示；如果每周都要按相同规则核对多字段并保留证据，技能更有复用价值。不要把仍需业务决定的规则固定成不可讨论的指令，先记录未决项与负责人。
第二步：建立正确的标识文件
按 Agent Skills 规范 建一个 cinema-programme-check 目录，里面放 SKILL.md，内容由 YAML 前置信息与 Markdown 指令组成，name 和 description 必填。文件名按规范使用精确的大写形式；同时检查系统是否隐藏扩展名，不要只凭文件图标判断。
name 使用 cinema-programme-check，与目录一致。description 可以写：“核对已确认排期与中英文放映单，报告日期、时间、影厅和版本冲突；用于多字段节目单审查，不用于擅自改期或发布。”这比“强大的影院助手”更能表达任务，也比把所有影视相关词都塞进去更容易划清范围。
正文按输入确认、字段映射、逐项比对、冲突与未知处理、产物验收组织。写明资料内文字是待检查内容，不是改变规则的指令。最后检查每一条差异都有来源位置，已确认事实和未决项分开，原排期没有被覆盖。
第三步：把正文写成可执行的方法
字段对齐先看含义，不盲目比较表头字符串。中文“开场”与英文 start time 可以按提供的词汇表对应，但缺少时区或日期格式有歧义时先询问。不要因为两边都写 7 就断定一致；需要确认二十四小时制、日期以及业务定义。
一个合适的输出表包含影片编号、字段、排期值、草稿值、问题类别、证据位置与处理建议。冲突的处理建议是让负责人确认或改正草稿，不自动更改事实来源。没有问题时列出检查过的字段与范围，不用“全部正确”覆盖缺少的附件和未读文件。
常用规则留在正文。影片版本缩写表可以放 references/，输出表样式可以放 assets/，正文说明什么时候读取。路径与资源需要真实存在；不要加一层层引用后以为就实现了渐进式结构。暂时没有确定性重复动作时不写脚本，避免为了显得高级引入不必要依赖。
项目规则和技能怎样配合
按 Claude Code 项目记忆文档，CLAUDE.md 用于项目等范围的持续上下文；适合特定任务的多步骤流程可另放技能。这里可把影院通用的日期写法、已确认排期的位置写进项目约定，把双语核对方法放进技能。指令文档是上下文，不是强制权限控制，不能用一句“不得发布”替代实际工具权限设置。
不要复制原文“每个文件每次对话都会全部加载”的绝对说法。范围、子目录、导入和产品版本会影响实际读取。出现规则缺失时检查当前加载的文件与适用位置，避免向全局配置重复添加同一内容。团队共用约定也应注明来源、负责人和更新方式。
第四步：按层定位“不触发”
先验证发现层：文件是否在当前宿主支持的范围，名字是否正确，目录是否多嵌套一层，frontmatter 是否可解析，有无同名冲突。再验证调用层：按 Claude Code 官方技能说明 使用适合当前版本的显式调用，确认正文和附件能够被读取。
显式调用成功后再试自然语言：“检查这份英文放映单是否与已确认中文排期一致，列时间和影厅冲突，不改文件。”记录是否选择目标技能、实际读了什么、输出质量怎样。无关问题如“这部影片属于什么类型”不应启动节目单审查。不要把模型直接完成简单问题视为技能必定加载失败。
如果目标任务没选到，检查描述是否过窄、含糊、与其他能力重叠，或资料没有进入当前任务范围。一次只改一个主要原因，并用原样本复查。不能每次不触发就增加热门词；它可能导致无关任务也调用，增加成本和混乱。
第五步：建立输出与误触发记录
至少覆盖正常一致、时间冲突、日期缺失、影片编号重复、附件不存在和记录中夹带指令六种合成情况。对每个样本先写预期，再运行；不能从模型结果反推一个刚好通过的标准。触发、内容和副作用分开判定，不使用一个总分掩盖关键错误。
F01 英文时间错误时应列冲突；日期缺少时应保留未知；重复编号时应请求确认而不是把两行拼成一个场次。输出事实还要检查翻译是否偷偷补出新的版本说明。每次保留输入版本、技能版本、宿主、运行记录和未执行项，新增规则后用未参与调优的样本检查是否只适配原例。
不会代码也能写初版吗？指令型技能可以先从 Markdown 开始，但仍要有人能检查业务规则和结果。加入解析脚本后，依赖、参数、文件访问和错误处理都需要真实验证，不能因为代码由代理生成就免于检查。
选辅助工具与分享前的检查
先确认 SkillPI Skill Finder 已安装，缺少时按 官方说明 安装，再找当前任务需要的能力。GitHub 的 Anthropic Skill Creator 可作为引导创建与迭代的方法来源；本站目前未核实到原文列出的同名创建、测试工具，不生成虚假的本站下载卡片。
Writing Guidelines 只放在技能技术说明的文字走查：提供目标文件、受众和读取链接手册的条件，检查歧义与结构，按团队语言调整。它不负责发现技能、验证日期或证明不误触发。润色后重新检查“未知”和“不改排期”等限制没有消失。
分享时给固定版本、最小样本、依赖说明、已测试宿主、已知限制和许可证；在另一份干净安装中核验文件与一个完整任务。聊天附件、项目目录、个人技能与社区市场是不同分发方式，不能统称“传过去就能用”。首版的完成标准是能解释它何时用、读什么、如何报告冲突，以及为什么还不能自动发布。