suno-songwriting

Suno Songwriting

参照ファイル

ファイル	用途
references/clarifying-interview-instructions.md	intake 台帳、ヒアリングループ、十分性ゲート、スケッチモードの例外。
references/lyric-writing-instructions.md	歌詞の構成、修正、押韻、構造、フック、ブリッジ、タイトル候補。
references/style-writing-instructions.md	Suno スタイルプロンプト、プロンプトの長さ、順序、ジャンルの融合、プロダクションの方向性、ネガティブ制約。
references/genre-knowledge.md	ジャンルの選択、ジャンルの融合、時代の参照、サブジャンルの語彙、プロダクションの特徴。
references/vocal-routing-index.md	ボーカル描写、プロファイルリソース、比較、ボイスデザインの深さのための軽量ルーティング。
references/instrument-knowledge.md	バンド、オーケストレーション、シンセ、リズムセクション、サウンドパレット、アレンジの語彙。
references/lyric-tag-knowledge.md	角括弧付き歌詞タグ、セクションタグ、パフォーマンスキュー、インストゥルメンタルブレイク、タグの抑制。
references/translation-instructions.md	非英語歌詞、バイリンガル歌詞、翻訳、ローカライズ、音節の保持、歌唱可能性。
references/extended-genre-diversity-matrix.md	珍しい、歴史的な、地域的な、融合ジャンルの語彙のインデックス。ここから関連する genres-*.md ファイルへルーティングします。
references/structure-movement-tags.md	詳細な構造、展開、エネルギー、パルス、クライマックス、ドロップ、インプロビゼーション、アレンジのタグのインデックス。
references/vocal-identity-library.md	名前付きボーカルアイデンティティ、ボイスプロファイルの比較、プロファイルプロンプトのバリアント、評価ルーブリックのインデックス。

専門的なプロファイル、ジャンル、タグファミリーのファイルは、タスクがその深さを必要とする場合にのみ、それぞれのインデックスリソースを通じて読み込んでください。

コアワークフロー

このスキルを使用して、連携する 2 つの出力を生成します。

1. Suno の歌詞フィールドに適した歌詞。オプションのパフォーマンス、展開、アレンジ、拡張キューなどのタグを埋め込んだセクションタグを使用します。
2. Suno のスタイルプロンプトフィールドに適したスタイルプロンプト。ユーザーのブリーフに基づき、コンパクト形式またはリッチなプロダクションブリーフ形式のいずれかを使用します。

新しい曲、大幅な書き直し、趣向の判断を伴う翻訳／翻案、またはユーザーが Suno 対応の結果を求めるリクエストについては、まず references/clarifying-interview-instructions.md を読んでください。ユーザーがすべての重要な入力を含む完全なブリーフをすでに提供している場合を除き、デフォルトでヒアリングを実施します。そのファイルのヒアリングチェックリストを内部の intake 台帳として維持してください。各必須領域は、ユーザーから収集するか、影響の少ない詳細については妥当な確信をもって推測するか、その領域が無関係であるために明示的にスキップ／省略する必要があります。1 回のヒアリングにつき最大 5 つの質問を行い、1 つの質問につき 1 つの未解決の入力カテゴリとします。別々のカテゴリを 1 つの質問や回答セットにまとめないでください。すべての重要な入力がユーザーによって明示的に提供されるまで続けてください。ユーザーが質問を断った、選択を委任した、簡単なドラフトを求めた、または「あとは全部決めて」と言ったという理由だけで、重要な入力の質問を省略しないでください。トピックとジャンル、またはトピックとムードを、完全なブリーフとして扱わないでください。

ハードストップ：薄いブリーフから新しい曲を作る場合、最初のレスポンスで最終的な 4 セクションの出力を返さないでください。代わりに intake スナップショットと明確化の質問を返してください。

ドラフト / スケッチモード

スケッチモードは、ユーザーが迅速なドラフト、ラフバージョン、スターター歌詞、ブレインストーミング、初稿、探索的な選択肢、または同様の最終成果物ではないものを明示的に求めた場合にのみ使用してください。スケッチモードはアイデア出しの速度のためのものであり、最終的な Suno 対応の出力のためのものではありません。

スケッチを作成する前に、以下の最低限の入力を収集または確認してください:

1. 成果物の範囲。
2. 主題/前提。
3. 主要ジャンルまたは大まかなスタイルレーン。
4. 歌詞が求められている場合は、歌詞の視点。
5. 禁止コンテンツ、または制約がないことの確認。

スケッチモードでは、ストーリーの切り口、感情的な終着点、ボーカルのアイデンティティ、ボーカルスタイル、目標の長さ、セクション構成、BPM、キー、アレンジの展開、その他の低リスクのコントロールを最善の判断で推測してください。スケッチの前に必須の重要入力レビューゲートを実行しないでください。スケッチを最終版、洗練済み、リリース可能、または Suno 対応として提示しないでください。

