Metadata Naming
Turn loose filename habits into a stable naming standard that is easy to read, sort, parse, and reuse.
Use This Standard
Follow this split by file purpose:
- - Use stable identity naming for long-lived entries that are updated in place.
- Use timestamp naming for snapshots, archives, exports, and reports.
- Prefer ASCII, no spaces, and fixed separator rules when filenames will be processed by scripts or moved across systems.
Core Metadata Blocks
Use these blocks in a fixed order when a filename needs richer metadata:
- - time
- prefix
- title
- version
- tags
- sourceorauthor
- note
Not every block is required. Keep only the fields that improve retrieval or automation.
Two Modes
Relaxed mode
Use for human-managed documents where readability matters more than strict parsing.
Conventions:
- - Chinese or mixed-language titles are allowed.
- Spaces are allowed when the surrounding system tolerates them.
- Typical visual markers:
- time:
(2026-03-11) or
(20260311-093500)
- version:
(v1.2.0)
- tags:
#tag
- source or author:
@name
- note: INLINECODE5
Example:
CODEBLOCK0
Strict mode
Use by default for standards, skills, inventories, generated files, syncable folders, and anything a script will read.
Conventions:
- - ASCII only
- no spaces
- top-level separator: INLINECODE6
- intra-block separator:
- or INLINECODE8 - lowercase slug-style titles unless there is a strong reason not to
General template:
CODEBLOCK1
Examples:
CODEBLOCK2
Default Rule For Long-Lived Entries
For catalogs, inventories, and canonical records, prefer stable filenames over timestamped filenames.
Use this template:
CODEBLOCK3
Examples:
CODEBLOCK4
Use this rule when the content is refreshed in place and the filename should not drift over time.
Default Rule For Snapshots And Reports
Use timestamp-first filenames for time-series artifacts.
Templates:
CODEBLOCK5
Examples:
CODEBLOCK6
Block Rules
Time
- - Use
YYYYMMDD for day-level tracking. - Use
YYYYMMDD-HHMMSS for run-level uniqueness. - Put time first when sort order matters.
Prefix
- - Use short taxonomy values such as
repo, skill, app, doc, snapshot, report. - Keep the vocabulary stable once chosen.
Title
- - Make this the main identity.
- Prefer short, stable, searchable slugs.
- Move extra description into tags or notes.
Version
- - Use semver when available:
v0.1.0, v2.3.4. - Omit the block when versioning is irrelevant.
Tags
- - Use compact, low-noise tags.
- Join multiple tags with
. or - inside the same block.
Source Or Author
- - Use the source system, publisher, owner, or author when it improves retrieval.
- Examples:
github, brew, workspace, openclaw, vendor-name.
Note
- - Keep it short.
- Do not put long prose into filenames.
- Use only when the note materially changes retrieval value.
Standard Principle
Use fixed-order metadata blocks. Use stable identity filenames for long-lived entries and timestamped filenames for snapshots. Default to ASCII, no spaces, __ between blocks, and - or . inside blocks so names stay sortable, parseable, and portable.
References
Read references/standard.md when you need the normalized standard, examples, and decision rules in a reference-friendly format.
元数据命名
将松散的文件命名习惯转变为稳定、易读、易排序、易解析且可复用的命名标准。
使用此标准
按文件用途进行如下划分:
- - 对原地更新的长期条目使用稳定标识命名。
- 对快照、归档、导出和报告使用时间戳命名。
- 当文件名将被脚本处理或在系统间迁移时,优先使用ASCII字符、无空格和固定分隔符规则。
核心元数据块
当文件名需要更丰富的元数据时,按固定顺序使用以下块:
并非每个块都是必需的。只保留能改善检索或自动化的字段。
两种模式
宽松模式
用于人工管理的文档,可读性比严格解析更重要。
约定:
- - 允许使用中文或混合语言标题。
- 当所在系统允许时,可以使用空格。
- 典型视觉标记:
- 时间:(2026-03-11) 或 (20260311-093500)
- 版本:(v1.2.0)
- 标签:#tag
- 来源或作者:@name
- 备注:¬e
示例:
text
(2026-03-11)Favorites Curator(v0.1.0)#skill#favorites@workspace&initial publish
严格模式
默认用于标准、技能、清单、生成文件、可同步文件夹以及任何脚本会读取的内容。
约定:
- - 仅使用ASCII字符
- 无空格
- 顶级分隔符:
- 块内分隔符:- 或 .
- 除非有充分理由,否则使用小写短横线式标题
通用模板:
text
YYYYMMDD[-HHMMSS]前缀标题版本标签来源备注.扩展名
示例:
text
20260311skillfavorites-curatorv0.1.0favorites.catalogworkspace.md
20260311repoopenclaw-backup-toolv0.1.0backup.toolgithub.md
20260311appcodexv0.112.0cli.aibrew.md
长期条目的默认规则
对于目录、清单和规范记录,优先使用稳定文件名而非带时间戳的文件名。
使用此模板:
text
<数据类型><来源名称><短横线式>.md
示例:
text
skillworkspacefavorites-curator.md
repogithubopenclaw-backup-tool.md
appbrewcodex.md
当内容原地刷新且文件名不应随时间变化时,使用此规则。
快照和报告的默认规则
对时序性工件使用时间戳优先的文件名。
模板:
text
YYYYMMDDreport主题.md
YYYYMMDD-HHMMSSsnapshot主题.json
示例:
text
20260311reportfavorites-digest.md
20260311-095914snapshotfavorites.json
块规则
时间
- - 按天追踪使用 YYYYMMDD。
- 按运行级别唯一性使用 YYYYMMDD-HHMMSS。
- 当排序顺序重要时,将时间放在首位。
前缀
- - 使用简短分类值,如 repo、skill、app、doc、snapshot、report。
- 选定后保持词汇稳定。
标题
- - 使其成为主要标识。
- 优先使用简短、稳定、可搜索的短横线式。
- 将额外描述移至标签或备注中。
版本
- - 可用时使用语义化版本:v0.1.0、v2.3.4。
- 当版本无关时省略该块。
标签
- - 使用紧凑、低噪音的标签。
- 在同一块内使用 . 或 - 连接多个标签。
来源或作者
- - 当能改善检索时,使用来源系统、发布者、所有者或作者。
- 示例:github、brew、workspace、openclaw、vendor-name。
备注
- - 保持简短。
- 不要在文件名中放入长篇说明。
- 仅在备注能实质性改变检索价值时使用。
标准原则
使用固定顺序的元数据块。对长期条目使用稳定标识文件名,对快照使用带时间戳的文件名。默认使用ASCII字符、无空格、块间用、块内用-或.,使名称保持可排序、可解析和可移植。
参考资料
当需要以参考友好的格式获取规范化标准、示例和决策规则时,请阅读 references/standard.md。