setup-artist

Artist 工作区

每位 Artist 都有一个工作区——一个存放背景信息、歌曲和参考资料的目录。根目录中的 RECOUP.md 文件将其关联到 Recoupable 平台。

Artist 目录位于沙盒内的 orgs/{org}/artists/{artist-slug}/。

进入 Artist 工作区

在 Artist 目录中开始工作时：

1. 阅读 RECOUP.md，确认你位于 Artist 工作区，并获取 Artist 的名称、slug 和 ID。
2. 检查已有内容——对目录执行 ls，查看其中已有的文件和文件夹。
3. 如果 context/artist.md 存在，则阅读它——这是了解 Artist 身份的准确信息来源。你的所有操作都应与之保持一致。
4. 查看该 Artist 最近的 git 历史记录——在仓库根目录中，git log --oneline -10 -- artists/{artist-slug}/ 仅显示涉及该 Artist 文件的提交。如果你已位于 Artist 目录中，则改用 git log --oneline -10 -- .。阅读提交信息，了解近期变更后再进行自己的修改。

---

在 Artist 目录中工作

文件放在哪里

内容齐全的 Artist 工作区如下所示。这里没有预先创建的内容——只有在有实际内容时，才会添加相应的文件和目录。

{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

如果文件或目录尚不存在，请在有内容时创建。如果已经存在，则更新它——先阅读现有内容，不要直接覆盖。目录结构应随着工作逐步形成，而不是预先搭建。

静态与动态背景信息

将 Artist 背景信息分为两层：

静态背景信息描述 Artist 本身。它变化缓慢——可能跨越数月、多个发行周期和职业阶段。artist.md 和 audience.md 都属于静态信息。一位 20 岁的卧室流行钢琴演奏者明年可能依然如此，但随着时间推移，她也可能发展出新的音色、改变美学风格，或触达不同的受众。应审慎更新静态背景信息，不要随意更改。修改 artist.md 时，你改变的是所有工具和 Agent 所依赖的准确信息来源。

动态背景信息描述当下正在发生的事情。发行文档、宣传活动调研和策略文档等都与特定时间相关。它们会不断补充内容，也会过时，并被下一个周期的内容取代。应将其视为有时效性的信息。发行周期结束或调研过时后，应将其归档，而不是任由它们堆积在工作目录中。

这一区分很重要，因为读取工作区的 Agent 需要知道：这是关于 Artist 的长期事实，还是三个月前的快照？静态背景信息应值得信赖。动态背景信息应保持最新；如果不再最新，就应将其移出当前工作区。

Artist 背景信息（context/artist.md）

这是工作区中最重要的文件。它定义了身份、品牌、表达风格、美学和创作限制。其他工具和 Agent 会读取它，以保持品牌一致性。这属于静态背景信息——只有在 Artist 确实发生变化时才更新，不要因每次宣传活动的调整而修改。

有了真实信息后再创建。包含真实数据的不完整档案，胜过带有占位符的完整模板。不要捏造不了解的细节——宁可省略章节，也不要猜测。

首次创建时，请阅读 references/artist-template.md，了解各章节的结构。查看 references/artist-example.md，了解填写完成后的样子。

受众背景信息（context/audience.md）

描述粉丝群体、能引起他们共鸣的内容，以及他们的表达方式。这属于静态背景信息——受众会随着 Artist 的成长逐渐变化，而不是每次发行都发生变化。

有了真实的受众数据后再创建。首次创建时，请阅读 references/audience-template.md。

歌曲

歌曲是素材来源。它们会永久存放在 songs/{song-slug}/ 中。mp3 文件以歌曲名称命名——下游工具会将文件名用作歌曲标题。

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

发布

当歌曲归入某个发布内容（EP、专辑、单曲）时，发布文档会通过 slug 引用这些歌曲，而不会复制或移动它们。如果需要了解某个发布内容包含哪些歌曲，请查看发布文档。

整理其他文件

将相关文件归在一起。竞品分析、品牌手册和策略文档都属于研究内容，应放在同一目录中，而不是分散到三个目录。创建新目录前，先检查文件是否适合放到已有目录中。

当动态上下文过时——例如发布周期结束、策略文档不再适用——应将其移至归档目录，而不是删除它或留在存放活跃文件的位置。需要时再创建归档目录，无需提前创建。

数据只存放在一个地方。歌曲放在 songs/ 中，不要复制到发布文件夹。上下文放在 context/ 中，不要重复到研究文档里。如果需要引用其他位置的数据，请通过路径引用，不要复制。

命名约定

• 目录和 slug： 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」让下一个 Agent 了解意图——不仅说明发生了变更，还说明变更的原因。这对于静态上下文变更尤其重要，因为后续 Agent 需要判断更新是有意调整，还是误操作。

不要为每位艺人单独维护进度文件。git 日志才是事实来源。如需了解发生了什么，请查看提交记录。

为什么采用这种结构

艺人工作区过去预先创建了 10 多个目录，每个文件夹中都有 README 文件、占位模板、专属记忆系统和每位艺人各自的配置文件。其中大部分很快就过时了，因为 Agent 无法分辨哪些是真实数据，哪些只是框架文件。对于未参与创建过程的 Agent 来说，满是 {placeholder} 标记的文件看起来像真实数据，结果也会受到影响。

当前结构刻意保持精简。只有在有真实内容需要存放时，才会创建相应内容。该技能会指导文件的存放位置，让 Agent 能随着工作的推进，自然而然地构建工作区。