用途：把命名当作系统模型的一部分，而非同义词练习。好名字应让目标读者知道概念是什么、由谁拥有、与邻近概念的区别，无需重建隐藏上下文。
两种模式：快速命名针对单个局部变量、函数、prop、文件或概念，给出三到五个候选、推荐一个并简要说明决定性区别；命名审计针对公开或跨模块词汇、多个相关名称或有迁移影响的改名，构建词汇表、追踪调用流并返回按优先级排序的改名建议。不要对局部标识符问题强加审计级推理。
决策规则：结合上下文命名，阅读声明、调用方、邻近概念、层次、受众与生命周期，不凭孤立片段臆造全局模型；选择视角，产品名描述用户意图，领域名描述持久概念，运行时名描述执行职责，适配器名描述跨越的边界，视角保持稳定直到真实边界改变它；保留决定性信息，仅当周围表达式承载省略含义时才缩短，公开与跨模块名通常比局部名更明确；一个概念一个词，同一概念保持同一术语，不同概念不共用方便的通用词；命名所有权而非附带机制，Manager、Service、Helper、Data、Info、Context、get、build 仅在准确表达局部模型时可接受；把命名摩擦当作证据，若每个候选都需一段解释，概念可能混合了职责或视角，应建议澄清设计而非更多同义词。公开或跨模块决策需要扩展上下文、调用流、对称性、生命周期或迁移检查时，阅读 references/principles.md。
工作流：快速命名需说明概念、读者、层次与最近竞争术语，检查用户提供的周围代码或文本，生成三到五个有实质差异的候选，推荐一个并解释最接近的替代为何落选，仅在证据确实使命名不稳定时标记设计问题。命名审计需阅读相关声明、调用方、契约、文档及持久化/传输名称，映射参与者、概念、生命周期状态、层次词汇与过载术语，识别错误视角、信息丢失、过时词汇、冲突与不一致，优先处理公开/API/领域名再处理小局部名，对每个改名说明旧到新、证据、概念修复、受影响面及真实契约是否要求兼容，并将推荐词汇与迁移计划分开。
输出：使用 references/output-template.md 中匹配的模式。快速回答保持对话式且紧凑；审计必须包含证据与迁移范围，但无需暴露表演性的推理链，只解释阅读后影响推荐的变化。
不适用场景：名称别扭源于模块所有权或抽象错误时用 hai-architecture；判断字段是否应存在或归属何处时用 entity-model-auditor；用户想要大胆方向改变而非名称时用 geju；范围是整个 React 组件 API 而非单个标识符时用 hai-architecture。本技能不作为大小写检查器、僵化命名标准或同义词生成器，项目约定约束答案，但概念清晰度决定答案。