用途
该技能用于为当前正在开发的游戏构建一个小型音频子系统。它要求从游戏玩法中推导出音乐与声音身份，然后在宿主引擎中实现，并带有明确的类硬件约束和可机器校验的契约。
核心规则
- 选择声音前先检查游戏。应基于动作、后果、危险、节奏、回合和吸引模式行为来设计，而不是基于预设目录。
- 静音和无BGM是有效结果。不要强行给节奏已由移动或事件声音承载的游戏添加连续音乐。
- 将游戏逻辑保持在事件边界之后：游戏代码发出抽象名称；音频总线通过活动游戏套件解析它们；适配器播放解析后的程序数据。
- 将命名程序保存在每游戏套件中，绝不放在共享合成器中。
- 在宿主允许时，将BGM提示、音效和提示音表示为确定性数据。使时长、声部使用、循环边界和变化种子可测量。
- 在编写套件前固定并钳制原语集和主链。按游戏重新组合固定集合；不要仅为挽救一个声音而添加新的合成原语。
- 区分“时代灵感”与“硬件忠实”。仅当命名目标和已验证的能力/时序约束在范围内时，才声称硬件保真度。
- 在游戏负载下统一调校同类声音。一个孤立的好声音仍可能组成糟糕的套件。
工作流
1. 发现宿主与玩法
阅读仓库说明、游戏规则、运行时入口点、事件/状态转换、现有音频代码、测试和构建命令。识别：
- 引擎和可用音频API；
- 是否已存在音频总线、合成器、混音器或资产管线；
- 需要即时反馈的玩家动作和后果；
- 值得提示音的稀有柜体/状态时刻；
- 可驱动强度或编排的玩法变量；
- 吸引/演示模式及其声音策略。
当现有声音架构已提供所需边界时，保留它。修复或扩展它，而不是安装并行音频栈。
2. 冻结音频契约
阅读 hardware-profiles.md。选择并记录：
- 保真度级别：时代灵感或硬件忠实，后者需命名目标；
- 原语集和物理/逻辑声部限制，以及同一tick内两个音符起始落在同一声部上的策略；
- BGM模式：无、固定循环、种子循环、分层自适应或事件音乐；
- 通道仲裁和闪避策略；
- 确定性种子所有权和重放行为；
- 时长、步数、密度和循环尾部预算。
对于游戏自有音频的浏览器目标，还需冻结宿主可见性策略。隐藏页面必须及时静音或暂停输出；可见页面只能恢复当前游戏状态仍请求的连续音频。在两种转换中保留用户静音、游戏暂停/结束、演示声音和浏览器激活门控。
在此契约稳定之前不要编写声音。仅当玩法证据表明所选能力模型无法表达所需反馈时，才在之后更改它。
3. 映射玩法时刻
将每个候选时刻分类为sfx、jingle、bgm或none。包括预期频率、优先级、并发性和演示行为。编码前写一行目标，例如：
- player:fire — 干燥窄脉冲，即时起音，在每秒八次射击下可读
- enemy:split — 两步向下金属撕裂声，区别于玩家受伤
- jingle:clear — 紧凑上升乐句，庆祝但短于准备节奏
当语义正确时，优先使用共享柜体词汇（coin、start、warning、jingle:clear）。当游戏特定名称使游戏代码更清晰时，使用它们。
4. 构建或适配事件边界
实现运行时时阅读 audio-contract.md。 保持此依赖方向：
game -> emit(event) -> bus -> kit/alias resolution -> adapter -> synth/output
将静音/演示门控、每帧重复上限、优先级和事件日志放在总线中。提供静音/模拟适配器，以便无头测试可以断言解析后的程序ID而无需音频输出。在浏览器目标上，在宿主边界绑定一次 visibilitychange 并将其转发到总线或适配器；不要在游戏代码中重复生命周期监听器。当固定引擎或库已拥有此生命周期时，将宿主提供的音频行为视为权威。
5. 编写BGM
当所选BGM模式不是none时，阅读 composition-workflow.md。应用通用管线：
- 规划意图、形式、速度、循环长度和声部角色；
- 选择或生成动机/模式；
- 将角色实现到受限声部上；
- 应用音色技术而不破坏声部预算；
- 最终确定确定性时间线和循环诊断。
优先使用短小可识别的单元、有意的休止和响应玩法的密度，而不是现代完整编排。保持变化在结构上足够重要但有界，使提示保持身份。
6. 编写音效和提示音
阅读 sound-effect-workflow.md。将同类声音设计为一个套件，然后从固定原语集编写它们。对重复反馈使用短单次音，对稀有状态变化使用短乐句。起始上限：
- 音效时长：<= 0.6秒；
- 提示音时长：<= 1.6秒；
- 每程序步数：<= 24。
仅在冻结契约中覆盖这些，并为新预算添加测试。保持柜体钟声略微落后于前景游戏；绝不要让提示音掩盖控制反馈。
7. 集成与仲裁
在玩法源处连接抽象事件。避免在实体、场景或规则代码中调用合成器。在测试密集游戏前定义碰撞策略：
- 保留玩家控制反馈和危险警告；
- 保留因果关系所需的后果；
- 闪避或丢弃奖励/环境声音；
- 在静音必要音效前减少BGM装饰。
按调度器tick解决碰撞策略，而不仅按音符：在tick内按优先级顺序分配声部，并对失败的请求应用声明的同tick策略。同一tick内单声部上的两个起始无论宿主如何混合都是一个声音，每帧重复上限不会改变这一点。
暴露最小有意义的控制面，通常为零到两个连续玩法轴。钳制它并在套件内推导速度、密度、音域、编排、音色或变化意图。仅当它代表独立玩法变量时才添加另一个暴露轴；绝不因为控制越过阈值而切换到无关的声音身份。
8. 完成前验证
阅读 verification.md。要求所有适用门控：
- schema、别名、ID、时长、步数、声部限制和事件覆盖检查；
- 固定选项和种子的确定性重放；
- 匹配的音符起始/释放和有界循环尾部；
- 对发出事件、静音/演示门控和重复上限的模拟适配器断言；
- 游戏自有浏览器音频的宿主可见性断言，包括隐藏发射抑制和状态正确恢复；
- 渲染或捕获输出测量静音、削波、起音和尾部，级别在每个共现组内比较，而不是整个游戏；
- 在真实引擎或浏览器中的运行时冒烟测试；
- 在现实最大事件密度下的压力测试；
- 生成BGM/音效变化的多种子比较；
- 在实际游戏中对完整同类套件进行低音量试听。
当项目可以发出 audio-contract.md 中描述的通用清单时——从运行时套件数据派生，绝不手工维护在旁边——运行：
node <skill-dir>/scripts/validate-audio-kit.mjs <manifest.json>
通过的运行会打印它读取的工件和检查的计数。如果它不打印任何内容，则它没有运行；在相信退出代码之前修复调用。
当维护或修改捆绑验证器时，也运行：
node <skill-dir>/scripts/validate-audio-kit.mjs --self-test
否则将相同不变量移植到项目的原生测试套件中。如果第二个清单会成为类型化运行时数据的未同步重复，则不要要求它。
完成报告
报告实现的事件边界、硬件配置、BGM模式、事件覆盖、生成的程序/提示计数、仲裁策略、验证命令和剩余试听风险。明确说明音频是时代灵感而非精确硬件仿真。
参考路由
- 选择约束时阅读 hardware-profiles.md。
- 构建总线、套件、适配器、模拟或验证清单时阅读 audio-contract.md。
- 实现BGM时阅读 composition-workflow.md。
- 将音效或提示音作为集成套件的一部分设计时阅读 sound-effect-workflow.md。
- 最终验证和交接前阅读 verification.md。