以下のスケッチ形式を使用してください:

### Sketch Draft
...

### Assumptions
...

### Next Questions
...

ユーザーがスケッチの最終化、洗練、エクスポート、または Suno 対応化を求めた場合は、最終的な Title / Lyrics / Style / Analysis の出力を生成する前に、通常のインタビューと重要入力レビューのフローに戻ってください。

必須の重要入力レビューゲート

このゲートは、歌詞、スタイルプロンプト、または最終的な Title / Lyrics / Style / Analysis の出力を生成するすべてのリクエストに対して、スキルレベルで適用されます。

歌詞またはスタイルプロンプトを生成する前に、常にユーザーに簡潔な重要入力レビューを表示し、確認を求めてください。これは、ユーザーが完全なブリーフを提供した場合でも必要です。このレビューと同じレスポンスで生成出力を出さないでください。

以下の形式を使用してください:

Critical inputs to review:
- User decisions: ...
- Best-judgment decisions: ...

Reply "approved" to generate, or tell me what to change.

User decisions には、ユーザーがブリーフまたはインタビューを通じて直接提供した重要な選択を要約してください。Best-judgment decisions には、スキルが推測またはデフォルト設定した重要でない選択のみを要約してください。

レビューは、該当するすべての生成を形作る入力、すなわち成果物の範囲、前提、ストーリーの切り口、歌詞の視点、宛先/聴き手、感情的な終着点、トーン、強度、主要ジャンル、サポートジャンルまたは融合、BPM またはテンポ感、キーまたはモード、プロダクションの方向性、ボーカルのアイデンティティ、ボーカルスタイル、目標の長さ、セクション計画、歌詞の密度、エンリッチされたタグ、タグの抑制、アレンジの展開、言語、露骨さ、必須フレーズ、禁止コンテンツ、安全上の制約、センシティブコンテンツの扱い、およびユースケースを網羅しなければなりません。Suno 対応の楽曲では、セクション構成、BPM/テンポ、キー/モード、ボーカルのアイデンティティ、およびボーカルスタイルは、承認の前にユーザーが明示的に提供しなければなりません。

ユーザーがレビューを承認した後、またはそれらの前提で進めることを明示的に求めた後にのみ、スキルは歌詞、スタイルプロンプトテキスト、タイトル案、または分析を生成できます。ユーザーが重要な入力を変更した場合は、レビューを更新し、生成の前に再度確認を求めてください。

リソースルーティング

特定のタスクに必要なリソースのみをロードしてください:

• 歌詞の作成、修正、韻、構成、フック、ブリッジ、タイトル案については、references/lyric-writing-instructions.md を読んでください。
• Suno スタイルプロンプト、プロンプトの長さ、順序、ジャンルの融合、ムード、プロダクション、ネガティブ制約については、references/style-writing-instructions.md を読んでください。
• ジャンルの選択、ジャンルの融合、時代の参照、サブジャンルの語彙、プロダクションの特徴については、references/genre-knowledge.md を読んでください。
• 通常のシンガーの描写、ハーモニー、合唱、ラップ、スポークン、デュエット、ボーカルプロダクションの指示については、まず references/vocal-routing-index.md を読んでください。これはコンパクトなボーカルスタイル、座標、プロファイル、比較、ルーブリックのリソースへルーティングします。
• バンド、オーケストレーション、シンセ、リズムセクション、サウンドパレット、アレンジの語彙については、references/instrument-knowledge.md を読んでください。
• 角括弧付きの歌詞タグ、セクションタグ、パフォーマンスキュー、インストゥルメンタルのブレイク、タグの抑制については、references/lyric-tag-knowledge.md を読んでください。
• 非英語の歌詞、バイリンガルの歌詞、翻訳、ローカライズ、音節の保持、言語をまたいだ歌唱性については、references/translation-instructions.md を読んでください。
• 執筆前の要件収集については、references/clarifying-interview-instructions.md を読んでください。

タスクがより広範な知識や専門的な語彙を必要とする場合は、まずインデックスリソースを使用してください:

• 珍しい、歴史的な、地域的な、または融合ジャンルの語彙については、references/extended-genre-diversity-matrix.md を読み、その後、関連する references/genres-*.md ファミリーファイルのみをロードしてください。
• 詳細な構成、動き、エネルギー、パルス、クライマックス、ドロップ、即興、アレンジのタグについては、references/structure-movement-tags.md を読み、その後、関連するタグファミリーファイルのみをロードしてください。
• 名前付きのボーカルアイデンティティ、声のプロファイルの比較、プロファイルプロンプトのバリエーション、評価ルーブリックについては、references/vocal-identity-library.md を読み、その後、関連するプロファイル、プロンプト、比較、またはルーブリックのファイルのみをロードしてください。
• 名前付きプロファイルを使用しない詳細な声の座標設計については、references/vocal-style-knowledge.md または references/vocal-feature-space.md を読んでください。
• ボーカルアイデンティティライブラリを生成または拡張するには、references/vocal-identity-generation-instructions.md を読んでください。

