用途：为团队建立一套小到能记住、又能真正被执行的 filename convention（文件命名规范），解决 Report_final_v2_FINAL_johns-edits(2).docx 之类的命名混乱，让文件可排序、可搜索、可长期延续。
主要能力：
- 语法设计——按团队真实文件确定槽位顺序，典型为 YYYY-MM-DD_project_doctype_descriptor_v2，并根据检索模式决定前导槽位。
- 示例改造——用团队近期真实文件按新语法改名，给出改名前/后对照表。
- 版本规则——只用整数版本（v1、v2、v3），可加 -draft/-approved 状态标签，禁止“final”，并在备忘单上写明理由。
- 一行式备忘单——把整套规范压缩成一行，便于贴进文件夹说明。
使用方式：技能要求提供四类输入——团队实际产出的文件类型（合同、演示、导出、会议文档等）、排序需求（按时间优先还是按实体优先）、云文档情况（Google Docs/Notion 标题即文件名，平台自带版本的文档可省略版本后缀）、当前混乱样本（十几个真实文件名）。据此产出规范、示例、版本规则和备忘单。
适用场景：团队文件命名混乱、需要统一命名规则、解决 v2-final-FINAL 问题、需要跨文化无歧义的日期格式、需要文件夹自排序与快速检索时。
限制与边界：ISO 日期优先是通常做法，唯一合理例外是实体优先（如 acme_2026-07-19_...），需按团队检索模式一次性选定；槽位顺序必须固定，分隔符纪律要写明；不得编码文件夹已表达的信息；不得为团队不产出的文件设计槽位；不得大规模重命名历史文件，以免破坏链接，采用“新文件即用、旧文件触达时再改”的规则；云文档标题即名称，不加版本后缀；导出/收据类文件用日期+来源+期间。质量检查包括前导槽位是否匹配主导检索模式、分隔符纪律是否写明、“final”是否被禁并附理由、示例是否用真实文件、推行方式是否为新文件加渐进式改名。