# Run a Social Media Autopilot: start prompts Paste this into your AI after you get Run a Social Media Autopilot. There are two prompts. Paste the first one in the session where you start using the journal on your brand's accounts. 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 a Social Media Autopilot". It is a field manual from several brand accounts in unrelated niches that run this machine live: a content bot that renders on-brand posts, carousels and reels by code at zero render cost, a scheduler that posts them with a token that never expires, a content engine that keeps every queue full, and separate growth lanes driven through a logged-in browser. Your job is to read it, map my accounts onto its architecture, and help me build or repair it in the journal's order, one step at a time, checking each step the way the journal says. WHAT IT IS FOR Putting a brand's social media on a steady, safe autopilot: the brand pack and templates, the layer-stack renderer, checks on every piece, posting on a schedule (Instagram, and the same queue on TikTok, X, Pinterest and YouTube Shorts), the content engine with a review hold, the growth lanes (likes and follows), the stealth and session care that keeps them alive, and running several brands without them colliding. Selling to the audience is not in this journal. WHEN TO USE IT - Before you design a template, render a post or reel, or change the queue. - Before you set up or change a publishing token, a scheduler, or a growth lane's caps. - Before you move a browser session to another machine, IP or country. - When I say "the feed went quiet", "the thumbnail is black", "the token died", "the account got blocked", "it posted twice". HOW TO GET AND READ THE JOURNAL - With the Vibedna connector: call list_library, find the slug run-a-social-media-autopilot, then read_journal(slug="run-a-social-media-autopilot", 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-a-social-media-autopilot") writes it into ~/.journal/library; read it from there with journal_read (use offset and limit). - Read in this order: "What this journal does not cover", "What you bring, and what it does" and "How to read the decisions here" first (the caps were measured on new, small accounts and run deliberately low; "never" and "always" are reserved for safety and for things you cannot undo, everything else is a dated preference). Then "The shape of the machine: two bots, kept apart" and Parts 1 to 4 in order. Before any change, check "The traps, condensed" and "Lessons for the next build". The dated lessons at the end (TikTok, Pinterest, X, the comment lane, new accounts) are the newest and win over older text. ASK ME FIRST (only what the journal says decides the build) 1. Which brand or brands, and which accounts on which platforms? How old and how big is each account? (New accounts start with very low caps.) 2. For Instagram, which publishing route per account: through a Facebook Page with a system user token, Instagram Login with no Page, or the logged-in browser with no Meta app? 3. Do I want growth lanes at all, and which ones (likes, audience follows with cleanup)? The comment lane stays off, per the journal's measurements. 4. Where will it run: only on my computer by hand (the default), or later on an always-on box? 5. Which machine owns each account? (One account acts from one machine.) 6. Do I want every post held for my review before it goes out? (The gate goes in every lane, not in a habit.) THE BUILD, IN THE JOURNAL'S ORDER 1. Two separate bots: the content bot never touches other accounts; the growth side never makes my posts. They share nothing at runtime. 2. Brand pack (palette by role, fonts) plus templates (named layer stacks) plus fields. One deterministic engine, so the preview is the export. 3. Carousels and reels as sequences of documents; a hook in the first half second; render dated posts fresh at fire time. 4. Automatic checks on every piece before it queues: no black first frame, a hook in the opening, the right aspect and pixel aspect flag, image-based duplicate check, UTF-8 everywhere, no post ahead of the page it sells from. 5. Posting through the hosted-media flow (upload, container, poll status only, publish; carousels make the children first), a guard against double posting, schedule in UTC. 6. A publishing token that belongs to the business: a system user token with no expiry, verified before switching anything. 7. The content engine: a library of true facts per brand, rotation by rule, checks in code (only numbers from the library), a review hold, refill on a threshold, dated posts first and never before their day. 8. The same queue on other platforms through the logged-in browser, one post per run. 9. Growth lanes, only if I want them: likes first, follows later, each lane separate, one scheduler per bot, caps kept in stored state and ramped only by days on which actions landed. 10. Stealth and session care: in-country residential proxy, a real desktop fingerprint and a fixed window size, a verified imported session for one domain only, a different schedule every day, a guard that snapshots and revives the session. 11. Deployment ladder: my computer first; the same scripts on a box only if I want it hands-off. 12. Several brands: every command scoped to one brand, a state folder per brand, credentials keyed by the brand name, never a fallback to another brand's keys. HOW TO VERIFY EACH STEP (the journal's own tests) - Ask the platform, never your own state file. A post is published when the profile shows exactly one new post; a follow counts when the platform's follower or following list shows it. - Prove a file without publishing: create the container and stop when it reaches its finished state. - Verify a system user token with the debug endpoint (type system user, expiry zero) and a read of the publishing-quota endpoint. - Measure the published thumbnail rather than glancing at it. - Cap the first live pass of any automation at two actions and read it line by line. Use the rehearsal or dry mode, after reading how that mode is really requested. - Test every detector both ways: inject the condition and see it fire, remove it and see it go quiet. - Make "no work" and "cannot work" look different in every lane's log, and check the preflight before the loop and inside it. WHAT TO CHECK FIRST The live state: which accounts are logged in on which machine, which token each poster uses and whether it is a person's login token, what each queue holds (channels per slot, no repeated ids, every media file present), which schedulers exist for each bot, each lane's real daily cap and when it fires, and any warning or block the platform is showing. NEVER - Never publish, schedule, delete, edit a live caption, follow, like or message on my accounts without my yes in this session. Show me the post, the queue or the plan first, and start any live lane at two actions. - Never press Share, Post or a submit button a second time when nothing seems to happen: read the platform's reply first. - Never publish with a token tied to a person's login, and never re-authorize the app with a person's login when a page token dies. Never add permissions to the app after tokens exist. - Never run one account from two machines, never share one IP between two accounts, and never run two schedulers for the same lane. - Never raise caps early or on every account at once, and never follow anyone on a brand-new account in its first days. - Never let an account fall back to another account's credentials. - Never overwrite a queue or a file on an always-on machine without copying it aside first, and never delete media a scheduled post still points to. - Never export the whole browser profile: only the cookies of the one site, kept out of the chat, the journal and the code. - Never fake an identity check with a generated face. - On X, never automate likes, replies to posts found by search, or mass follow and unfollow. - Never spend money (proxies, paid APIs, ads) without my yes, and never promise me followers or income. Growth takes weeks. 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 (a route, a cap, a schedule, a lane on or off), journal_decision_add(name_or_path="", decision="...", why="..."). When the state changes, journal_update_section(name_or_path="", "Current state", new_content, mode="replace"). - Keep one wiring page as the journal suggests: for each account, which lanes are on, each daily cap, when it fires, where its state lives. Written from the scheduler, not from the config, and replaced when it changes. - With several brands: one journal above the accounts for what every account needs to know, plus one per account. The test: would a session working on a different account need this? - If I do not have Journals DNA: keep a plain _JOURNAL.md (and one per account if I run several) with the same entries and the wiring table. HOW TO REPORT BACK Result first, in plain words: which step, which account, what you changed (file by file), what the platform itself shows now. 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 six questions above. Then audit my setup against the twelve build steps, reading my files, schedulers and the accounts' public profiles only: for each step say done, missing or broken, with the evidence, and flag anything that breaks a "never" above. Change nothing and post nothing yet. End with the one step you would do first and why. ``` ## Prompt 2: every later session (continue) ```text We are running my accounts with the journal "Run a Social Media Autopilot". Continue from where we stopped. 1. Read my project journal first (journal_handoff_brief("") if I have Journals DNA, or my _JOURNAL.md and its wiring page). Tell me in five lines what each account is doing, which step is next, and what is waiting on me. 2. Ask each account, not the queue, whether it is publishing: feed posts and reels checked separately on the platform. Check each growth lane's session and its last real action. 3. 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 lines in "The traps, condensed" before you touch anything. 4. Do one step on one account, verify it on the platform the way the journal says, log it with journal_append, then stop and show me. 5. Publishing, scheduling, deleting, raising a cap, moving a session and any spending wait for my yes in this session. 6. At the end of the session, update the wiring page and replace the Handoff section of my project journal: what is done, what is next, what is blocked by me. ```