# Build an AI Beat & Sample Pack Business: start prompts Paste this into your AI after you get Build an AI Beat & Sample Pack Business. There are two prompts. Paste the first one in the session where you start using the journal on your packs or beats. 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 "Build an AI Beat and Sample Pack Business". It is a field manual from two music catalogues with live, sold packs: which audio I am allowed to resell, how to generate it (a synth I own, Suno on a paid tier, or an open model I fine-tune on my own audio), how to cut, clean, measure and package it like a label release, how to license and price beats, and the audio-specific parts of selling it on a store I own. Your job is to read it, map my catalogue 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 Turning an instrument or an AI tool into packs and beats I can actually sell: the license decision, generation, stems and drum loops, cleaning and file naming, exact tempo and key, automated quality gates, covers, license tiers, the pricing ladder, previews, the pack launch and the buyer's library. WHEN TO USE IT - Before you generate a single sound I intend to sell. - Before you cut loops, separate stems, name files or build a zip. - Before you make a cover, write a license, set a price or put a pack on a store. - When I say "this loop does not wrap", "the BPM is off", "a buyer's library is empty", "the preview clicks", "nobody takes the upsell". HOW TO GET AND READ THE JOURNAL - With the Vibedna connector: call list_library, find the slug sell-ai-beats-and-sample-packs, then read_journal(slug="sell-ai-beats-and-sample-packs", 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="sell-ai-beats-and-sample-packs") writes it into ~/.journal/library; read it from there with journal_read (use offset and limit). - Read in this order: "What you bring, and where this comes from" and "How to read the decisions here" first (every number, price and fade time is a starting point that worked for one catalogue: verify it against my genre, my buyers and my ears). Then "One method, not the only one" and "The license question comes first". Then the method we use and the section for the step we are on. Before any change, check "Bug catalogue: symptom, root cause, fix", "Recurring traps" and "Lessons for the next pack or beat business". - The generic store plumbing (site, login, checkout, webhooks, delivery, email) is not in this journal; it points to a separate journal for that. Do not rebuild it from guesses. ASK ME FIRST (only what the journal says decides the build) 1. Where does my audio come from: a synth I own, a paid AI tool (which one, which plan, since when), a model I fine-tune, or my own recordings? 2. Did I generate anything while on a free plan? (A free plan licenses nothing, and upgrading later does not fix it.) 3. Do I sell packs, beats on a license ladder, or both? Do I also release full tracks on streaming? 4. Which genres, and what tempo range is normal for each? (Tempo labels fold into the genre's range.) 5. Where do I sell: my own site, a marketplace, or both? (One price per product on every channel.) 6. Do I already have live products and buyers? (Then nothing a buyer's library depends on gets deleted.) THE PIPELINE, IN THE JOURNAL'S ORDER 1. License gate: read every document my source publishes (terms of use, product terms, prohibited-use policy), note each "last updated" date, and confirm I may resell isolated output as samples. My buyer license stays inside my source license. 2. Generate with the chosen method. Own synth: one shared tone core for the live synth and the renderer, a fresh instance per file, a click scan. Suno: Studio layer by layer with Multitrack export (it does not spend the monthly download allowance). Own model: training set of audio I own outright only. 3. Stems and loops: only drums separate cleanly from a mix; generate bass and harmony as their own layers. Drum loops cut on a measured beat grid, kick to kick, exact bar count, starting where a part starts (four bars is the safe default). 4. Clean every file the same way, sort into category folders, name files predictably with measured key and tempo. 5. Measure tempo to a fraction of a BPM (beat tracker over the whole track, BPM from the slope) and key with a doubt flag. 6. Run the automated gates on the final package (one note per one-shot, whole transient, dedupe, family checks, loudness target), then my ears decide. 7. Package from an explicit file list into a zip with the license text, a pack file and a manifest. Count only real playable WAVs. 8. Cover from one pristine canonical box image, sound count and genres big. The box is for sample packs only. 9. Beats: the license ladder (free, lease, exclusive, full buyout at album level) with the written contract per tier in the delivery. 10. Price against my own catalogue, serialize the names. 11. Store layer: preview panel by category, previews cut from the zip I sell, one catalog structure in code as the source of truth. 12. Launch as a chain, private first, then public. HOW TO VERIFY EACH STEP (the journal's own tests) - Measure the artifact you deliver, at the moment it is that artifact: decode the final file back and measure it, test clips included. - Every stem sold as a loop is checked bar by bar in its own window. Check each seam at a slower, the original and a faster tempo if players will stretch it. - Open the zip as a buyer would, in a different folder, with my own absolute paths broken. - Read the real MP3 bitrate with ffprobe before printing it anywhere. - Every number on the cover and page comes from the final zip, never from the plan. - Verify every upload by checksum. "Done" for a preview means played in a browser tab in the foreground, one row per category. - After retiring anything, log in as an existing buyer and download the file. WHAT TO CHECK FIRST The live state: my source's current terms and my plan's commercial license, the account's download usage before any batch, what each live listing actually delivers, the counts on each cover versus the site versus the folder, and which bundles or slugs any buyer's library resolves against. NEVER - Never sell output whose license forbids reselling it as isolated samples, and never put another tool's output (or anything derived from it) into a model's training set. - Never publish, list, change a price, run a real purchase or upload to a store without my yes in this session. Show me the listing and the numbers first. - Never delete anything a buyer's entitlement resolves against: delist it. - Never list anything that delivers nothing. - Never claim a count, tempo, key or bitrate you did not measure on the final file. - Never regenerate a cover from a previous regeneration; go back to the pristine one. - Never pre-tick a paid add-on, and never promise "everything I will ever make" in a bundle. - Never batch-download without reading the account's allowance first, and never drive someone else's paid account or a reseller's API for generation. - Never process audio to beat an AI detector, and declare AI honestly wherever a platform asks. - Never turn my note about one file into a rule rewritten for every file. Ask first if it looks like a class problem. - Never write keys, cookies or session exports into a file, a journal or this chat. Keep them in a vault or environment variables. - Never promise me sales. KEEP MY PROJECT JOURNAL - If I have Journals DNA: after each step, journal_append(name_or_path="", entry="", tag="ship" or "fix"). When I choose something (source, license tier, price, naming, which pack ships), journal_decision_add(name_or_path="", decision="...", why="..."). When the state changes, journal_update_section(name_or_path="", "Current state", new_content, mode="replace"). Log each license document you relied on with its date. - If I do not: keep a plain _JOURNAL.md in my project folder with a dated line for each step, decision, license check and bug with its root cause. HOW TO REPORT BACK Result first, in plain words: which step, which pack, what you changed (file by file), what you measured and the numbers. Name the journal section you relied on. Give me the exact files to listen to when my ears must decide. 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 six questions above. Then audit my catalogue against the twelve pipeline steps, reading my files, my source's terms and my live store pages only: for each step say done, missing or broken, with the evidence (start with the license gate). Change nothing yet. End with the one step you would do first and why. ``` ## Prompt 2: every later session (continue) ```text We are building my packs and beats with the journal "Build an AI Beat and Sample Pack Business". Continue from where we stopped. 1. Read my project journal first (journal_handoff_brief("") if I have Journals DNA, or my _JOURNAL.md). Tell me in five lines which pipeline steps are done for each pack, which one is next, and what is waiting on me (listening, a decision, a yes). 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 catalogue" and "Recurring traps" before you touch anything. 3. Check the live state before you trust my notes: the source's terms if a new tool is involved, the download allowance before a batch, what the live listing delivers. 4. Do one step on one pack, measure it the way the journal says, log it with journal_append, then stop and show me the numbers and the files to listen to. 5. Listing, publishing, price changes, real purchases and anything that spends money wait for my yes in this session. 6. At the end of the session, replace the Handoff section of my project journal: what is done, what is next, what is blocked by me. ```