setup-artist

アーティストのワークスペース

すべてのアーティストにワークスペースがあります。ここにはコンテキスト、楽曲、参考資料が保存されます。ルートにある RECOUP.md ファイルが、Recoupable プラットフォームとワークスペースを接続します。

アーティストのディレクトリは、サンドボックス内の orgs/{org}/artists/{artist-slug}/ にあります。

アーティストのワークスペースに入る

アーティストのディレクトリで作業を始めるときは、次の手順に従ってください。

1. RECOUP.md を読み、アーティストのワークスペースであることを確認し、アーティスト名、スラッグ、ID を取得します。
2. 何があるか確認します。ディレクトリで ls を実行し、すでに存在するファイルやフォルダーを確認します。
3. context/artist.md が存在する場合は読みます。これはアーティストの人物像を示す信頼できる情報源です。行うすべての作業は、この内容と一貫している必要があります。
4. このアーティストに関する最近の Git 履歴を確認します。リポジトリのルートから git log --oneline -10 -- artists/{artist-slug}/ を実行すると、このアーティストのファイルに変更を加えたコミットのみが表示されます。すでにアーティストのディレクトリ内にいる場合は、代わりに git log --oneline -10 -- . を使用します。自分で変更を加える前に、コミットメッセージを読んで最近の変更を把握してください。

---

アーティストのディレクトリで作業する

ファイルの配置先

内容がそろったアーティストのワークスペースは、次のようになります。ここにあるものは事前に作成されていません。ファイルやディレクトリは、実際のコンテンツができたときに追加されます。

{artist-slug}/
├── RECOUP.md                    # identity — connects workspace to the platform
├── context/
│   ├── artist.md                # who they are, how they present, creative constraints
│   ├── audience.md              # who listens and what resonates
│   └── images/
│       └── face-guide.png       # face reference for visual content generation
└── songs/
    └── {song-slug}/
        ├── {song-slug}.mp3
        └── {song-slug}.wav

ファイルやディレクトリがまだ存在しない場合は、コンテンツができたときに作成します。すでに存在する場合は、まず内容を読んでから更新します。確認せずに上書きしてはいけません。ディレクトリ構造はひな形からではなく、作業を通じて形作られます。

静的コンテキストと動的コンテキスト

アーティストのコンテキストは、次の2つの層で考えてください。

静的コンテキストは、アーティストがどのような人物であるかを示します。数か月、リリースサイクル、キャリアの段階を経て、ゆっくりと変化します。artist.md と audience.md は静的な情報です。20歳のベッドルームポップのピアニストは、翌年もベッドルームポップのピアニストかもしれませんが、時とともに新たなサウンドを取り入れたり、スタイルを変えたり、異なるオーディエンスに届くようになったりすることがあります。静的コンテキストは慎重に更新し、安易に変更しないでください。artist.md を変更すると、すべてのツールやエージェントが参照する信頼できる情報源を変更することになります。

動的コンテキストは、今起きていることを示します。リリース関連ドキュメント、キャンペーン調査、戦略ドキュメントなどは、特定の時点に結び付いた情報です。追記されたり、古くなったり、次のサイクルで置き換えられたりします。これらは期間限定の情報として扱ってください。リリースサイクルが終わったときや調査内容が古くなったときは、作業ディレクトリを散らかしたままにせず、アーカイブしてください。

この区別が重要なのは、ワークスペースを読むエージェントが、その情報がアーティストに関する長期的な事実なのか、それとも3か月前の時点での記録なのかを知る必要があるからです。静的コンテキストには信頼できる印象が必要です。動的コンテキストは最新である必要があり、最新でない場合は、作業の妨げにならない場所に移動してください。

アーティストのコンテキスト（context/artist.md）

ワークスペースで最も重要なファイルです。アーティストのアイデンティティ、ブランド、声、スタイル、創作上の制約を定義します。他のツールやエージェントは、ブランドに沿った状態を保つためにこれを読みます。これは静的コンテキストです。アーティストが本当に変化したときに更新し、キャンペーンが変わるたびに更新するものではありません。

