用途：让当前仓库中的每个名称都表达统一的领域模型，覆盖目录、文件、包、模块、类型、函数、变量、测试、文档、配置、脚本与 CI，而不仅是选中文件。
主要能力：建立覆盖全部追踪与非忽略未追踪路径的覆盖台账（scripts/naming-ledger.py），记录保留/重命名/排除/阻塞等处置；先做基线与契约边界分析，再构建有证据支撑的重命名映射，按依赖波次执行，最后做最终验证与报告。允许路径移动、仓库内可控接口迁移；对导出面只有在所有消费者都在范围内且能原子迁移时才视为仓库可控。
使用方式：技能通过斜杠或美元调用注入指令；若已注入则直接遵循，不再重复调用技能工具。台账初始化示例：uv run "<skill-dir>/scripts/naming-ledger.py" init --root <repo> --ledger <scratch.json>；标记命令为 mark --ledger <scratch.json> --status <pending|retained|renamed|excluded|blocked> --path <path>，支持 --from-file dispositions.tsv、--pending-as renamed、--skip-unknown，另有 pending、refresh、summary 子命令。执行前需按仓库协调机制声明累积写入集，ai-coord 用 ai-coord start 'naming refactor' <paths>... [--recursive <dir>]...，仅在返回 READY 后继续。
适用场景：需要彻底统一命名、按领域角色而非实现细节命名、把泛化名称（如 data、info、item、manager、process、handle、utils）替换为有证据的具体名称，并让目录、文件名、主导出与模块职责对齐。
限制：不得改变功能、运行时行为、副作用、性能敏感特征和外部契约；其他 API 名、CLI 标志、环境变量、配置键、线上字段、路由、数据库名和导入路径，除非用户明确授权破坏性迁移，否则保留。不得提交、推送、发布或外部写入，除非用户或仓库指令要求。生成物通过生成器或 schema 修改后重新生成；不编辑 vendored 源码。若无可靠协调机制，必须让用户确认独占写入窗口，不能凭稳定工作树推断。仅当无待处理或阻塞路径时才算完成；无法证明行为等价或需未批准的外部契约破坏时，应报告未完成。本介绍未提供价格、平台或效果等资料。