用途：基于 EARS（Easy Approach to Requirements Syntax）把模糊、口语化或有歧义的需求改写为清晰、无歧义、可测试、可评审的规格陈述，并在需要时给出句式选择、拆分建议和校验意见。
主要能力与模式路由：提供六种 EARS 模式判断与模板——Ubiquitous、Event-Driven（WHEN）、State-Driven（WHILE）、Unwanted Behavior（IF-THEN）、Optional Feature（WHERE）、Complex。按决策流程选择：有触发事件且有持续状态用复合型；仅有事件用事件驱动型；无事件但有持续条件用状态驱动型；错误/故障/边界场景用非期望行为型；依赖功能或配置用可选功能型；否则用普适型。
使用方式：先识别系统名称、动作对象、触发事件、状态条件、异常条件与约束，标记模糊词、多动作混写、未量化约束、缺失主语等问题，判断是否需拆分为多条需求，进入模式路由后按模板改写，补足可测试性（时间、次数、范围、失败处理、提示内容），缺失时列出待确认问题，并按固定结构输出模式判断、改写前后对照、拆分说明与审查意见。校验要求每条陈述恰好一个 shall，使用可衡量可验证语言，EARS 关键字全部大写。
默认输出约定：对外输出默认使用中文句式，不输出 WHEN、WHILE、IF、THEN、WHERE、shall 等英文关键词，采用“当…时”“在…时”“如果…，则…”“应”等表达；英文关键字仅用于模式讲解、分类说明、内部讨论或用户明确要求保留英文模板的场景。
文件路由：进入技能先看 SKILL.md；判断是否适用看 references/ears-usage-guide.md；中文输出看 references/ears-chinese-output.md；模式细节看 references/ears-patterns.md；输出结构看 references/ears-output-template.md；编写规则看 references/ears-writing-rules.md；案例看 examples/ears-examples.md。
适用场景：需求规格改写与审查、把需求转成 EARS 规格，或与 USDM 配合时在规格级别（SPEC-NNN）编写每条规格。限制：如无法明确主语、触发条件或响应动作，应停止硬改并转为输出待确认问题；不擅自补充业务规则。