技能介绍

解决什么问题

Suno 生成质量不稳定，常卡在提示词：Styles 字段要同时交代曲风、情绪、歌手质感和编曲；Lyrics 还要遵守段落标签、时间戳与 [Key: Value] 约束。手动写时很容易出现风格漂移、情绪线断裂、段落结构对不上，或者把方法论和最终提示词混在一起，导致一次生成后难以复现。

这个技能把提示词创作拆成可审计的流程：主 Agent 只负责收集需求、路由任务和交付结果；提示词本体由多个专家子 Agent 生成与修改，质检意见再回传给对应专家，避免所有逻辑挤在同一个上下文里。

核心能力

需求卡先行：先按 references/subagents/00-requirements-template.md 写入 build//00-requirements.md，覆盖任务类型、曲风流派、情绪线、参考歌手、使用场景、原创或翻唱、是否含歌词，以及定制歌曲时的实际段落结构。
三类工作流：从零开发或开发新模板走 研究 -> Styles -> Lyrics -> QA；套用现有模板直接生成成品，不过质检；为指定歌曲定制时沿用四步链路，但结构要求改成目标歌曲的真实段落骨架。
专家子 Agent 分工：01-researcher.md 产出知识简报；02-styles-writer.md 写四段法 Styles；03-lyrics-writer.md 写 [Key: Value] 形式的 Lyrics；04-qa.md 做硬性规则检查；05-template-applier.md 把客户歌词和风格诉求套进现有模板。
产物隔离：流水线中间稿写入 build//，模板 QA 通过后追加到 templates/系列模板.md 并更新 templates/index.md；歌曲成品可选保存到 songs//。

关键步骤

从零创作时，先让搜索专家补齐曲风、歌手和编曲参考，再写 02-styles.md。Styles 专家读取研究稿，产出固定 14 段骨架的提示词。Lyrics 专家同时读取 Styles 和研究稿，但只取 BPM、Key、情绪线等必要信息，避免被搜索细节带偏。最后质检同时检查两个文件，不通过则连同 QA 报告回传给对应专家，最多两轮。

主 Agent 不在派发 prompt 中注入方法论，也不直接改写子 Agent 产物；每步先确认输出文件已生成再继续。最终只把可复制粘贴的提示词卡交给客户，并注明是否通过硬性规则质检。