BeatFlow 技能

BeatFlow

使用 Codex 進行音樂決策。使用內建引擎處理精確時序、功能性音高實現、聲部配置、驗證、診斷、編譯、MIDI 渲染與檢查。

執行環境

將此技能目錄稱為 <skill-root> 並執行：

python "<skill-root>/scripts/run.py" <command> ...

需要 Python 3.10 或更新版本。將作曲腳本與產出的成品寫入使用者的工作區，切勿寫入 <skill-root>。

工作流程

1. 從簡報中提取時長、曲式、速度、拍號、調性語言、樂器編制、能量曲線、優先事項與排除事項。針對遺漏的細節做出可逆的假設。

2. 將每項樂器分類為 essential（必要）、substitutable（可替代）或 optional（選用）。另外將其顯著性分類為 primary（主要）、co-primary（共同主要）、support（支撐）或 background（背景）。在考慮合約變更前，先保留必要樂器並修復其寫法、平衡或播放程式。

3. 閱讀 composition-guidance.md 與 composition-format.md。針對突出的旋律、主題發展、複雜拍號或時序修復，請閱讀 phrasing-and-coordination.md。針對超過 90 秒的作品，請閱讀 long-form.md。在修改或比較候選版本時，請閱讀 diagnostics.md。僅在需要方法論證據時，才載入 research-foundations.md。

4. 在撰寫事件之前先進行規劃：

   • 框架：時長、段落、速度、拍號、節拍、主音與調式；
   • 樂句：分組、和聲節奏、注意力、到達點與釋放點；
   • 骨架：脈衝、低音、和聲、角色進場、休止與交接；
   • 前景：節奏特性、輪廓、密度、紋理與結構音；
   • 裝飾：填充音、次要攻擊音、對位線條與斷奏法。

5. 在加入前景之前先呈現量化的骨架。至少保留一個穩定的時間參考，並讓重要的和聲變化與到達點能被感知。將前景視為選用；低音鉤、設計的和弦頂音或節奏紋理可能已經足夠引導注意力。

6. 撰寫一個可信賴的 Python 檔案，其 build() 函式回傳 Composition。使用 SongBuilder；讓風格影響撰寫的音樂，而非影響模式或編譯器。

7. 對於完整的歌曲，將可重複使用的段落素材與時間軸上的事件分開處理。使用事件發展與 arrange() 處理來創造形式上的變化，而無需複製整個段落。

8. 對於品質敏感的旋律或主題創作，在擴充曲式之前，先試聽數個短小、結構不同的候選版本。比較不帶音高裝飾的節奏與時長，保留一個早期可辨識的陳述，並透過聆聽來選擇。

9. 渲染選定的候選版本：

python "<skill-root>/scripts/run.py" compose "<output>/<name>.py" "<output>/<name>.mid" --composition-output "<output>/<name>.composition.json" --project-output "<output>/<name>.project.json" --report "<output>/<name>.report.json"

10. 將驗證錯誤視為嚴重失敗。將診斷結果視為與書面意圖相悖的證據，而非品味分數。修改造成問題的最高因果層，重新渲染，並再次聆聽。
11. 報告音樂設計、假設、驗證結果、診斷發現、MIDI 資訊，以及任何仍需透過聆聽判斷的決策。

核心限制

• 保持預設時序完全量化。僅在使用者明確要求時間實驗時，才加入起音偏移或人性化處理，並保留一個量化基準。
• 計算感知節拍，而非假設每個四分音符都是一拍。使用 song.at()、song.tactus() 和 song.bars() 來規劃符合拍號的方案。
• 使用規則的完整小節樂句分組，除非不規則性具有指定的音樂功能。
• 為重要的前景樂句賦予清晰的特性、內部對比與主要的到達點。當其意圖需要可測試時，使用 phrase()、phrase_stage() 和 arrival()。
• 為相關的角色賦予有目的的依賴性，但不要強迫一致的攻擊音。當獨立性、交織、呼應或交接是簡報的核心時，使用 interaction()。
• 當和弦聲部中的最高音承載旋律線時，使用 top_target。僅在它有明確的補充角色時，才加入一個單獨的主旋律。
• 明確指出每個起音與時值。切勿從下一個攻擊音推斷音符長度。

修改

按以下順序進行診斷：

1. 拍號與共享時鐘；
2. 角色所有權與樂器合約；
3. 樂句分組、手勢連續性與到達點；
4. 和聲節奏、低音支撐與聲部配置；
5. 音高輪廓與非和弦音行為；
6. 斷奏法、平衡與播放音色。

在加入規則之前，先使用三種簡單的比較方式：

• 用單一音高試聽前景節奏；
• 一次靜音一個選用或競爭層；
• 比較最早完成的樂句結尾與一個後來的結尾。

修復因果結構，而非孤立的音符。不要使用隨機密度、任意抖動、全面人性化或新的特定類型引擎規則作為捷徑。

指令

• schema：列印 Composition 1.1 JSON Schema
• validate COMPOSITION：執行嚴格的結構與語意檢查
• diagnose COMPOSITION：報告建議性的音樂觀察
• compare COMPOSITION...：比較候選版本的指紋
• compile COMPOSITION PROJECT：編譯為內部 Project JSON
• render COMPOSITION MIDI：驗證、診斷、編譯、渲染並檢查
• compose SCRIPT MIDI：執行可信賴的 build() 並執行完整管線
• inspect MIDI：報告 MIDI 結構、程式、範圍與控制器
• self-check：執行端到端安裝冒煙測試

僅在處理低階編譯的 Project 邊界時，才使用 project-schema、project-validate 和 render-project。

邊界

• 創作原創的符號音樂。請勿複製參考旋律或模仿在世藝術家。
• 在匯入分析語料庫或參考檔案之前，先驗證授權。
• 將 General MIDI 播放視為預覽；在目標樂器或 DAW 中評估製作音色。
• 將聆聽保留為最終的音樂決策。