出力契約

最終結果は常に、正確にこの順序でこれらの H3 セクションを含む Markdown ファイルとして返してください: Title、Lyrics、Style、Analysis。各 H3 見出しの下の内容は、コピー＆ペーストしやすいようにフェンスコードブロック内に配置してください。

次の構造を使用してください:

### Title
```text
...
```

### Lyrics
```markdown
[Verse 1]
...
```

### Style
```text
...
```

### Analysis
```markdown
...
```

スタイルプロンプトは簡潔にしつつも、情報不足にならないようにしてください: 単純なブリーフにはカンマ区切りのコンパクトなプロンプトを使用し、特徴的な融合、詳細なボーカルの挙動、インストゥルメンテーション、アレンジの動き、歌詞の前提、または長さの制約がある場合は、より密度の高いプロダクションブリーフのプロンプトを使用してください。歌詞は歌いやすく、構造化され、Suno にそのまま貼り付けられる状態にしてください。Lyrics ブロックでは、すべての角括弧付き歌詞タグはセクションタグでなければなりません。強化されたすべてのキュータグ、動きのタグ、アレンジのタグ、パフォーマンスのタグは、[Verse 1 - Spoken Delivery] や [Final Chorus - Big Chorus, Ad-Lib Finale] のように、関連するセクションタグの内部に埋め込んでください。歌詞の中に単独のキューやパフォーマンスのタグを配置しないでください。Analysis では、主に歌詞の意味に焦点を当ててください: 物語の弧、語り手、テーマ、メタファー、イメージ、感情の転換、そしてフックがどのように歌を再構成するか。スタイルプロンプト、構成、長さ、または強化の選択肢については、それらが意味、物語、テーマ、イメージ、または感情のペース配分を支える場合にのみ言及してください。ユーザーが複数の選択肢を求めた場合は、各選択肢について同じ 4 セクション構造を繰り返し、ほぼ重複したものを作るのではなく、ジャンル、フックのアングル、ボーカルの方向性、またはアレンジを変化させてください。

出力後のファイル提案

最終的な Title / Lyrics / Style / Analysis の出力を生成して表示した後、表示したとおりの Markdown をローカルファイルに書き出すことを提案します。ユーザーが事前にファイル作成を明示的に希望していない限り、出力を表示する前にファイルを書き出さないでください。

次の形式で具体的な推奨パスを使用します。

./songs/{YYYYMMDD-HHMMSS}-{song-title-slug}.md

利用可能な場合は、ユーザーのローカルの日時を使用します。選択したタイトルからタイトルスラッグを作成します。小文字、実用的な場合は ASCII、ハイフン区切りとし、ファイル名として安全でない記号は除去します。複数の曲の候補がある場合は、それぞれ異なるタイトルスラッグで候補ごとに 1 ファイルを提案します。推奨ファイル名がすでに存在する場合は、上書きせずに -2、-3、または次に利用可能な数値サフィックスを追加します。

最終レスポンスの最後に、次のような短い提案を付けます。

I can also write this to `./songs/20260512-143015-example-title.md`.

ユーザーが承諾した場合は、必要に応じて songs ディレクトリを作成し、4 つの H3 セクションとフェンス付きコードブロックを含む、最終的な Markdown の内容をそのまま書き出します。

スケッチモードでは、ユーザーが明示的にスケッチの保存を求めない限り、ファイルの書き出しを提案しないでください。

判断ルール

• 抽象的の称賛よりも、具体的な音楽的記述子を優先します。
• Suno のスタイルプロンプトは焦点を絞り、順序立てて保ちます。コンパクトなプロンプトでは、存在する場合はシグネチャーサウンドまたはスタイルを最初に置き、続いてジャンル、BPM、キー、サポートスタイル、ボーカルの個性、楽器の役割、歌詞の前提、プロダクションの質感を続けます。リッチなプロンプトでは、references/style-writing-instructions.md に従います。
• ユーザーがそれらの入力を明示的に提供する完全なブリーフを与えた場合にのみ、重要な入力に関する質問を避けます。それ以外の場合は、書き出す前に明確化のためのインタビューを行います。
• ユーザーがそれをテーマにしない限り、歌詞で楽器名や音楽の概念に言及しないでください。
• 生成されたボーカルの個性は、具体的なボーカル、ジャンル、ディクション、プロダクションの特性を持つプロファイルとして扱います。
• デフォルトでは、角括弧付きの歌詞タグを適度な数だけ使用します。通常のセクションラベルに加え、それらのセクションラベルに埋め込まれた、重要ないくつかの補足的なキューを使用し、タグの煩雑さを避けます。
• 翻訳では、直訳の語順よりも歌唱性と感情的な意図を優先します。