当使用者贴出一段 xxxxx 形式的字数模板、说"按这个结构写"、"帮我定一下歌曲结构"、"主歌预副副歌该各写几句"时使用。把 x 模板解析成可执行的骨架表：每段每行的字数、停顿位置、押韵位、以及这一段在整首歌里的功能；没有模板时给两三个常用骨架供选。这是确定性工作，不派子代理。
产出的骨架是填词的唯一输入，改字数等于改旋律。
The English summary is being prepared. Showing the original description.
See how to installReview the instructions the agent will receive before you install.
把字数模板变成一张可执行的骨架表，或者在没有模板时给出一个。
骨架是填词唯一的硬约束来源。后面所有环节都拿它当输入，所以这一步的产出必须精确到每一行。
解析模板是确定性工作：数 x、找空格、标段落。派子代理不会更准，只会更慢更贵。
没有模板需要生成骨架时，也是从下面几个成熟结构里挑一个，不是创作。
为了用而用子代理是浪费。 需要创意的是填词那一步（adversarial-lyric-writer）。
xxxxx 模板要照着写不适用于 / Not for：
adversarial-lyric-writerlyric-concept-builder；骨架定得再准，没内容也填不出东西主
xxxxxxxxxx
xxxxxxxxxx
xxxxxx
xxxxxxxxx
预副
xxxxxxxx
xxxxx xxxxx
x = 一个汉字 = 一个音节 = 一个节拍位xxxxx xxxxx 是"五字，停，五字"，不是十字一口气唱完详细规则见 _shared/craft-reference.md 第 4 节。
逐行数，不要目测。 十个 x 和十一个 x 看上去一样，填出来的词唱起来不一样。
骨架表里每一段都要标功能，否则填词时会四段写成同一段：
| 段落 | 功能 | 常见特征 |
|---|---|---|
| 主歌 1 | 建立处境：谁、在哪、发生了什么 | 行较长，叙述性，情绪压着 |
| 预副 | 收窄并抬升 | 行变短或字数递减，情绪转向，最后一行像个问号 |
| 副歌 | hook + 情绪顶点 | 行数多，开口辙，第一句或最后一句是 hook |
| 主歌 2 | 推进，不是重述 | 与主歌 1 同长，但时间/地点/事件/视角要变 |
| 桥段 | 视角转换或反转 | 常换辙、换人称，是全曲唯一可以"说别的"的地方 |
| 尾段 | 收束 | 行数少，可以只留一句，字数短于其他段 |
主歌 2 是整首歌最容易塌的地方。同长同韵会诱使人把主歌 1 换个说法再写一遍。 骨架表里就要写死主歌 2 相对主歌 1 要变什么，别留到填词时才想。
按歌的性质挑，不要默认给最长的那个：
A. 标准流行（最常用）
主歌1 → 预副 → 副歌 → 主歌2 → 预副 → 副歌 → 桥段 → 副歌 → 尾
适合：有故事、有转折的题材。预副是这个结构的关键，没有它副歌会来得很突兀。
B. 无预副（更直接）
主歌1 → 副歌 → 主歌2 → 副歌 → 桥段 → 副歌
适合：情绪单一、想快点到副歌的歌。主歌末行要自带抬升，否则接副歌会硬。
C. AABA（老派、短）
A → A → B → A
适合：三分钟以内、以旋律取胜的小品。B 段承担全部转折。
给骨架时把每段的行数和字数一并给出，不要只给段落名。
## 骨架表
### 主歌 1 —— 建立处境
| 行 | 字数 | 停顿 | 押韵 |
|---|---|---|---|
| 1 | 10 | 无 | 否 |
| 2 | 10 | 无 | 是 |
| 3 | 6 | 无 | 否 |
| 4 | 9 | 4+5 | 是 |
（各段照排）
## 押韵方案
主歌：<辙名> 预副：<辙名> 副歌：<辙名，开口辙> 桥段：<辙名>
## 段落间的约定
- 主歌 2 相对主歌 1 要变的是：<时间 / 地点 / 事件 / 视角，指明一项>
- 副歌 A/B 的差别在：<哪几行不同>
- hook 落在：<第几段第几行>
## 总字数与时长估算
<总字数>字；BPM <B>、每拍 <k> 字，演唱约 <总字数 ÷ (k × B)> 分钟，加前奏间奏约 <M> 分钟（假设的数写明是假设）
时长按 BPM 推，给个范围就行：演唱时长（分钟）≈ 总字数 ÷（每拍字数 × BPM）。
一拍一个字，每拍字数取 1；一拍唱两个字（八分音符的密度）取 2。还没有旋律时按
_shared/craft-reference.md 第 3 节"一字一音"的读法取 1，写明是假设。没有 BPM 就问一句，
或者按 80 到 120 给范围。句尾拖长和换气也占拍，所以这个数只会偏短；前奏、间奏、尾奏
另按"小节数 × 每小节拍数 ÷ BPM"加上。
例：主歌、预副各 35 字、副歌 67 字排结构 A，不算桥段和尾声共 341 字。BPM 90、一拍一字时， 光演唱就要约 3.8 分钟（341 ÷ 90），做三分钟的歌就得砍段落或压字数；一拍两字时约 1.9 分钟。 这个数用来提醒结构排得是不是太长或太短。
| 版本 | 日期 | 变更 | 类型 |
|---|---|---|---|
| 0.1.1 | 2026-09-26 | 时长估算改按 BPM 推算（总字数 ÷（每拍字数 × BPM），另加前奏间奏）：原来的"每分钟 180 到 240 字"与本 skill 自己的模板和例子对不上，时长约偏短一半；输出模板和例子同步改 | patch |
| 0.1.0 | 2026-08-11 | 初始草稿 | minor |
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
当学生说"Common App 活动栏写不下"、"这段活动描述超字数了"、"帮我把这几条压到限制内"时使用。先按官方申请表核对当季字符限额，再逐条检查；一次把所有条目量完并直接给出压缩版，只在需要砍掉实质内容时才用选择题问该保哪部分。每改一版都用工具重新数一遍字符，绝不凭感觉说"这样应该够了"。只压缩，不代写空白。
The English summary is being prepared. Showing the original description.
当学生说"我参加过一些活动但没整理过"、"帮我把经历录进去"、"我的活动档案是空的"时使用。让学生一口气把记得的活动说出来，直接把这段话拆成结构化的长期事项（角色、组织、起止时间、做了什么、结果、级别），说不清的字段留空标"待补"而不是编，再用一张选择题卡把级别判定与是否重复这类关键项一次问完，然后提案入库。只记录学生真正说出口的内容，级别按事实判定，绝不往高了写。
The English summary is being prepared. Showing the original description.
当学生问"招生官会怎么看我的档案"、"我的背景还差什么"、"帮我评估一下现在的申请竞争力"时使用。以顶尖大学招生官的视角通读学生的档案、长期活动与已写下的反思，不问任何前置问题直接产出一份指名道姓的坦诚点评：这份材料的亮点、招生官真实的解读方式、明显的短板与空白、以及接下来最值得做的一到两件事。只读不写，不修改学生的任何数据，也不代写任何申请材料。
The English summary is being prepared. Showing the original description.
当使用者说"帮我填词"、"按这个字数模板写歌词"、"用多Agent对抗式写词"、"这首副歌帮我想几句"时使用，前提是字数骨架和这首歌写什么都已经有了；只有主题、还没定写什么时先用 lyric-concept-builder。拿一份字数骨架和意象系统，派三个 sonnet 子代理按不同路子并行独立起草（场景派 / 口语派 / 意象派），再派一个红队子代理逐句挑毛病，主 Agent 按句裁决拼稿，最后统一辙口与意象。收敛判据卡死：字数用 lyric-doctor 的脚本对模板数、每段同辙、hook 不含陈词、主歌二对主歌一有推进。不抄现有歌词，不替使用者决定这首歌要说什么。
The English summary is being prepared. Showing the original description.
当想知道一段 AI 回答"哪些能直接用、哪些必须先验证、哪些只能当建议"时使用。按声明类型分四级——低风险草稿材料、观点与策略建议、可查证的事实声明、会改变状态的可执行指令——每级配一句默认处置动作；再按影响半径排序，给出最小的下一步检查。可执行类一律标"不能直接执行；先做代码审阅/沙箱测试/回滚准备"，其中破坏性或提权的命令排在最前。教的是一套可复用的复查习惯，不是替使用者把所有内容都核实一遍：本 skill 只分级、排序、定处置，要逐条核实走 ai-output-fact-checker，整段代码要做入库体检走 ai-code-onboarding-checklist。
The English summary is being prepared. Showing the original description.
当拿到一段 AI 生成的代码，还没决定要不要信、要不要跑、要不要往上继续加东西时使用。先做一遍客观体检：行数与嵌套深度、有没有测试、有没有硬编码密钥或遗留 TODO、依赖是不是真实存在、有没有危险调用（eval/exec、shell=True、递归删除、反序列化、提权、外发网络，按正文给的 grep 模式逐类查）；再给风险评级和下一步动作。老实写明它查不了算法正确性——体检通过不等于代码是对的。回答里文字、事实和代码混在一起时先用 ai-answer-triage 分级；只审相对已有代码的一份改动用 ai-diff-review-protocol。
The English summary is being prepared. Showing the original description.