artist-workspace

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Artist Workspace

艺术家工作区

Every artist has a workspace — a directory that holds context, songs, and reference material. The

RECOUP.md

file at the root connects it to the Recoupable platform.

Artist directories live inside the sandbox at

artists/{artist-slug}/

. The sandbox is already scoped to a single Recoupable organization (its repo is the org), so artists live at the top level — there is no

orgs/

directory.

每位艺术家都拥有一个工作区——用于存储信息、歌曲和参考资料的目录。根目录下的

RECOUP.md

文件将其与Recoupable平台关联。

艺术家目录存储在sandbox的

artists/{artist-slug}/

路径下。sandbox已限定为单个Recoupable组织（其仓库即为该组织），因此艺术家目录位于顶层——不存在

orgs/

目录。

Listing what's in the sandbox

列出sandbox中的内容

When the account asks "what artists do I have", "list my artists", "which orgs am I in", or any other inventory question about the sandbox, walk the filesystem — it is authoritative for this sandbox. Do not call the Recoupable API for this: the API answers "what artists does this account have access to across everything", which is a different (and usually larger) set than what the sandbox was opened for.

bash

undefined

当用户询问“我有哪些艺术家”“列出我的艺术家”“我属于哪些组织”或其他关于sandbox的库存问题时，遍历文件系统——它是当前sandbox的权威来源。请勿调用Recoupable API获取此类信息：API返回的是“该账户可访问的所有艺术家”，这与当前打开的sandbox中的艺术家集合不同（通常范围更大）。

bash

undefined

All artist workspaces in this sandbox

当前sandbox中的所有艺术家工作区