実際の情報が得られたら作成してください。実際のデータが含まれた部分的なプロフィールの方が、プレースホルダーだらけの完全なテンプレートよりも有用です。知らないことを作り上げてはいけません。推測で埋めるのではなく、そのセクションは省略してください。

初めて作成するときのセクションごとの構成については、references/artist-template.md を読んでください。記入済みの例については、references/artist-example.md を参照してください。

オーディエンスのコンテキスト（context/audience.md）

ファンがどのような人たちか、何が響くのか、どのような話し方をするのかを記録します。これは静的コンテキストです。オーディエンスはリリースごとに変わるのではなく、アーティストの成長に伴って徐々に変化します。

実際のオーディエンスデータが得られたら作成してください。初めて作成するときは、references/audience-template.md を読んでください。

楽曲

楽曲は素材となるデータです。songs/{song-slug}/ に恒久的に保存します。mp3 のファイル名には楽曲名を使用してください。ファイル名が、後続のツールで楽曲タイトルとして使われます。

songs/adhd/adhd.mp3           ✓  title becomes "adhd"
songs/adhd/audio.mp3          ✗  title becomes "audio"

リリース

曲がリリース（EP、アルバム、シングル）にまとめられる場合、リリースのドキュメントでは曲をスラッグで参照します。曲を複製したり、移動したりはしません。どの曲がリリースに含まれているかを確認するには、リリースのドキュメントを確認してください。

その他のファイルの整理

関連するファイルはまとめてください。競合分析、ブランドガイド、戦略ドキュメントはいずれもリサーチにあたるため、3つのディレクトリに分散させず、同じディレクトリに置きます。新しいディレクトリを作成する前に、既存のディレクトリにファイルを置けないか確認してください。

動的コンテキストが古くなった場合（リリースサイクルの終了や戦略ドキュメントの陳腐化など）は、削除したりアクティブなファイルの置き場所に残したりせず、アーカイブに移動してください。アーカイブは必要になったときに作成し、先回りして作成する必要はありません。

データは1か所に置きます。曲はリリースのフォルダーにコピーせず、songs/ に置きます。コンテキストはリサーチのドキュメントに重複させず、context/ に置きます。別の場所にあるデータを参照する必要がある場合は、コピーせずパスで参照してください。

命名規則

• ディレクトリとスラッグ： lowercase-kebab-case
• 曲ファイル： songs/{song-slug}/{song-slug}.mp3

変更の記録

進捗ログには git の履歴を使用してください。アーティストのディレクトリに対する変更はすべて、変更内容とその理由が伝わるメッセージを付けてコミットしてください。

アーティストのディレクトリに適したコミットメッセージ：

artist: update aesthetic — shifting from bedroom to lo-fi studio (user direction)
songs: add 5 tracks from ADHD EP with lyrics and clips
research: competitive analysis for Q2 release planning
release: update ADHD EP — distributor confirmed as SpaceHeater
context: refine audience — adding Gen Alpha psychographics from fan survey
archive: move pre-release strategy docs from ADHD EP cycle

形式は {what}: {why} です。「what」には対象領域を記し、「why」には次のエージェントに意図を伝えます。単に何かが変更されたということだけでなく、変更した理由を伝えてください。これは、将来のエージェントが更新の意図的な進化なのか、間違いなのかを理解する必要がある、静的コンテキストの変更において特に重要です。

アーティストごとに別の進捗ファイルを管理しないでください。git のログが信頼できる情報源です。何が起きたかを把握する必要がある場合は、コミットを読んでください。

この構成の理由

以前のアーティスト用ワークスペースには、あらかじめ作成された10以上のディレクトリ、すべてのフォルダーに置かれた README ファイル、プレースホルダーのテンプレート、スコープ付きメモリーシステム、アーティストごとの設定ファイルがありました。その大半はすぐに古くなりました。エージェントには、実データと足場となるファイルを見分けられなかったためです。{placeholder} トークンだらけのファイルは、作成時にその場にいなかったエージェントには実データのように見えてしまい、出力の質が損なわれます。

現在の構成は意図的に最小限にしています。実際のコンテンツを入れる必要が生じるまで、何も作成しません。このスキルはファイルの配置場所を示し、作業の進行に合わせてエージェントがワークスペースを自然に構築できるようにします。