Jak używać
- Skopiuj polecenie instalacji i sprawdź źródła przed instalacją we własnym środowisku agenta.
- W oryginale sprawdź wymagane narzędzia, dane dostępowe i obsługiwane środowiska.
- Opisz dane wejściowe i oczekiwany rezultat; porównaj wynik ze źródłami.
npx skills add https://github.com/jtydhr88/music-composition-skills --skill mc-workflowPrzed rozpoczęciem
- Instalacja nie obejmuje subskrypcji modelu, limitu API ani uprawnień do plików.
- Gwiazdki i instalacje pokazują aktywność, a nie niezależny test jakości lub bezpieczeństwa.
Treść z repozytorium z zachowaniem nagłówków, przykładów, kodu, tabel, linków i obrazów.
作曲编曲工作流与路由（Workflow & Routing）
任何作曲/编曲请求先读这个 skill，再决定读哪个别的。
这个库的产出不是音频，是一份 ARR-SPEC（编曲规格单）。 音频由后端生成，规格单决定它长什么样、以及怎么验收它。
本库的根本立场：AI 味不是音色问题，是没有人做过选择。 整套流程就是一台强迫做选择的机器。
0. 三十秒定位：我该去哪
| 你现在要做的事 | 去 |
|---|---|
| 从零开始一首歌 | §1 阶段表，从 S0 走。★ S2a 必须先读 mc-development 再填 material 与 form[].development，只照 schema 的字段说明填会把每段写成一个新画面 |
| 已有 brief，要出规格单 | §1 的 S1–S4（S2 现分 S2a 材料与发展、S2b 和声） |
| 规格单写完了，要生成 | §1 的 S5 ＋ mc-render-compile |
| 生成回来了，不对劲 | §4 诊断路径 |
| 不知道某个问题归哪个 skill | §2 全库边界表 |
| lint 不过 | §3.2 |
| 要交给作词、混音、剪辑等别的部门 / 别的人 | §5 对外接口 |
| 要检验：选的 skill 对不对、两版哪个好、后端照做没有 | §6 三个检验办法 |
| 要混合两种风格（rap + 中国风、city pop + EDM…） | ★ §2.4 |
1. 阶段表 S0–S7
每个阶段有明确的产出物和门禁。门禁不过不许进下一阶段。
| 阶段 | 做什么 | 产出 | 门禁 | 主用 skill |
|---|---|---|---|---|
| S0 立意 | 把 brief 变成"只干一件事" | intent 四项 | 四项齐全，borrow 不许只写歌名 | 本 skill §3.1 |
| S1 骨架 | 定调、拍、速度、曲式表 | meta + form | 段落首尾相接；不许全是 8 的倍数 | mc-form、mc-harmony、mc-arrangement-arch |
| S2a 材料与发展 | 定主题动机、原始陈述在哪段、每段拿它做什么 | material + form[].development | 先读 `mc-development` 再填；motif 与 stated_in 非空；每段 development 都填；填 new 的段不过半 | mc-development、mc-melody |
| S2b 旋律与和声 | 写主旋律、和声进行、必要的对位 | form[].harmony + harmony_letters | 双记号都要有；至少一段有调外和弦 | mc-melody、mc-harmony、mc-progressions、mc-modulation、mc-counterpoint |
| S3 编制 | 谁在场、什么时候进退、占什么频段 | arrangement 全段 | 能量曲线必须有下降；至少一件乐器提前退场；至少一个减法事件 | mc-arrangement-arch、mc-orchestration、mc-texture-layering、mc-rhythm-section、mc-sound-design |
| S4 演唱与混音意图 | 怎么唱、声场怎么摆 | vocal + mix_intent | 力度逐段不同；副歌逐遍有变化；宽度至少两种取值 | mc-vocal-direction、mc-mix-intent |
| S5 编译 | 规格单 → 各后端输入 | render.* | 按 §3.0 的 20 条自查一遍；不过的条目改掉或写明理由 | mc-render-compile、mc-symbolic-score |
| S6 生成 | 跑后端，取多版 | 音频 | 按 backends.yaml 的 honors 决定哪些字段可指望 | mc-render-compile |
| S7 验收 | 先算再听 | 照做率 + AI 味旗标 | 先分开看两件事：后端照做了没有、成品有没有机器指纹；耳朵在这之后介入 | mc-ai-tell-audit |
1.1 ★ 三条不许跳的顺序
- `intent` 不齐不许写 `form` —— 这是整套流程唯一的硬门禁
- 17 条不过不许编译 —— 不过说明规格没写完，不是挑刺。★ 按 §3.0 逐条自查，不要为此写 lint 脚本
- 照做率不过不许用耳朵返工 —— 先改规格重生成，耳朵是最后一小步
第 3 条最容易破。"我听着不对，我调一下混音"—— 那一刻你就从规格驱动掉回手感驱动了， 而手感驱动的产物无法复现、无法 AB、无法积累。
1.2 耳朵怎么介入（S7 之后）
照做率过关后才听，而且要：A/B 打乱 → 成对比较 → 同一对听两遍看结论稳不稳。 两遍不是多余的谨慎：听觉系统会在重复暴露里改变自己的处理策略，同一段声音第二次听可能得到不同的结论，这类判断天然容易不可重复（p0251-p0252）。结论两遍不一致 = 这个差异不存在，别改。
如果两次听中间隔的时间较长，还要防一种相反的偏差：耳朵会对持续暴露的音色变化逐渐适应，越听越觉得两版差不多，容易把真实存在的差异误判成"不存在"（p0342）。两次判断之间留出间断，别来回连着切，能同时防住这两头。
2. 全库边界表
每一个决策只有一个 owner。 拿不准就查这张表。
2.1 按问题查
| 问题 | Owner |
|---|---|
| 这首歌要干什么 | 本 skill S0 |
| 用什么曲式、段落多长 | mc-form（乐理） ＋ mc-arrangement-arch（非对称与能量） |
| 旋律怎么写、可唱性 | mc-melody |
| 和弦怎么选、怎么配 | mc-harmony |
| 查一个现成进行 | mc-progressions |
| 怎么转调 | mc-modulation |
| 节奏型是什么 | mc-rhythm-groove |
| 声部怎么独立、怎么避免平行 | mc-counterpoint |
| 一个动机怎么长成一段、一段怎么长成一首 | mc-development（L1）；旋律本身在 mc-melody，段落功能在 mc-form |
| 乐器什么时候进、什么时候退、能量曲线 | mc-arrangement-arch |
| 用哪件乐器、混合音色 | mc-orchestration |
| 频段怎么分、谁和谁抢、前中后景 | mc-texture-layering |
| 打得像不像人、贝司和底鼓怎么配 | mc-rhythm-section |
| 合成器音色怎么做 | mc-sound-design |
| 人声怎么唱、和声怎么加 | mc-vocal-direction |
| 声场怎么摆、谁给谁让路 | mc-mix-intent |
| 这个风格该怎么做 | mc-style-*（L3） |
| 规格单怎么变成 prompt | mc-render-compile |
| 要出 ABC / MIDI / MusicXML | mc-symbolic-score |
| 生成的东西哪里像 AI | mc-ai-tell-audit |
| 找一个真实作品的拆解 | mc-case-studies |
2.2 六组最容易混的分界（★ 逐条记住）
| A ⇄ B | 分界线 |
|---|---|
mc-form ⇄ mc-arrangement-arch | form 管曲式是什么（乐理），arrangement-arch 管这首歌为什么这么切（决策） |
mc-rhythm-groove ⇄ mc-rhythm-section | groove 管节奏本身是什么，rhythm-section 管怎么把它打出来像人 |
mc-texture-layering ⇄ mc-mix-intent | texture 的解法是"改写"（换音区/减音符/交替），mix-intent 的解法是"改混"（让频/侧链/动态）。能改写解决的不许留给混音 |
mc-orchestration ⇄ mc-sound-design | orchestration 管真实乐器与混合，sound-design 管合成音色的设计 |
mc-sound-design ⇄ 声音（音效、拟音） | 本库的 sound-design 是乐音音色；影视意义的"声音设计"（音效/拟音/空间）是声音这一职能的事，同名不同事 |
| 本库 ⇄ 作词 | 词的一切是作词的事，包括词曲对齐（符割り、字余り、倒字、协音）——那是词的工序；本库读同一首歌的歌词（meta.upstream.lyrics），共享六字段谁定谁读见 §5.1 |
2.4 ★ 风格混合：不是调匀，是分维度签字
★ 边界是分工，不是禁令。 隔离的目的是让每个选择都有人签字，不是把风格锁死。写 J-Pop 规格时顺手借一个 city pop 的裏和弦、写中国风时低音走了 hip-hop 的 808——只要在style_layers/fusion_note里写一句为什么，就是合法的混合；轻微的串音完全可以接受，真正要防的是「没人选、默认长成那样」。
污染隔离 ≠ 禁止混合。 两者的区别只有一条：
混合是写下来的选择；污染是没人选。 一首 rap + 中国风的歌（如汪苏泷《桃花扇》）完全成立——前提是规格单说得出哪个维度归谁。
做法：meta.style_layers 填一张分工表（schema §1.1.1），一个 base + 若干 overlay， 每层写明它 owns 哪些维度：
| 维度 | 《桃花扇》式的分法（示意） |
|---|---|
harmony、melody、color_instruments | 中国风（五声旋律、民乐采样做色彩层） |
（完整分工见 mc-style-hiphop §8.1） | |
groove、low_end、vocal_delivery_verse | hip-hop（律动、808、主歌 flow） |
vocal_delivery_chorus、form | 中国风副歌唱、结构仍是主副歌 |
★ owns 是封闭集合，只能从这十四个里选： harmony melody groove low_end fill_policy instrumentation color_instruments timbre arrangement_hook vocal_delivery（可拆成 vocal_delivery_verse / vocal_delivery_chorus） form mix。 要分配的东西不在表里，归到最接近的那个，并在 fusion_note 里写一句说明，不要自造名字。
三条规则（第 18 条自查）：
- 每个维度只有一个 owner——两层都声称
groove= 两种默认值叠在一起，谁也没选 - 每层至少拥有一个维度——否则它只是被读了，没起作用
- `fusion_note` 一句话说这个组合为什么成立——说不出就是硬凑
怎么用各 L3 的移植表：overlay 搬进来的，正是它移植表里标"不可搬／会被认出来"的项—— 那就是你要的辨识度。但每搬一项都要在 owns 里签字，并看 base 风格的移植表是否允许让出那个维度 （例如 city pop 的移植表说"抢拍贝司可搬"，那 base 是 city pop 时 groove 让给别人就要三思）。
路由上：混合 brief 应读全部被点名的 L3 skill，这不算污染； 读了没被点名的风格才是。
2.3 不归本包的东西
| 内容 | 归哪个职能 |
|---|---|
| EQ 频点、压缩比、混响参数、总线链、母带 | 声音（混音、母带）；本包只给 mix_intent 这份意图 |
| 影视音效、Foley、环境声、空间设计 | 声音（录音、音效） |
| 跟画面走的配乐结构、cue sheet、spotting | 配乐（为画面写音乐） |
| 歌词写作、押韵、意象、叙事人称 | 作词。★ 词的三种情况：用户没提词 → 可出可不出，出了就在 checks.exemptions 记一条"词未经作词工序"；用户明确要纯音乐 / 轻音乐 / 器乐 → 一个字都不加，vocal 留空；用户明确要词 → 必须出词，有同一首歌的歌词（meta.upstream.lyrics）就照它，没有就按本库的 mc-vocal-direction 写并记豁免。只示意人声节奏（rap 的 flow、副歌字数）时用占位音节（da-da / 拉拉）或 X 标记 |
| 商业流程（compe、仮歌、版权、分成） | 不做 |
3. ARR-SPEC：本库唯一的交接物
完整规范在本 skill 目录下的 [ARR-SPEC.schema.md](ARR-SPEC.schema.md)（v1.0），空模板 [ARR-SPEC.template.yaml](ARR-SPEC.template.yaml)，后端能力档案 [backends.yaml](backends.yaml)。 ★ 写规格单前先 Read 模板，照它的字段名填——实测不看模板的话 agent 会自己发明字段（intent.scene/borrow、push_pull 写成字符串）。 （这三个文件就是本库随包交付的全部"格式"——除了 Read 它们，不需要任何工具。）
3.1 一物四用
| 用途 | 怎么用 |
|---|---|
| 对外交接 | 给混音师、乐手、作词和别的部门看的，是这一份（§5） |
| AB 测试对象 | 改一个字段 → 重生成 → 比对。变量可控 |
| 编译源 | mc-render-compile 把它编译成 Suno prompt / YuE 输入 / MIDI |
| 验收基准 | 生成回来的东西逐字段对照它，看后端照做了多少 |
★ 第二和第四条是关键：没有规格单就没有可控实验，没有可控实验就只能靠感觉。
3.0 ★ 写完的 20 条自查
本库不需要用户机器上有任何工具——没有 lint、没有脚本、不预设 Python 或 Node。 写完规格单，自己把下面 20 条逐条过一遍，结果写进 checks.self_audit。 ★ 这是判据，不是铁律：某条不过，要么改，要么一句话写明为什么这首歌就该这样。 写了理由的偏离就是合法的选择；没有任何一条会"卡住"后面的编译。 ★ 不要为了检查去写脚本（实测有 agent 这么干过，白费很多轮）——20 条全部用眼睛就能判。
| # | 自查问法 | 对照字段 |
|---|---|---|
| 1 | intent 四项都填了？reference_pair 恰好 2 项且每项写了"借哪一点"？ | intent |
| 2 | 各段 start_bar 首尾相接？（上一段 start + bars = 下一段 start） | form |
| 3 | 至少一段的 bars 不是 8 的倍数？ | form[].bars |
| 4 | energy_curve 的 key 集合 == form 的 id 集合？（不多不少） | energy_curve |
| 5 | 能量曲线至少下降一次？ | energy_curve |
| 6 | subtraction_events ≥ 1？ | subtraction_events |
| 7 | 每件乐器有 entry；至少一件 exit 不是 end？ | roster |
| 8 | arrangement_hook.what 非空？ | hooks |
| 9 | 至少一个非 Intro/Outro 段有调外和弦或转调标记？ | form[].harmony |
| 10 | fill_policy.bars 不是公差 4 的等差数列？ | groove |
| 11 | push_pull 至少一项 offset_ms ≠ 0，且每项是 {part, offset_ms, note} 字典？ | groove |
| 12 | width_map 至少两种取值？ | mix_intent |
| 13 | style_prompt 非空且无 epic/emotional/beautiful；section_tags 若手填则与 form 段数、顺序一致（由 form[].name 派生，可不填）？ | render.suno |
| 14 | Σbars × 每小节拍数 ÷ tempo × 60 与 target_duration 偏差 ≤ 10%？ | meta |
| 15 | 有人声时 dynamics_by_section 至少两种取值？（器乐作品跳过） | vocal |
| 16 | 有人声时 chorus_variation 非空？（器乐作品跳过） | vocal |
| 17 | 多风格时：恰好一个 base；每个维度只有一个 owner；每层至少一个维度；fusion_note 非空？ | meta.style_layers |
| 18 | material.motif 与 stated_in 非空；每段 development 填了；new 不过半；至少一段 repeat 或 recap；副歌各遍不全是 new？ | material form[].development |
| 19 | 和弦拼写全 ASCII，后缀在封闭集合里（maj7 m7b5 dim，不写 △ ø ° ♭ ♯ ×）？ | form[].harmony_letters harmony |
| 20 | key 是"主音 major/minor"；mode 在枚举内；段名在封闭集合内；subtraction_events[].at 是 {section, bar_offset} 这样的结构不是句子？ | meta form[].name subtraction_events |
YAML 本身的自查（agent 最常写坏的地方）：
- 列表字段（
roster/sound_stage/push_pull/emotional_arc…）的- {…}条目下面不能挂 `note:` 键——要注释用同级xxx_note:或# - 冒号后有空格；值里有冒号的加引号；缩进统一两格
3.2 自查不过怎么办
不过的条目通常指向一个没读的 skill，而不是需要硬填：
| 不过的条目 | 多半是哪个 skill 没读 |
|---|---|
| 1（intent 不齐） | 本 skill §1 的 S0——回去想清楚，不要硬填 |
| 2、3、14（段落与时长） | mc-arrangement-arch §4 |
| 4、5（能量曲线） | mc-arrangement-arch §2 |
| 6（减法事件） | mc-arrangement-arch §3 |
| 7（编制进退场） | mc-arrangement-arch §5 |
| 8（arrangement_hook） | mc-arrangement-arch §7 |
| 9（和声单调） | mc-harmony、mc-modulation |
| 10、11（fill 与律动） | mc-rhythm-section §3、§8 |
| 12（宽度恒定） | mc-mix-intent §2 |
| 13（编译不完整） | mc-render-compile |
| 15、16（人声） | mc-vocal-direction §1、§4 |
豁免的规矩：写进 checks.exemptions，必须带理由。 静默跳过 = 没写完。
3.3 ★ 生成后端的默认值对照表
后端在无指令时会滑向左列。ARR-SPEC 的对应字段就是为了把它拉回来。
| 后端默认倾向 | 对抗字段 | lint |
|---|---|---|
| 段落等长、都是 8 的倍数 | form[].bars | #3 |
| 能量单调上升到底 | energy_curve | #5 |
| 开场就把乐器铺满 | roster[].entry | — |
| 所有乐器从头响到尾 | roster[].exit | #7 |
| 只加不减 | subtraction_events | #6 |
| 每 4 小节一个过门 | fill_policy.bars | #10 |
| 全声部严格对齐网格 | groove.push_pull | #11 |
| 人声全程一个力度 | vocal.dynamics_by_section | #15 |
| 副歌逐遍原样复制 | vocal.chorus_variation | #16 |
| 人声音准全中 | vocal.pitch_policy | 人工项 |
| 立体声宽度全曲不变 | mix_intent.width_map | #12 |
| 动态被压平 | mix_intent.dynamics | 人工项 |
| 没有非人声记忆点 | hooks.arrangement_hook | #8 |
| 时长永远 3:30 | meta.target_duration | #14 |
4. 诊断路径：生成回来不对劲
按这个顺序查，不要凭直觉跳。
听着"像 AI"
└─ 先分开两个问题：后端照做了没有（照做率）、成品有没有机器指纹（AI 味旗标）
├─ 照做率低 → 后端没照做
│ ├─ 查 backends.yaml：这个字段该后端 honors 是 none 吗？
│ │ └─ 是 → 不是它的错。换后端（YuE2 控制力最强）或接受
│ └─ 否 → 编译问题，查 mc-render-compile
└─ 照做率高但仍像 AI → 规格本身不够
└─ 走 mc-ai-tell-audit 的清单4.1 具体症状 → skill
| 症状 | 先查 |
|---|---|
| 平、没起伏 | mc-arrangement-arch §2 能量曲线 |
| 糊、浑 | mc-texture-layering §4 → 先查持续音，不是先怪鼓 |
| 主角不突出 | mc-texture-layering §3 四条深度线索 |
| 机械、太准 | mc-rhythm-section §2 ＋ mc-vocal-direction §4 |
| 听着还行但记不住 | mc-arrangement-arch §7 —— arrangement_hook 是不是空的 |
| 第二遍副歌和第一遍一样 | mc-arrangement-arch §6 ＋ mc-vocal-direction §1④ |
| 人声埋在伴奏里 | 先查音准（mc-vocal-direction §4.1），再查频段 |
| 贝斯在手机上消失 | mc-sound-design §6 差音 |
| 结尾很突兀 / 淡出了事 | mc-arrangement-arch §8 三种结尾 |
| 技术上干净但情绪不对 | mc-mix-intent §3.1 —— mood 是不是没写 |
4.2 ★ 两个数不许混为一谈
| 问什么 | 怎么算 | |
|---|---|---|
| 照做率 | 后端照着规格做了多少 | 逐字段对照规格听/看；0–100 的参考线见 §6.3 |
| AI 味旗标 | 成品有没有机器指纹 | mc-ai-tell-audit 的清单，独立计数 |
照做率 100 的东西完全可能满是 AI 味——那说明规格写得像 AI。 反过来，照做率 40 但好听，说明后端自己干得不错，但你不可复现。
5. 对外接口
本库管一首歌的作曲与编曲决定（调、速度、段落、和声、主题材料、谁什么时候进退、能量曲线、怎么唱、混音要达到什么），产出是 ARR-SPEC。不假设下游是谁、用什么工具；对外只经规格单：交出去的字段、有就读的上游字段（§5.2）、messages（§5.3）。字段怎么理解：ARR-SPEC.schema.md §5。
| 职能 | 不归本库的 | 交出去 |
|---|---|---|
| 作词 | 词怎么写：押韵、意象、叙事人称；字怎么安到音上（符割り、字余り、倒字、协音） | 共享六字段（§5.1）；vocal.phrasing／breath_points、hooks.vocal_hook、intent.emotional_arc、form[].melody_register |
| 声音（混音、母带） | EQ 频点、压缩比、混响参数、总线链、母带；录音；影视意义的音效与拟音 | mix_intent（只写意图）、roster、depth_map、spectrum_budget、subtraction_events、vocal.pitch_policy／stacking；deliverable 含 stems 时交分轨 |
| 配乐（为画面写音乐） | 跟画面走的结构：spotting、cue sheet、从哪一帧进 | meta.tempo／tempo_map／target_duration、form[].start_bar／bars、material、hooks.arrangement_hook、energy_curve |
| 剪辑环节 | 把音乐放到画面上：切在哪、剪短、接缝 | 同上的时间字段、subtraction_events、stems |
镜头设计按放音拍时读速度与段落时间，交出去以后再改要先写消息；商用前的许可看 backends.yaml 的 license（制片与现场）。小节换算成秒的约定见 schema §5.1。
5.1 与歌曲另一侧共享的六个字段
form[].id / form[].bars / form[].name / meta.tempo / meta.key / vocal.persona。两边用同一套段落 id。
- 谁先做谁定。 先曲后词：本库定，写进自己的字段。先词后曲：从
meta.upstream.lyrics.shared原样读进来，当锁死项用；词的字数和句式反过来约束form[].bars。 - 后做时不改这六项。 词放不进这几小节、调或速度唱不下来，就写一条
messages（to: lyrics），说清改哪一项、为什么；对方接受并改了它自己的规格单，本库再重新读。 - 只有曲、没有歌词那一侧时，这六项由本库自己定。
完整规则与原文：schema §5.4。
5.2 上游：有就读
meta.upstream.brief／lyrics／picture 来自谁不重要：有就读（先词后曲时的共享六项是锁死项），没有就按本库自己的分析走——S0 从 brief 起，没有歌词就按 §2.3 的三种情况，没有画面时长就自己定时长。已填的上游字段不改写；冲突时照实写本库的字段，再写消息给来源的职能。
5.3 messages：怎么收发
- 收：S0 开工与每次改规格前读
to: music的，交给about所指字段的 owner（§2.1）；改了标accepted、不改标rejected，reply写改了什么或理由。 - 发：如
{from: music, to: sound, about: "mix_intent.dynamics", says: "D 段比 C2 低 6 dB 是唯一的大落差，母带请留住", status: open}；to取lyricssoundeditingshot-designwritingproduction。 - 不等待：读不到回话就当没有；
open不挡自查、不停阶段，交付时原样交出去。
6. 三个检验办法
6.1 选 skill 时对照边界表
开工前把这首歌要读的 skill 列出来，对照 §2 和各 skill 的边界表看两件事：
- 该读的读了没有：brief 里每个要做的决定，都有一个 owner 被选中
- 不该读的混进来没有
—— 尤其是 L3 风格层，多读一个没被点名的风格 skill，最容易把它的默认值带进这首歌（被点名的混合不算，见 §2.4）
这就是为什么每个 skill 都必须有「边界：什么不归这个 skill 管」表—— 那张表是给选 skill 时看的，不只是给人看的。
6.2 文本层 AB
评判表在看结果之前定稿。 改一个字段 → 重生成 → 盲比。 定稿之后再看结果，否则你会不自觉地把评判标准调向你已经看到的那个。
比响度前先对齐电平，再比内容：声音只要更响，耳朵就倾向觉得它更好，这条偏差会把"哪个字段起了作用"的判断，悄悄换成"哪个版本更响"（p0299-p0300）。两版生成结果如果响度或整体密度对不齐，先拉平这两项再做成对比较，不然字段本身的效果会被响度差盖过去。
6.3 先算再听（照做率）
见 §1 的 S7 与 §4.2。
★ 零点校准（参考值，供理解量级，不是交付门槛）：拿一份 City Pop 规格（112 BPM、10 段、114 小节）去比三首与它无关、制作精良的华语成品，按字段加权打分得 63–66， 所以我们把 82 / 70 当"照做得好 / 勉强"的参考线，不是 60。 逐字段对照时，照做率就是对照后的一个判断，不必算成数。
7. 目录地图
随包发布（用户拿到的就是这些，全是文本）：
skills/<27 个 skill>/SKILL.md, reference.md
skills/mc-workflow/ARR-SPEC.schema.md ★ 规格单定义（v1.0）
skills/mc-workflow/ARR-SPEC.template.yaml 空模板
skills/mc-workflow/backends.yaml ★ 各后端的 honors 声明
skills/mc-workflow/example-*.yaml 填好的示例（citypop / 混合 / 反面样本）8. 写完一首歌的自检
- [ ]
intent四项是想出来的，不是为了过 lint 填的 - [ ] §3.0 的 20 条逐条过了，不过的都写了理由
- [ ] 每个字段都能说出是哪个 skill 的哪一节决定的
- [ ] 逐字段对照过生成结果，且知道哪些项因
honors: none本来就不指望 - [ ] 跑过
mc-ai-tell-audit - [ ] 耳朵是最后介入的，且 A/B 结论两遍一致
附：这个库为什么这样分层
分库/分 skill 的判据是四件事全不同：交接物、裁判、语料、评判方法。 按工序切，不按知识领域切。
所以：
- "和声"是知识领域，但它被切进
mc-harmony（写的时候）和mc-progressions（查的时候）——
因为这是两道工序
- "city pop"是风格，它的鼓型不进
mc-rhythm-section，进mc-style-citypop-rnb——
因为"打得像人"和"打得像 city pop"是两道工序
- "混音"横跨三层：意图在
mc-mix-intent，改写型解法在mc-texture-layering，
参数是混音的事——因为它们的裁判不同（作曲判断 / 编曲判断 / 工程判断）
附：来源
- Howard & Angus《音乐声学与心理声学》（Acoustics and Psychoacoustics）——§1.2 两遍复听的两条心理声学依据：重复听音会改变听觉系统的处理策略、以及持续暴露带来的听觉适应。页码为中译本页。
- Roey Izhaki《Mixing Audio》（混音指南）——§6.2 提醒的响度偏差：更响的版本容易被判定"更好"，与内容本身的差异无关。页码为该书页。
本库其余各 skill 引用的书目见各自的「附：来源」。