ls -d artists/*/ 2>/dev/null

Every artist's identity file — read the frontmatter for name/slug/id

每位艺术家的身份文件——读取前置元数据获取名称/别名/ID

find artists -type f -name RECOUP.md 2>/dev/null


Each `RECOUP.md` has frontmatter (`artistName`, `artistSlug`, `artistId`) — read it with `head` or any YAML parser to get the canonical identity.

If `artists/` does not exist, the sandbox has not been set up yet — point the account at the `setup-sandbox` skill rather than inventing data.

find artists -type f -name RECOUP.md 2>/dev/null


每个`RECOUP.md`文件都包含前置元数据（`artistName`、`artistSlug`、`artistId`）——可使用`head`命令或任意YAML解析器读取，以获取标准身份信息。

若`artists/`目录不存在，说明sandbox尚未设置——请引导用户使用`setup-sandbox` Skill，而非编造数据。

Creating a new artist

创建新艺术家

When the user asks to create a new artist (or onboard, add, or set one up), drive the work from a checklist file — don't try to run the chain from memory. The setup is 8 sequential API calls and the agent loop loses state between turns; the checklist is what lets you resume cleanly and prove which steps actually ran.

当用户要求创建新艺术家（或引入、添加、设置艺术家）时，基于清单文件推进工作——不要尝试仅凭记忆执行流程。设置过程包含8个连续的API调用，且Agent循环在轮次间会丢失状态；清单文件可让你干净地恢复流程，并证明已执行的步骤。

Step 0: Scaffold the workspace BEFORE any API call

步骤0：在任何API调用前搭建工作区

Pick a slug, make the directory, and write the initial

RECOUP.md

template — frontmatter holds the values the chain captures, body holds the unchecked steps:

bash

ARTIST_SLUG=$(echo "$ARTIST_NAME" | tr '[:upper:]' '[:lower:]' | sed 's/[^a-z0-9]\+/-/g; s/^-//; s/-$//')
ARTIST_DIR="artists/$ARTIST_SLUG"
mkdir -p "$ARTIST_DIR"

cat > "$ARTIST_DIR/RECOUP.md" <<EOF
---
artistName: $ARTIST_NAME
artistSlug: $ARTIST_SLUG
artistId:
spotifyArtistId:
spotifyProfileUrl:
imageUrl:
cmArtistId:
---

选择一个slug，创建目录，并写入初始的

RECOUP.md

模板——前置元数据存储流程捕获的值，正文存储未完成的步骤：

bash

ARTIST_SLUG=$(echo "$ARTIST_NAME" | tr '[:upper:]' '[:lower:]' | sed 's/[^a-z0-9]\+/-/g; s/^-//; s/-$//')
ARTIST_DIR="artists/$ARTIST_SLUG"
mkdir -p "$ARTIST_DIR"

cat > "$ARTIST_DIR/RECOUP.md" <<EOF
---
artistName: $ARTIST_NAME
artistSlug: $ARTIST_SLUG
artistId:
spotifyArtistId:
spotifyProfileUrl:
imageUrl:
cmArtistId:
---

$ARTIST_NAME

Setup checklist

Notes

EOF


Don't proceed to step 1 until the file exists on disk.

The full curl-by-curl playbook for steps 1–8 lives at `https://developers.recoupable.com/workflows/create-artist` and is also linked from the `recoup-api` skill. Fetch it once at scaffold time and follow it in order.

EOF


在文件写入磁盘前，请勿进入步骤1。

步骤1至8的完整curl操作指南位于`https://developers.recoupable.com/workflows/create-artist`，同时也在`recoup-api` Skill中提供链接。在搭建阶段获取该指南，并按顺序执行。

After every step: tick + persist

每完成一步：勾选并持久化

Two writes back to

RECOUP.md

after each step completes:

Tick the checkbox (
```
- [ ]
```
→
```
- [x]
```
) for the step that just ran.
Write the captured value into frontmatter (
```
artistId:
```
,
```
spotifyArtistId:
```
,
```
spotifyProfileUrl:
```
,
```
imageUrl:
```
,
```
cmArtistId:
```
). Later steps read these values from the frontmatter — never re-derive what's already saved. Larger payloads (research responses, social URLs) belong under their own headed subsection in the body, not in frontmatter.

The file IS the workflow state. If a value isn't on disk, the next turn doesn't know it.

每完成一个步骤后，需对

RECOUP.md

进行两处修改：

勾选复选框（将
```
- [ ]
```
改为
```
- [x]
```
）标记已完成的步骤。
将捕获的值写入前置元数据（
```
artistId:
```
、
```
spotifyArtistId:
```
、
```
spotifyProfileUrl:
```
、
```
imageUrl:
```
、
```
cmArtistId:
```
）。后续步骤将从前置元数据中读取这些值——切勿重新推导已保存的内容。较大的 payload（研究响应、社交平台链接）应放在正文中对应的小节下，而非前置元数据中。

该文件即为工作流状态。若值未存储在磁盘上，下一轮次将无法获取。

Resuming a partial setup

恢复未完成的设置

$ARTIST_DIR/RECOUP.md

already exists, do not re-run completed steps. Read the file, find the first unchecked item, and resume from there using the captured frontmatter values:

bash

undefined

若

$ARTIST_DIR/RECOUP.md

已存在，请勿重新执行已完成的步骤。读取该文件，找到第一个未勾选的项，并使用已捕获的前置元数据值从该处恢复：

bash

undefined

Show the next unchecked step

显示下一个未完成的步骤

grep -n '^- [ ]' "$ARTIST_DIR/RECOUP.md" | head -1


If every item is checked, the artist is fully set up — confirm with the user before doing anything else.

grep -n '^- [ ]' "$ARTIST_DIR/RECOUP.md" | head -1


若所有项均已勾选，说明艺术家已完全设置完成——在执行其他操作前请与用户确认。

Why the checklist

使用清单的原因

Long deterministic chains executed from prose tend to drop steps: the agent reads the doc once, runs a few calls, and forgets the rest. A file-as-state checklist sidesteps that — progress is visible on disk, every step has a write-back side effect, and a fresh turn can resume from the file rather than re-deriving what's already been done.

基于 prose 执行的长确定性流程容易遗漏步骤：Agent读取文档一次，执行几次调用后就会忘记剩余步骤。以文件作为状态的清单可避免此问题——进度在磁盘上可见，每个步骤都有写入操作的副作用，新的轮次可从文件恢复，而非重新推导已完成的内容。

Entering an Artist Workspace

进入艺术家工作区

When starting work in an artist directory:

Read
```
RECOUP.md
```
to confirm you're in an artist workspace and get the artist's name, slug, and ID.
Check what exists —
```
ls
```
the directory to see which files and folders are already there.
Read
```
context/artist.md
```
if it exists — this is the source of truth for who the artist is. Everything you do should be consistent with it.
Check recent git history for this artist — from the repo root,
```
git log --oneline -10 -- artists/{artist-slug}/
```
shows only commits that touched this artist's files. If you're already inside the artist directory, use
```
git log --oneline -10 -- .
```
instead. Read the commit messages to understand recent changes before making your own.

开始在艺术家目录中工作时：

读取
```
RECOUP.md
```
以确认处于艺术家工作区，并获取艺术家的名称、slug和ID。
检查已有内容——使用
```
ls
```
命令查看目录中已有的文件和文件夹。
若存在
```
context/artist.md
```
，请读取该文件——这是艺术家身份的权威来源。所有操作均应与其保持一致。
查看该艺术家的近期git历史——从仓库根目录执行
```
git log --oneline -10 -- artists/{artist-slug}/
```
可查看仅涉及该艺术家文件的提交记录。若已在艺术家目录内，可改用
```
git log --oneline -10 -- .
```
。在进行修改前，读取提交消息以了解近期变更。

Working in an Artist Directory

在艺术家目录中工作

What Goes Where

内容存放规则

A populated artist workspace looks like this. Nothing here is pre-created — each file and directory gets added when there's real content for it.

{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
├── releases/
│   ├── top-tracks.md            # cross-release Spotify top tracks (snapshot)
│   └── {release-slug}/          # one folder per album / EP / single
│       └── RELEASE.md           # tracklist + Spotify metadata + cover art URL
└── songs/
    └── {song-slug}/
        ├── {song-slug}.mp3
        └── {song-slug}.wav

If a file or directory doesn't exist yet, create it when the content arrives. If it already exists, update it — don't overwrite without reading what's there first. The directory structure emerges from the work, not from scaffolding.

一个已填充内容的艺术家工作区结构如下。所有文件和目录均不会预先创建——仅当有实际内容时才会添加。

{artist-slug}/
├── RECOUP.md                    # 身份信息——关联工作区与平台
├── context/
│   ├── artist.md                # 艺术家身份、品牌呈现、创作约束
│   ├── audience.md              # 受众群体及偏好
│   └── images/
│       └── face-guide.png       # 面部参考图，用于生成视觉内容
├── releases/
│   ├── top-tracks.md            # 跨发行作品的Spotify热门曲目（快照）
│   └── {release-slug}/          # 每张专辑/EP/单曲对应一个文件夹
│       └── RELEASE.md           # 曲目列表 + Spotify元数据 + 封面URL
└── songs/
    └── {song-slug}/
        ├── {song-slug}.mp3
        └── {song-slug}.wav

若文件或目录尚未存在，在有内容时创建它。若已存在，则进行更新——在覆盖前务必先读取原有内容。目录结构随工作推进自然形成，而非预先搭建。

Static vs Dynamic Context

静态信息与动态信息

Think of artist context in two layers:

Static context is who the artist IS. It evolves slowly — across months, release cycles, career phases.

artist.md

and

audience.md

are static. A 20-year-old bedroom-pop pianist might still be a bedroom-pop pianist next year, but over time she may grow into new sonics, shift her aesthetic, or reach a different audience. Update static context deliberately, not casually. When you change

artist.md

, you're changing the source of truth that every tool and agent relies on.

Dynamic context is what's happening NOW. Release documents, campaign research, strategy docs — these are tied to a moment in time. They get appended to, they go stale, they get replaced by the next cycle. Treat them as time-bound. When a release cycle ends or research becomes outdated, archive it rather than letting it clutter the working directory.

This distinction matters because agents reading the workspace need to know: is this a durable fact about the artist, or a snapshot from three months ago? Static context should feel trustworthy. Dynamic context should feel current — and if it's not current, it should be moved out of the way.

艺术家信息分为两层：

静态信息是艺术家的本质属性。它的演变速度缓慢——以月、发行周期或职业阶段为单位。

artist.md

和

audience.md

属于静态信息。一位20岁的卧室流行钢琴家明年可能仍是卧室流行风格，但随着时间推移，她可能会探索新的音效、改变审美或接触不同的受众。请谨慎更新静态信息，而非随意修改。修改

artist.md

时，你正在改变所有工具和Agent依赖的权威来源。

动态信息是当前正在发生的事情。发行文档、营销研究、策略文档——这些都与特定时间点相关。它们会被追加内容、过时，或被下一周期的文档取代。请将其视为有时间限制的内容。当发行周期结束或研究内容过时，应将其归档，而非留在工作目录中造成混乱。

这种区分至关重要，因为读取工作区的Agent需要知道：这是关于艺术家的持久事实，还是三个月前的快照？静态信息应值得信赖。动态信息应保持时效性——若已过时，应移至其他位置。

Artist Context (

context/artist.md

)

艺术家信息（

context/artist.md

）

The most important file in the workspace. Defines identity, brand, voice, aesthetic, and creative constraints. Other tools and agents read it to stay on-brand. This is static context — update it when the artist genuinely evolves, not for every campaign shift.

Create it when you have real information. A partial profile with real data beats a complete template with placeholders. Don't fabricate details you don't know — leave sections out rather than guessing.

Read

references/artist-template.md

for the section-by-section structure when creating one for the first time. See

references/artist-example.md

for what a filled one looks like.

工作区中最重要的文件。定义了艺术家的身份、品牌、风格、审美和创作约束。其他工具和Agent会读取该文件以保持品牌一致性。这属于静态信息——仅当艺术家真正发生演变时才更新，而非针对每次营销活动调整。

仅当有真实信息时才创建该文件。包含真实数据的部分资料优于充满占位符的完整模板。切勿编造未知的细节——未知部分可留空，而非猜测。

首次创建时，可参考

references/artist-template.md

的章节结构。

references/artist-example.md

展示了完整填充后的样式。

Audience Context (

context/audience.md

)

受众信息（

context/audience.md

）

Who the fans are, what resonates with them, how they talk. Static context — the audience shifts gradually as the artist grows, not with every release.

Create when you have real audience data. Read

references/audience-template.md

when creating it for the first time.

粉丝群体特征、偏好及沟通方式。属于静态信息——受众随艺术家成长逐渐变化，而非随每次发行变更。

仅当有真实受众数据时才创建该文件。首次创建时可参考

references/audience-template.md

。

Songs

歌曲

Songs are the source material. They live in

songs/{song-slug}/

permanently. Name the mp3 after the song — the filename becomes the song title in downstream tools.

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

歌曲是核心素材。它们永久存储在

songs/{song-slug}/

路径下。将mp3文件命名为歌曲名——文件名会成为下游工具中的歌曲标题。

songs/adhd/adhd.mp3           ✓  标题为“adhd”
songs/adhd/audio.mp3          ✗  标题为“audio”

Releases

发行作品

Releases live at

releases/{release-slug}/

. Each release is a folder with a

RELEASE.md

at the root — the master release-management document that travels with the release through every lifecycle stage (announcement, release week, sustain). Every other release-level artifact (research, copy, assets, derivative reports) goes in the same folder.

Slug convention —

lowercase-kebab-case

of the project title plus a format suffix:

Album →
```
releases/{title-slug}/
```
(no suffix — album is the default)
EP →
```
releases/{title-slug}-ep/
```
Single →
```
releases/{title-slug}-single/
```
Compilation →
```
releases/{title-slug}-compilation/
```

releases/after-hours/RELEASE.md          # album
releases/adhd-ep/RELEASE.md              # EP
releases/blinding-lights-single/RELEASE.md

The

RELEASE.md

is 18 sections covering project snapshot, identifiers + metadata, narrative, audience, DSP strategy, marketing, social, PR, visuals, physical/merch/touring, team, budget, KPI tracking, and a links hub — plus an Outstanding Deliverables table and a Document History log. Read

references/release-template.md

for the full canonical template, sharing-tag conventions (

[INTERNAL]

[SHAREABLE]

[OPS]

), and status markers (

✅

❌

⚠️ TBD

N/A

It references songs by slug — it doesn't duplicate or move them.

发行作品存储在

releases/{release-slug}/

路径下。每个发行作品对应一个文件夹，根目录下有一个

RELEASE.md

文件——这是发行管理的主文档，会伴随发行作品经历整个生命周期（预告、发行周、持续推广）。所有其他发行层面的资料（研究、文案、资产、衍生报告）均存放在同一文件夹中。

Slug命名规则——项目标题的

小写短横线格式

加上类型后缀：

专辑 →
```
releases/{title-slug}/
```
（无后缀——专辑为默认类型）
EP →
```
releases/{title-slug}-ep/
```
单曲 →
```
releases/{title-slug}-single/
```
合辑 →
```
releases/{title-slug}-compilation/
```

releases/after-hours/RELEASE.md          # 专辑
releases/adhd-ep/RELEASE.md              # EP
releases/blinding-lights-single/RELEASE.md

RELEASE.md

包含18个章节，涵盖项目快照、标识符与元数据、叙事、受众、DSP策略、营销、社交、公关、视觉、实体/周边/巡演、团队、预算、KPI追踪以及链接中心——此外还有待交付事项表和文档历史日志。完整的标准模板、共享标签规则（

[INTERNAL]

[SHAREABLE]

[OPS]

）和状态标记（

✅

❌

⚠️ TBD

N/A

）可参考

references/release-template.md

。

该文件通过slug引用歌曲——不会复制或移动歌曲文件。

Where Spotify catalog data lands

Spotify目录数据的存储位置

Step 5 of the create-artist chain (Spotify catalog) populates this folder:

Each album returned by
GET /api/spotify/artist/albums
→
```
releases/{release-slug}/RELEASE.md
```
scaffolded from
```
references/release-template.md
```
. Step 5 fills the Spotify-derivable fields (Section 1: artist name, project title, release date, format; Section 2.1: Spotify URI; Section 2.2: per-track title + duration + explicit; Section 2.3: cross-reference local
```
songs/
```
; Section 18: cover art URL) and leaves everything else as
```
⚠️ TBD
```
. ISRC, UPC, writers/producers, label, distributor, and all marketing/PR/budget sections aren't in the public Spotify response — they stay TBD until the user provides them. See
```
references/release-template.md
```
for the full mapping.

GET /api/spotify/artist/topTracks
→

releases/top-tracks.md

(cross-release snapshot — these aren't a release themselves but live here because it's all Spotify catalog data and pinning it next to releases keeps the catalog in one place). Inline structure:

markdown

---
title: Top Tracks
source: spotify
snapshotDate: {YYYY-MM-DD}
---

# Top Tracks

| # | Track | Album | Duration |
|---|-------|-------|----------|
| 1 | {name} | {album-slug or external} | {mm:ss} |

创建艺术家流程的步骤5（Spotify目录）会填充此文件夹：

GET /api/spotify/artist/albums
返回的每张专辑 → 基于
```
references/release-template.md
```
生成
```
releases/{release-slug}/RELEASE.md
```
。步骤5会填充可从Spotify获取的字段（第1章：艺术家名称、项目标题、发行日期、格式；第2.1节：Spotify URI；第2.2节：单轨标题+时长+是否含 explicit 内容；第2.3节：关联本地
```
songs/
```
目录；第18章：封面URL），其余字段保留为
```
⚠️ TBD
```
。ISRC、UPC、词曲作者/制作人、厂牌、发行商以及所有营销/公关/预算字段未包含在公开的Spotify响应中——需等待用户提供后再填充。完整的字段映射可参考
```
references/release-template.md
```
。

GET /api/spotify/artist/topTracks
返回的内容 → 存储为

releases/top-tracks.md

（跨发行作品的快照——这些并非独立发行作品，但因属于Spotify目录数据，与发行作品放在一起可保持目录结构统一）。内联结构如下：

markdown

---
title: Top Tracks
source: spotify
snapshotDate: {YYYY-MM-DD}
---

# Top Tracks

| # | Track | Album | Duration |
|---|-------|-------|----------|
| 1 | {name} | {album-slug or external} | {mm:ss} |

Organizing Other Files

其他文件的组织

Group related files together. A competitive analysis, brand bible, and strategy doc are all research — they belong in the same directory, not scattered across three. Before creating a new directory, check if the file fits somewhere that already exists.

When dynamic context gets stale — a release cycle ends, a strategy doc becomes outdated — move it to an archive rather than deleting it or leaving it where active files live. Create the archive when you need it, not before.

Data lives in one place. Songs live in

songs/

, not copied into release folders. Context lives in

context/

, not duplicated into research docs. If something needs to reference data from another location, reference it by path — don't copy it.

将相关文件分组存放。竞品分析、品牌手册和策略文档均属于研究资料——应放在同一目录中，而非分散存放。创建新目录前，请检查文件是否可放入已存在的目录。

当动态信息过时（如发行周期结束、策略文档失效），应将其移至归档目录，而非删除或留在活跃文件目录中。仅当需要时才创建归档目录。

数据仅存放在一处。歌曲存放在

songs/

目录，而非复制到发行文件夹中。信息存放在

context/

目录，而非复制到研究文档中。若需要引用其他位置的数据，请通过路径引用——不要复制。

Naming Conventions

命名规则

Directories and slugs:
```
lowercase-kebab-case
```
Song files:
```
songs/{song-slug}/{song-slug}.mp3
```

目录和slug：
```
小写短横线格式
```
歌曲文件：
```
songs/{song-slug}/{song-slug}.mp3
```

Tracking Changes

变更追踪

Use git history as the progress log. Every change to an artist directory should be a commit with a message that captures what changed and why.

Good commit messages for artist directories:

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

The pattern:

{what}: {why}

. The "what" tells you the area. The "why" tells the next agent the intent — not just that something changed, but the reason it changed. This is especially important for static context changes, where a future agent needs to understand whether an update was a deliberate evolution or a mistake.

Don't maintain a separate progress file per artist. The git log is the source of truth. If you need to understand what happened, read the commits.

将git历史作为进度日志。对艺术家目录的每一次变更都应提交为一个git commit，提交消息需说明变更内容及原因。

Why This Structure

艺术家目录的优质提交消息示例：

Artist workspaces used to have 10+ pre-created directories, README files in every folder, placeholder templates, a scoped memory system, and per-artist config files. Most of it went stale immediately because agents couldn't tell what was real data versus scaffolding. A file full of

{placeholder}

tokens looks like real data to an agent that wasn't there when it was created — and the output suffers.

The current structure is deliberately minimal. Nothing gets created until there's real content to put in it. The skill teaches where things go so agents can build the workspace organically as the work happens.

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

格式：

{领域}: {原因}

。“领域”说明变更所属的区域。“原因”告知后续Agent变更的意图——不仅是变更内容，还包括变更的理由。这对于静态信息变更尤为重要，未来的Agent需要了解更新是有意的演变还是错误操作。

无需为每位艺术家维护单独的进度文件。git日志是权威来源。若需了解历史变更，请读取提交记录。

—

此结构的设计原因

—

艺术家工作区曾包含10+个预先创建的目录、每个文件夹中的README文件、占位符模板、限定范围的内存系统以及每位艺术家的配置文件。其中大部分内容很快过时，因为Agent无法区分真实数据与预搭建内容。充满

{placeholder}

标记的文件会让未参与创建的Agent误以为是真实数据——进而影响输出质量。

当前结构刻意保持极简。仅当有真实内容时才创建文件或目录。本Skill指导内容的存放位置，以便Agent可随工作推进有机地构建工作区。

artist-workspace

Original

Translation

Artist Workspace

艺术家工作区

Listing what's in the sandbox

列出sandbox中的内容

All artist workspaces in this sandbox

当前sandbox中的所有艺术家工作区

Every artist's identity file — read the frontmatter for name/slug/id

每位艺术家的身份文件——读取前置元数据获取名称/别名/ID

Creating a new artist

创建新艺术家

Step 0: Scaffold the workspace BEFORE any API call

步骤0：在任何API调用前搭建工作区

$ARTIST_NAME

$ARTIST_NAME

Setup checklist

Setup checklist

Notes

Notes

After every step: tick + persist

每完成一步：勾选并持久化

Resuming a partial setup

恢复未完成的设置

Show the next unchecked step

显示下一个未完成的步骤

Why the checklist

使用清单的原因

Entering an Artist Workspace

进入艺术家工作区

Working in an Artist Directory

在艺术家目录中工作

What Goes Where

内容存放规则

Static vs Dynamic Context

静态信息与动态信息

Artist Context (context/artist.md)

艺术家信息（context/artist.md）

Audience Context (context/audience.md)

受众信息（context/audience.md）

Songs

歌曲

Releases

发行作品

Where Spotify catalog data lands

Spotify目录数据的存储位置

Organizing Other Files

其他文件的组织

Naming Conventions

命名规则

Tracking Changes

变更追踪

Why This Structure

艺术家目录的优质提交消息示例：

此结构的设计原因

Artist Context (
`context/artist.md`
)

艺术家信息（
`context/artist.md`
）

Audience Context (
`context/audience.md`
)

受众信息（
`context/audience.md`
）