# Run an AI Music Label: start prompts

Paste this into your AI after you get Run an AI Music Label.

There are two prompts. Paste the first one in the session where you start using the journal on your label or your own catalog. Paste the second one at the start of every later session, so your AI picks up where it stopped.

## Prompt 1: first session (read, map, audit)

```text
I bought the journal "Run an AI Music Label". It is a field manual from a label that runs several artist profiles on Spotify through DistroKid: generating or bringing tracks, giving the catalog one identity with covers, visualizers and lyric videos, distributing, pitching each release in time for Release Radar, adding a Canvas, syncing the content drip to release dates, staying compliant, and reading the real royalty economics before spending on promotion. Your job is to read it, map my label onto its pipeline, and help me run that pipeline in the journal's order, one step at a time, checking each step the way the journal says.

WHAT IT IS FOR
Running releases end to end, with AI-generated music or my own recordings: the license gate, the catalog, the brand pack, covers, visualizers and lyric videos, the DistroKid upload, the release calendar, the Spotify for Artists pitch and Canvas, the release-synced drip to YouTube and Instagram, AI disclosure and the anti-fraud rules.

WHEN TO USE IT
- Before you generate a track for release, or upload anything to DistroKid.
- Before you set or move a release date, or pitch a release.
- Before you render a cover, a visualizer, a lyric video, a Canvas or a reel.
- Before anyone spends money on promotion.
- When I say "it missed Release Radar", "the date will not change", "the upload bounced", "the Canvas failed", "the videos did not go live".

HOW TO GET AND READ THE JOURNAL
- With the Vibedna connector: call list_library, find the slug run-an-ai-music-label, then read_journal(slug="run-an-ai-music-label", part=1), then part=2, 3 and so on until there are no more parts. Read every part before you propose changes.
- With Journals DNA paired: journal_get(slug="run-an-ai-music-label") writes it into ~/.journal/library; read it from there with journal_read (use offset and limit).
- Read in this order: "What to bring, and what to do first" and "How to read the decisions here" first (platforms change their flows, payout rates and AI policies: keep the reasoning, re-check every number against the live source). Then "The honest money, first", and do its multiplication with me. Then "Works the same with your own recordings" and the section for the step we are on. Before any change, check "Bug to Root Cause to Fix catalog", "Decisions and reasoning" and "Lessons for the next label". The dated entries at the end are the newest lessons and win over older text.

ASK ME FIRST (only what the journal says decides the run)
1. AI-generated or my own recordings? (With my own finished tracks we skip generation and start at identity.)
2. If AI: which generation tool and plan, and does its license explicitly allow distribution to streaming? Was anything generated on a free plan?
3. How many artist profiles will I run? (The distributor plan caps artist names; decide before choosing a plan.)
4. What release pace per profile, and on which weekday? (At least seven days between releases on the same profile.)
5. Instrumental, vocal, or both? (Instrumentals get a visualizer, vocal releases a lyric video.)
6. Which stages do I want: all of them, or only some (covers, visualizers, distribution, pitching, the drip)?
7. How many streams do I honestly expect in the first year? We multiply it by the current per-stream rate before building anything.

THE PIPELINE, IN THE JOURNAL'S ORDER
1. The money multiplication with my own numbers. If the answer kills the project, stop there.
2. License gate and generation at cadence: paid tier, a paper trail per track (generation date, lyric authorship, clearances), describe the sound and never name an artist, download masters promptly, a unique name per track.
3. Identity as a config: the brand pack every renderer reads (name, logo, palette, fonts, genre words and banned words, handles).
4. Covers from the track name; the release cover feeds every other surface.
5. Visualizer (instrumental) or lyric video (vocal), from one frozen recipe, with per-track facts measured from the audio.
6. Distribute through DistroKid: every dependent flag set, credits with a human's legal name, paid extras unticked, my own file uploaded, a human checkpoint right before the first click that can submit.
7. Calendar and pitch: pitch as soon as the profile's slot is free, space by the queue on that profile, a daily job that reports on itself.
8. Canvas on every release before it goes out, cut from about a quarter of the way in, no URLs or calls to action.
9. The drip: content dates derived from the release date, YouTube scheduled inside the platform, reels on the release day, never a video public before its track is on streaming.
10. Compliance at every step: honest AI disclosure, sane cadence, zero fraud signals.
Growth (outreach to other accounts) is a separate system, built second.

HOW TO VERIFY EACH STEP (the journal's own tests)
- After every action on someone else's interface, read the state back. A banner, a "ready" status or a returned success proves nothing.
- On an album, compare each row's typed title against the file loaded in that row before submitting.
- A pitch, Canvas or Artist Pick counts as done only when it disappears from the release's pending-actions list in Spotify for Artists, checked with a few retries.
- Measure the air of each release: the gap to the previous release in the queue on the same profile.
- A daily job is alive only if its run log has a new line. The scheduler showing "ready" proves the task exists, not that it ran.
- After scheduling on YouTube, re-read each video and compare the publish time, title and description with what you intended. Download the served thumbnail to confirm it changed.
- Address artists by platform id, never by name.

WHAT TO CHECK FIRST
The live state: the generation tool's current terms, the distributor plan and how many artist names it allows, which releases are scheduled for which date on which profile, which are already on the Spotify side and pitchable, what each release still needs in its pending list, and which distributor account the browser session is on.

NEVER
- Never buy streams, followers or placements, never pay anyone to add a track to a playlist, never accept submissions from artists who buy streams, never run public or collaborative playlists, and never sell or rent a playlist or account.
- Never submit a release, change a date, pitch, upload a Canvas, publish or schedule a video or post, or spend on promotion without my yes in this session. Show me the metadata, the date and the text first.
- Never distribute audio whose license does not explicitly allow streaming distribution.
- Never leave a paid add-on ticked, and never take the paid audio enhance: upload my own file.
- Never edit a date while a release is processing; cancel and re-upload while it is still scheduled.
- Never put the artist alias in a credit field; credits name a real person.
- Never process audio to beat an AI detector, and never hide the AI credit (listeners see it).
- Never render a batch before I approve the first piece.
- Never share one Meta app across brands.
- Never write cookies, keys or tokens into a file, a journal or this chat. Keep them in a vault or environment variables.
- Never promise me royalties or income. Statements lag six to eight weeks.

KEEP MY PROJECT JOURNAL
- If I have Journals DNA: after each step, journal_append(name_or_path="<PROJECT>", entry="<step, release, what you did, how you verified it>", tag="ship" or "fix"). When I choose something (pace, profile count, plan, a release date, a promotion budget), journal_decision_add(name_or_path="<PROJECT>", decision="...", why="..."). When the state changes, journal_update_section(name_or_path="<PROJECT>", "Current state", new_content, mode="replace").
- Write the release schedule into my journal the same session you set it, as a table: track, profile, date, one line of why. When a date moves, say what it displaced. The calendar lives inside the distributor's wizard and nowhere else unless we write it down.
- Keep one wiring page as the journal suggests (profiles, scheduled releases, pitch and Canvas status, where the masters live, what still needs me), replaced as it changes and written from the live tools.
- If I do not have Journals DNA: keep a plain <PROJECT>_JOURNAL.md in my project folder with the same entries, the schedule table and the wiring page.

HOW TO REPORT BACK
Result first, in plain words: which step, which release, what you changed, how you verified it. Name the journal section you relied on. End with one question if something needs my decision.

FIRST TASK NOW
Read part 1 of the journal (and the rest before proposing anything). Ask me the seven questions above and do the money multiplication with my answer. Then audit my label against the ten pipeline steps, reading my files, my distributor schedule and Spotify for Artists only: for each step say done, missing or broken, with the evidence, and list every scheduled release with its air in days. Change nothing yet. End with the one step you would do first and why.
```

## Prompt 2: every later session (continue)

```text
We are running my label with the journal "Run an AI Music Label". Continue from where we stopped.

1. Read my project journal first (journal_handoff_brief("<PROJECT>") if I have Journals DNA, or my <PROJECT>_JOURNAL.md, its release table and wiring page). Tell me in five lines what is scheduled, what each release still needs (pitch, Canvas, video), which step is next, and what is waiting on me.
2. Re-open the journal section for the next step (read_journal with the part that holds it, or the copy in ~/.journal/library) and its rows in "Bug to Root Cause to Fix catalog" before you touch anything.
3. Check the live state before you trust my notes: the distributor's schedule, the Spotify for Artists pending lists, the daily job's run log.
4. Do one step on one release, verify it by reading the state back the way the journal says, log it with journal_append, then stop and show me.
5. Submitting, date changes, pitches, Canvas uploads, publishing videos or posts and any promotion spend wait for my yes in this session.
6. At the end of the session, update the release table and replace the Handoff section of my project journal: what is done, what is next, what is blocked by me.
```