Six content automations for lead-generating content

What you're building

Most content systems fail in the same place. They generate. You end up with a folder of text nobody asked for, and the filing is still your job.

This one is shaped differently. Six inputs you already produce feed one database, and every automation ends at your thumb.

1. A creator you already follow publishes something, and it comes back as a scored idea with their link attached and your own framework already matched to it.
2. A voice note you send yourself on a walk becomes a stored thought in your own words, before you had time to polish it.
3. A coaching call becomes one or two filed lessons with the client's identity stripped out.
4. A post that did well becomes a carousel in your own visual style.
5. A script you already approved becomes a delivered video, disclosed, without you sitting down to record.
6. Work you already shipped becomes a build-in-public idea, as long as it carries a lesson a stranger cares about.

None of the six can publish anything on its own. Every one stops and shows you the work.

The thing that makes this reliable is not the AI. It is the database. An agent with a well-shaped place to put things becomes dependable. An agent with nowhere to put things hands you text you then have to file, which is most of the work you were trying to remove.

What AI is good at, and what it is not

Every one of the six exists because of a line I drew before I built anything, and it is the reason the output still sounds like me.

Use it for these four. Remixing ideas, so a concept from a newsletter collides with something you already teach and produces an angle neither had alone. Analysing what worked, yours and other people's, so you can see the mechanism rather than admire the result. Structuring your rambling thoughts into something with a shape. And repurposing your winners into formats you would never get round to by hand.

Do not use it for these two. Telling your stories. Holding your opinions.

That is why any system promising you push-button content should make you suspicious. If no human is in the loop evaluating what goes in and what comes out, what comes out is slop, and it will be slop at scale, which is worse.

Every automation below is built around that split. The machine does the fetching, the matching, the structuring and the production. The judgment, the story and the final yes stay with you.

Where the leads come from, and how to wire it

Be clear about this before you build anything. None of the six automations generates a lead on its own. Nothing that writes a caption generates a lead. What they do is remove the reason you stop posting. A second, much smaller loop is what turns the posting into an email list, and it is the shortest build on this page.

Four steps. You publish something useful. The caption asks people to comment one word. A comment-to-DM tool sends them a link. The link is a free resource page that hands the thing over and invites them onto your list.

The reason it works is that a comment is a much smaller ask than a click, so more people do it, and the ones who do have already told the algorithm the post is worth showing to somebody else.

Three pieces, and only one of them is technical:

1. Something worth trading an email for. One page. A checklist, a template, the actual thing you demoed. If you cannot name what the person gets in one sentence, it is not ready.
2. An email tool with a form and one automated email. I use Kit. The form gives you somewhere to send people and a tag so you know which post they came from.
3. A comment-to-DM tool. I use ManyChat. It watches a post for a keyword and sends the DM.

Set the keyword, then register every way a real person will actually type it. This one detail costs people most of their leads. Viewers do not type the keyword the way it appears on screen. If your word is HYPERFRAMES, register it lowercase, split as two words, hyphenated, and singular, and use partial matching rather than exact.

Help me wire up the loop that turns one published post into an email
subscriber. I am not technical. Walk me through it one step at a time and
wait for me to confirm before moving on.

My free resource lives at [URL OF MY RESOURCE PAGE]. My email tool is
[KIT / MAILCHIMP / BEEHIIV]. My comment-to-DM tool is [MANYCHAT / OTHER].

Do it in this order:

1. Before anything else, check that my resource URL actually loads and
   returns a real page, not a 404. If it does not, stop and tell me. A
   DM that sends someone to a broken link is worse than no DM at all.

2. Help me pick the comment keyword. One short word tied to the post's
   topic, easy to spell, and not something people would type by accident
   in a normal comment.

3. Then the step everyone skips. Give me the FULL list of trigger
   variants to register, because viewers never type the keyword the way
   it appears on screen. Include: the word exactly as shown, all
   lowercase, split at the natural word boundary, hyphenated, and
   singular. Tell me to use "contains" or partial matching rather than
   exact matching, and explain what that changes.

4. Write the DM copy. Two short messages, not one long one. The first
   acknowledges what they asked for in my own voice. The second delivers
   the link. No hype, no emoji walls.

5. Write the caption line that asks for the comment. Put it near the top
   of the caption AND repeat it at the bottom, because most people never
   read to the end.

6. Tell me exactly where in my email tool to create the form and the tag,
   so I can see which post each subscriber came from, and what the first
   automated email should say.

7. Give me a test plan: comment the keyword from a second account, and
   tell me what I should see happen, in order, and roughly how long each
   step should take.

Timing rule I want you to enforce: build the automation while the post is
still scheduled, then attach the trigger to the live post about five
minutes AFTER it publishes. I cannot select a post that does not exist
yet.

Do not post anything, schedule anything, or send any message on my
behalf. Tell me what to click and let me do it.

Two hard rules I learned the expensive way. The resource has to be live and returning a real page before you schedule the post, because a DM that sends someone to a broken link is worse than no DM. And build the automation while the post is still scheduled, then attach it to the live post about five minutes after it publishes, because you cannot select a post that does not exist yet.

The full click-by-click version, including the upgrade that asks for the email before it hands over the resource, is here: Automate ManyChat with Claude.

How hard this actually is

I would rather say this now than have you find out in step four. These are my own estimates from having built them, not promises.

Two of the six are small. The voice note and the shipped-work capture are genuinely an afternoon each once the foundation exists. Two more are a weekend. The call miner and the carousel project both need a real database underneath them before they mean anything.

The avatar one is the odd one out. Building it takes an evening. Deciding whether you should is the real work, and for most people the answer is no.

And the scout, the piece that quietly runs all of this overnight, is the one that took me longest, because an agent that runs while you sleep has to be trusted, and trust is mostly plumbing. Mine took the better part of a week and I found about a dozen real bugs on the way. Several of them reported success while doing nothing at all.

If a week is not what you want to spend, skip to the afternoon version near the end. It gets you a real chunk of the value with no server involved.

What you'll need

• A Google account for the spreadsheet and the folders. Free.
• Telegram, free, which is how you talk to the system from your phone.
• Claude Code or Codex on your own machine to do the building. I use both. This is the real cost, and it is the one you would be paying for anyway.
• ffmpeg and whisper.cpp, both free and open source, for turning voice notes into text on your own machine.
• An avatar tool and a voice tool, only if you build number five. I use HeyGen for the face and ElevenLabs for the voice. Both are paid, and both changed their pricing while I was building, so price them at signup.
• A small Linux server, only when you want things running while your laptop is closed. Mine is roughly ten dollars a month, and plans move, so check before you buy.

The open-source pieces are free. Your coding agent and any model usage are the real line items, and they depend on which account and runtime you use. Do not buy a server, a transcription service or a publishing plan until one real idea has gone all the way through by hand.

Build the base first

All six write into the same three places. Build these once and every later step gets shorter.

The spreadsheet

Three tabs, not fourteen. Mine has fourteen as of August 2026, and that is the result of two years, not a starting point.

Build me a content database in Google Sheets. Keep it to three tabs.
I am not technical, so tell me what to click, and stop after each tab so
I can look at it before you carry on.

Make this a brand new spreadsheet of my own. Do not connect it to anyone
else's system.

TAB 1, named CAPTURE_INBOX. The parking spot for raw thoughts before
anyone decides they are worth making. Headers in row 1:
  Capture ID, Date Saved, Platform, Creator, URL, Caption,
  What It Teaches, Status, Candidate ID, Notes

TAB 2, named IDEA_CANDIDATES. Scored ideas waiting for my approval.
Headers in row 1:
  Candidate ID, Date, Source, Source URL, Topic, Angle, Format,
  Audience Breadth, Novelty, Shareability, Visual Material, Recency,
  POV Strength, Pillar Fit, Total Score, Why Now, Status, CID,
  Score Rationale, Notes

TAB 3, named CONTENT. One row per real piece of content.
Headers in row 1:
  CID, Title, Card State, Packet, Script, Record, Edit, Published,
  Source Refs, Idea Packet, Script Doc, Drive Folder, Publish Date,
  Notes, Created, Last Updated

Rules I want enforced. Explain each one back to me in plain English
before you build it:

- Source and Source URL sit at positions 3 and 4 on IDEA_CANDIDATES.
  They get filled the moment an idea is found, never later.
- CONTENT has a Source Refs column, and it is never left blank on a row
  that came from somebody else's work.
- A CID is my own single series across all content types, C0001 upward.
  It is never reused, and it appears in exactly one row.
- Nothing in CAPTURE_INBOX or IDEA_CANDIDATES ever gets a CID. Those two
  tabs are pre-approval by design.
- Card State is one of: active, parked, scrapped, published.
- Every stage column is one of: not_started, in_progress, needs_review,
  done, skipped.
- New rows go in at the top, not the bottom.

Add dropdowns for Card State and the stage columns. Then show me how to
read one row at a glance.

One difference you will notice if you watch me use mine. I split that third tab by content type, so I have a shorts tab, a YouTube tab, a carousels tab and so on, all sharing one ID series. That is worth doing once a single tab gets unwieldy. It is not worth doing on day one, so the prompt above gives you one content tab and the same rules.

Four of those rules are worth defending, because I got every one of them wrong first.

Two tabs never get an ID. Captures and candidates are pre-approval on purpose. The moment a raw thought gets a permanent number it starts to feel like a commitment, and you finish things you should have killed.

Source and Source URL go in at position three and four. Not because of where they sit, but because filling them is the first thing that happens when an idea is found. Credit added afterwards is credit you will forget.

Resolve columns by header name, never by letter. Write this rule down now. The day you insert a column, every hardcoded letter silently points at the wrong data. I inserted nine columns into a tab once and every document link shifted four columns right.

Newest at the top. Trivial until you realise row numbers now change constantly, which is exactly why anything writing to a row has to find that row by its ID immediately before writing, and never by remembering where it was. A background job clobbered a completely different piece of my content this way.

The Google permission

This is the step people bounce off, and it is not hard, it is unfamiliar. Have the AI walk you through it rather than reading Google's documentation.

I am a complete beginner and I have never used Google Cloud. Walk me
through giving a script permission to write to my Google Sheet, one step
at a time, and wait for me to confirm after each step.

For every step tell me three things: which website to open, exactly what
to click, and what I should see on screen when it worked.

Cover, in this order:
1. Creating a Google Cloud project.
2. Enabling the Google Sheets API and the Google Drive API.
3. Creating a service account.
4. Downloading its JSON key file, and where on my computer to put it so
   I do not accidentally upload it anywhere.
5. Finding the client_email inside that file, and sharing my spreadsheet
   with that address as an Editor, with notifications turned off.
6. If I will also have it read or write Google Docs later, sharing the
   Drive FOLDER those documents live in with the same address. Sharing
   the spreadsheet does not share my documents.

Then write a tiny read-only test script for me, install whatever it
needs, run it, and print my sheet's tab names back to me.

If it fails, print the ACTUAL error text, then walk this checklist in
order rather than guessing: is the spreadsheet shared with the service
account email, are there stray quote marks around the values in my
settings file, is the right API enabled, and are the requested
permissions the full ones rather than a read-only variant.

Never ask me to paste a key file or a password into this chat.

When you hit a 403 that reads like your key is broken, the key is usually fine. Walk this list in order before touching anything: is the spreadsheet actually shared with the service account address, are there stray quote marks around the values in your settings file, is the API enabled, and did you ask for a read-only permission when the full one was what you were granted. I have lost a session to each of those.

The bot

Now the phone half. Open Telegram, search for BotFather, and send /newbot. It asks for a display name, then a username that has to end in the word bot. It replies with a long token. Treat that token like a password. Then search for userinfobot and press start, and it gives you your own numeric ID, which is what stops anyone else writing into your spreadsheet.

Build me a minimal Telegram bot in this folder. Keep the whole thing
under 200 lines. No frameworks beyond what we install, no config system,
no plugin architecture. If it grows past 200 lines, cut abstractions
rather than adding files.

What it does, and nothing else:
1. I message it, and it appends one row to the CAPTURE_INBOX tab of my
   Google Sheet.
2. I send /queue and it shows me the last 10 rows with Status = new.

Rules:
- Python, using python-telegram-bot and the Google API client. Write a
  requirements.txt with pinned versions.
- Read settings from a .env file: TELEGRAM_BOT_TOKEN, GOOGLE_SHEET_ID,
  GOOGLE_SERVICE_ACCOUNT_FILE, ALLOWED_TELEGRAM_USER_ID. Also write a
  .env.example with blank values, and a .gitignore that excludes .env
  and the key file.
- STRIP surrounding single or double quotes from every value you read
  out of .env. A naive split on the equals sign keeps the quotes, and
  the result is a 403 that looks exactly like a broken key.
- Ignore, and log, every message from any user id that is not
  ALLOWED_TELEGRAM_USER_ID. Compare them as integers.
- Use the FULL Google Sheets permission, not a read-only variant.

THE WRITE PATH, which is where this usually goes wrong:
- Read row 1 first and resolve every column by HEADER NAME, never by
  column letter.
- Build a row list exactly as long as the header row, pre-filled with
  empty strings, then place each value at its header's index. Error out
  naming any header you cannot find, rather than writing to the wrong
  slot.
- Generate the Capture ID by reading the existing ID column, taking the
  highest s#### number, and adding one.
- After writing, READ THE ROW BACK and compare it against what you meant
  to write. Print any mismatch. Appending silently trims trailing empty
  cells, which shifts every later column one to the left.
- Never create a content ID. Everything this bot writes is pre-approval.

When it is written, tell me the exact command to run it, and exactly
what to type in Telegram to prove it worked.

Do not ask me for my bot token or the contents of my key file in this
chat. Tell me which file to paste them into instead.

Test it before building anything else. Message the bot, then go and look at the spreadsheet with your own eyes. Check that Status landed in the Status column and not one to its left. A single column shift is the most common failure here and it is completely silent.

Automation 1: a creator's idea becomes your take

Everyone builds a version of this and nobody keeps it. You paste an article into a chat window and ask for ten video ideas. It works once. Two months later you cannot remember where any of it came from, and neither can the machine.

Two things make the difference.

The first is that your agent knows your back catalogue. Mine is trained on every piece of content I have ever made, so when it reads something new it is not summarising, it is matching. I follow Wes Kao's newsletter, and so does my bot. When it read one of her issues it came back and told me it had matched her idea against three things already in my system: my question-context-example framework, my answer-decision-or-warning diagnostic, and a real conversation I had with a partner at a consulting firm. That is a collision between her thinking and mine, and it is worth more than ten generated ideas.

The second is one column. When an idea is found, the source and its link are written into the row at that moment, before scoring, before any writing. When I later approve the idea, that link is copied onto the real content row in the same write that creates it. The credit exists before a single word of script does.

Then I did the part the automation cannot do. I borrowed her exact phrase, minimum viable backstory, said her name out loud on camera, explained the idea in my own words, and used it to tee up a framework I teach. That video did around 3,500 likes and over 800 comments. The source is visible from the spreadsheet row. What I added to it is visible in the linked idea packet. Anyone can check both.

That is what makes it your take rather than a rewrite, and it is the only version of AI-assisted content you can comfortably defend when somebody asks.

Build it

The scout's judgment lives in a plain markdown file with no code in it at all. Separate code does the data access, the writing and the scheduling, and the prompt below asks for both so you do not end up with instructions nothing runs.

Create a skill file at .claude/skills/my-scout/SKILL.md, plus a small
runner script that actually executes it on a schedule. I want both, and
I want you to tell me plainly which parts are instructions and which
parts are code.

The skill is a nightly idea scout for [MY AUDIENCE, e.g. "small business
owners using AI"]. It runs unattended, so it can never stop and ask a
question.

THE SKILL FILE

Frontmatter: a name, and a description saying what it mines, that it
scores on a 7-axis rubric, that it writes to the IDEA_CANDIDATES tab,
and that it NEVER creates a content ID.

Body, in this order:

1. The rule that matters most: this only writes candidate rows. It never
   mints a content ID and never touches the CONTENT tab. That separation
   is what makes it safe to run while I am asleep.

2. My sheet ID is [MY SHEET ID], tab IDEA_CANDIDATES. Read row 1 for the
   current header names before every write. Never write any other tab.

3. HEADLESS RULE. In an unattended run, never ask a question. If you are
   genuinely blocked, print one line starting with "scout BLOCKED:" that
   names the blocker, then exit with an error code so I find out.

4. Sources, in strict priority order, my own material FIRST:
   a. anything I hand-saved into CAPTURE_INBOX
   b. my own work notes and build journals since the last run
   c. my own published free resources
   d. my own best-performing past posts
   e. my newsletters
   f. LAST, a watchlist of creators I follow, and only after the owned
      sources have run clean for a week

5. The 7-axis rubric. Score each candidate 0 to 10 per axis. Total is
   the sum, out of 70.
   - Audience breadth: how many people in my audience could care
   - Novelty: is the mechanism genuinely unfamiliar
   - Shareability: would someone send this to a colleague
   - Visual material: what actually exists to show
   - Recency: evergreen scores 6, hand-saved items score 8
   - POV strength: is this my own take with a real story, number or
     moment. A secondhand take caps at 6.
   - Pillar fit: does it match what I teach

6. PROVENANCE RULE, non-negotiable. Every candidate records Source and
   Source URL the moment it is found, before scoring and before writing.
   For a source with no public link, such as my own notes, write the
   file path or document name instead. Never invent a URL, ever.

7. COLD-READER RULE. Write the topic and angle as a pitch to a stranger,
   in plain language. Never use my internal shorthand or tool names. The
   universal lesson leads. My own build is the proof inside the video,
   never the pitch.

8. A Score Rationale field on every row: two or three plain sentences
   naming which axes moved the score and why, so I can argue with it.

9. Dedup: never propose the same idea in the same format twice in one
   week. Check the newest content rows and every open candidate first.
   Expire candidates older than 14 days.

10. ANTI-BLOAT RULE. My feedback about scoring or taste never gets
    written into this file. It goes in a separate taste folder that the
    skill loads on every run, so I can change my taste without editing
    the skill.

THE RUNNER

A single command I can schedule, which loads the skill, reads the source
locations I give you, writes rows through the same verified sheet writer
we already built, and keeps a small state file recording the last run so
it does not reprocess everything.

Have it run once by hand first and show me the rows. Do not schedule
anything until I have read two nights of output.

Run it by hand first, twice, and read every row. Check three things. Is the source link real and clickable. Is the score rationale two or three sentences you could argue with. Does the total equal the sum of the axes. If the rationale is empty the scoring is a black box, and you will quietly stop trusting it within a month.

What comes out the other side, once you approve an idea, is an idea packet: the core idea, the one thing you want the viewer to take away, the shift you are asking for, who it is aimed at, how you want them to feel, and the source material. Read that before any script exists. It is much cheaper to kill a bad idea at the packet stage than after you have a draft you are attached to.

Then it writes a first pass of the script. Mine gets me perhaps 85 or 90 percent of the way, and the last 10 percent is not optional. Read it out loud. Fix what does not sound like you. That is the whole job.

The audit that catches the failure I actually had

My idea document had Wes Kao's link in it. The spreadsheet cell was blank. Everything looked correct right up until somebody clicked the cell.

The document is not the record. The cell is the record, because nothing that reads your database can see inside a document.

Write me a checker that finds broken attribution in my content database.

My own domains are [LIST YOUR DOMAINS]. Anything else is an outside
source.

For every row in my CONTENT tab that has a linked Idea Packet document,
read the document text and pull out every link that is not one of my
domains.

Report a row as BROKEN when the document contains an outside link but the
row's Source Refs cell is empty. Print the content ID, the title, and
every orphaned link you found.

Also report the reverse: a Source Refs cell holding something that is
neither a link nor a content ID.

End with one plain line: how many rows scanned, how many broken.

This catches a specific failure that is easy to miss. The document had
the source link in it. The spreadsheet cell was blank. Everything looked
fine right up until somebody clicked the cell. The document is not the
record. The cell is the record, because nothing else that reads the
database can see inside a document.

Report only by default. Add a --fix flag that takes the content ID and
the exact URL, so I choose which link is authoritative rather than the
script guessing when a document holds several. On a fix, re-find the row
by its content ID immediately before writing, then read the cell back and
print what actually landed.

Before you run it, check that my service account can open the packet
documents. Access to the spreadsheet does not include them.

Automation 2: a voice note becomes an idea

Build this one first.

The best thing you will say all week is the sentence you say before you have time to polish it, usually while walking somewhere. Ten minutes later it is gone. What you eventually sit down and type is a worse version with the interesting part sanded off, and the emotional charge you felt in the moment is nowhere in it.

So the capture step is deliberately stupid. Hold the microphone button in Telegram, talk for a minute, let go. Shortly after, your words are in a spreadsheet row. No title, no summary, no ID. Nothing has become content.

Mine came back with "captured s0024 from your voice note" and had kept the two things that mattered from a rambling minute: a story about a former manager, and the rule I was circling, which was to ask one question, give one reason if it is needed, then stop talking. Then I replied "score it now" and it went off to rank it against everything else waiting.

Two details make it work. The transcription runs on your own machine with whisper.cpp, so the audio goes to Telegram and then no further, rather than through a separate transcription company. And the transcript is stored raw. Not tidied, not summarised, not improved. If the machine rewrites your sentence at capture time you have lost the exact thing you were trying to keep. It is a machine transcript, so it will make mistakes, and that is a fair trade for keeping your phrasing.

Build it

Two installs first. In Terminal, run brew install ffmpeg whisper-cpp. Note that the program is called whisper-cli, not whisper-cpp, which trips everybody up. Then download an English model file. Ask your coding agent for the current download command and the sizes on offer rather than typing a URL by hand, because the model list changes. A smaller model is faster and slightly worse, and for capturing your own voice notes that trade is usually fine.

Upgrade my existing Telegram bot so it also accepts voice notes. Keep
every handler that already works, including the text capture and /queue.
Add to it, do not replace it.

End to end:
1. Listen for VOICE messages as well as text.
2. Reject any message whose user id is not ALLOWED_TELEGRAM_USER_ID.
3. Download the voice file. Telegram sends OGG/Opus.
4. Convert it:
   ffmpeg -y -i <in.oga> -ar 16000 -ac 1 -c:a pcm_s16le <out.wav>
5. Transcribe it on my own machine with whisper.cpp:
   whisper-cli -m <MODEL PATH> -f <out.wav> --output-txt --no-timestamps -of <basename>
   Then read the .txt it wrote and collapse the line breaks into single
   spaces. Do NOT rewrite, summarise, tidy or improve my words. Store
   the raw machine transcript. The whole point is that my original
   phrasing survives, and a cleaned-up version has lost the thing I was
   trying to keep.
6. Append one row to CAPTURE_INBOX using the SAME verified writer the
   text path already uses, so the column mapping and the read-back check
   are identical: a new Capture ID, today's date, Platform "Telegram",
   Caption set to the transcript, Status "new", Candidate ID EMPTY.
7. Reply with one short line: "Captured <id> from your voice note."

Hard rules:
- NEVER interpolate the transcript into a shell string. Call ffmpeg and
  whisper-cli with subprocess.run and an argument LIST, never
  shell=True. My words will contain apostrophes and dollar signs and the
  shell will mangle them.
- Pass check=True and a timeout to both commands so a failure is loud.
- Delete the temp .oga, .wav and .txt files when done, including on
  failure. Use try/finally.
- On any failure, reply with one plain line naming what broke, and do
  not write a partial row.
- Never create a content ID.

Before you wire up Telegram, run steps 4 and 5 by hand on one audio file
I give you and show me the transcript. If that fails, the bot would fail
too and I would not know which half broke.

Prove the transcription works on its own before you connect it to Telegram. Record any twenty-second memo, hand the file to your coding agent, and have it run the two commands directly and print the text. If you skip this and it breaks later, you will not know which half failed.

Automation 3: a call becomes filed ideas

Your calls contain the exact words your audience uses when they are stuck. That is worth more than any keyword tool, and most people throw it away every week.

The loop: the call records and transcribes itself, the transcript lands in a Drive folder, and the agent reads any new one and pulls out one or two real teaching moments. Not a summary. A place where a genuine problem came up and you taught something in response.

One of mine came back as an idea called "if you ramble, do not ramble in sentence one", assembled from several different calls where the same thing kept happening. The packet described the problem the way the person actually experienced it: a question comes in live, they start talking before the answer is clear, and they only find the point after rambling. I read that and thought, yes, that is the thing. So it became a script in my own voice.

The hook it wrote was not good enough. I said so, and I rewrote it. That is the normal state of affairs, and the feedback is not wasted: the more specific you are about why something missed, the closer the next one lands.

Two things make this more than a summariser.

It deduplicates. A framework you teach in four different calls becomes one row carrying four source links, not four near-identical rows. Repeated teachings accumulate evidence rather than clutter, and the rows with the most links are the ones your audience keeps needing.

It is instructed to anonymise before anything is written, and I read every output myself because an instruction is not a guarantee. Every name comes out and the person becomes "a client". If you are mining real client calls, do not skip that read, at least until you have seen twenty come out clean.

Build it

Turn on recording and transcription in your meeting tool. Google Meet on a Workspace plan does both with a toggle at the start of the call, and each lands in your Drive when the call ends. Zoom and Fathom work too, the transcript just arrives somewhere different.

Then start by hand. Do not build the always-on watcher yet. Paste one real transcript at a mining skill and read what comes out.

Build me a skill called call-mining. Trigger it when I say "mine this
call" or "pull ideas from this transcript".

What it does, in order:

1. Take a transcript from a document link, a folder, or pasted text.

2. Read the WHOLE thing and find distinct teaching moments. A teaching
   moment is a place where a real problem came up and I taught something
   in response. An actual before and after. Not a nice-sounding line, and
   not a summary of the call. Expect one or two per call, not ten.

3. For each one, write a document containing:
   - The problem, stated the way the client experienced it, anonymised.
   - The teaching, in my own vocabulary.
   - Verbatim quotes of the key lines I said.
   - Which of my topics it belongs to.
   - A source line linking back to the full transcript.

4. Before writing anything, check my database for that transcript's
   link. If the same teaching already exists as a row, do NOT create a
   second one. Append this transcript's link to the existing row's
   Source Refs instead, so a teaching I repeat accumulates evidence
   rather than clutter. The rows with the most links are the ones my
   audience keeps needing, and that is a signal I want to be able to see.

5. Write one row per new document into my CONTENT tab: the next ID, the
   title, the source link, and not_started for every stage column.

THE PRIVACY RULE, and treat this as the most important line in the file:
never write a client's name, employer, job title, or any detail that
would identify them. Refer to them as "a client". Before you output
anything, list every proper noun you found in the transcript, then check
your own output against that list and tell me what you removed.

Be honest with me about what that check is. It is an instruction you are
following, not a guarantee, so I am going to read every output myself
before it goes anywhere.

Run it on ONE transcript I give you, show me the result, and wait. Do not
write anything to my database until I have read the first one.

Three things I found out the hard way. The transcript finishes before the recording does, so anything downstream has to cope with the recording being missing. Check that captions were actually on: I have one fifty-minute call whose transcript document exists, records that the meeting ended, and contains zero words. And where a session got exported twice you can end up with two documents where one is nearly empty, so prefer the one with more words rather than the newest.

Once that works by hand, the always-on version is the upgrade: a folder watcher on a server, and a message to your phone when new packets are filed. I wrote that whole build up separately, including the server, the agent's identity file and a dozen things that went wrong: Turn Coaching Calls Into Content. That guide numbers this build differently because it belongs to an older video. Same system.

Automation 4: a winner becomes a carousel

You already know which of your posts did well. What you do not do is act on it, because repurposing is boring and the payoff is invisible.

I run this half in Codex as a project folder rather than a chat, because a carousel is mostly assets. Mine holds my brand colours, cutout headshots (one set for each of my two brands, so it swaps the right face depending on which one I am posting to), and a references folder full of screenshots of carousels by people whose design I admire. A16Z is in there. So is my friend Soph, whose covers are unusually clean and whose body slides are plain how-to steps with no decoration at all.

Giving it references matters more than describing what you want. "Make it clean and modern" produces nothing. Ten screenshots of carousels you would be happy to have made produces something close on the first try.

Then the order of operations, which is the part people get backwards.

Copy first, design second. Get the hook and the slide copy right while it is still cheap to change. Expect to go several rounds. On mine I said I liked the first option but wanted a subheader that teased without giving away what actually works, and it came back with three. Only once the words were locked did I ask for it to lay them out and put me in the cover.

Set up a carousel project so I can turn a post that already did well
into an image carousel, in my own visual style.

STEP 1, the asset folder. Create a project folder with these inside:
  brand/       my logo, my colour hex codes, my fonts
  headshots/   cutout photos of me, one subfolder per brand if I run more
               than one
  references/  screenshots of carousels by other people whose design I
               admire
  output/      finished slides

Ask me to drop my own files in, then look at what I actually put there
and tell me what is missing before you design anything.

STEP 2, learn the references. Read every image in references/ and write
me a short style note for each: what the cover does, how the body slides
are laid out, how much text per slide, where the eye goes first. Then ask
me which of those I want to borrow and which I do not. Do not copy any
one creator's whole look. I want their structure, not their identity.

STEP 3, copy before design. Take the post I give you and write the slide
copy first: a cover hook plus 5 to 7 body slides, so 6 to 8 slides total.
Give me three cover options. Then stop and let me react. Expect several
rounds of this. I will say things like "I like option one but I want a
subheader that teases without giving away what actually works", and I
want you to take that note and re-run rather than defending the draft.

STEP 4, design after the copy is locked. Build the slides as an HTML page
using my brand folder, then screenshot each slide at 1080 by 1350. Do not
start this until I have said the copy is right, because redesigning
around changing words wastes both our time.

STEP 5, show me the whole set at once as a contact sheet, so I can see
the arc rather than judging slides one at a time.

Do not post or schedule anything. Output files, and I will take it from
there.

Then make it come to you

The upgrade is that you stop having to remember. Once your agent can see which of your posts performed, it can message you first: this one did well, want a carousel. Mine sends me the idea and the numbers behind it, and I reply yes or ignore it.

One honest note on my own version. It scores my posts and surfaces the top one, but it has no minimum, so on a slow week it will propose the best of a bad bunch with total confidence. Put a floor in yours. The prompt below asks you for one.

Now make my agent bring me carousel ideas without being asked, so I stop
having to remember which of my posts deserve a second life.

STEP 1, get the numbers in. Ask me where my post metrics live and how to
read them, whether that is an analytics tool with an API, a scheduling
tool I already pay for, or a CSV I export by hand. Start with whatever
requires no new subscription. If I have to export a CSV once a week to
begin with, that is fine, say so instead of building an integration I
do not need yet.

STEP 2, rank. Score my published posts from the last 90 days:
  saves x 5 + shares x 4 + comments x 2 + likes x 1 + min(views / 1000, 25)
Saves and shares outrank views on purpose. A post people kept is worth
more than a post people scrolled past. If a platform does not report
saves, tell me which of my platforms are missing data rather than
silently scoring them as zero.

Skip anything already turned into a carousel.

STEP 3, the floor. Show me the scores for my last 90 days, then ask me
what minimum score is worth interrupting me for. Without a floor this
returns a top scorer every single day whether or not the numbers deserve
it, and I will start ignoring the message, which defeats the point.

STEP 4, propose, and stop. Message me the winner with its real numbers
and one question: do I want a carousel. Build nothing yet. A proposal has
to be free for me to ignore.

Only when I reply "draft" do you run the carousel project we already
built. Do not create a content ID, upload anything, or schedule anything
until I have seen the finished slides and told you the exact publish
time.

Keep the gate. A proposal costs nothing and can be ignored. Nothing gets an ID, an upload or a schedule until you have looked at the finished slides. The system can do the production work without pretending every generated draft deserves to be published.

If you want the slide design craft rather than the automation, that is a separate guide: The Carousel Engine.

Automation 5: a script becomes an AI clone

This is the one to be careful with, so I am going to be blunt about what it is.

Once a script is written and I have actually read and edited it, the talking-head part can be produced without me sitting down to record. A voice model reads the script and a digital twin of my face is animated to match. What comes out is raw footage. Captions, b-roll and graphics happen exactly as they would for a real recording.

I was uncomfortable with this, and if you are too, that is the correct starting position. What changed my mind was watching creators I respect do it openly. Sabrina Ramonov wears a purple beanie whenever the video is her clone, and she has said so on camera before. You can look at one of her videos and know. The engagement is fine. People talk about it rather than feeling tricked, and the difference between those two reactions is entirely the disclosure.

So pick your own tell before you build anything. Mine would be a hat, because I almost never wear one. Something a viewer can notice without reading the caption.

Two more rules I hold to.

Real audio beats the clone, always. The moment I have a real recording, that audio drives the video even if the twin is still the face. The synthetic voice is the fallback for when no recording exists, not the default.

It only delivers what I already approved. It scales delivery. The idea, the judgment and the accountability all stay with me. This lane is for my building-with-AI content, not for teaching people how to communicate, where showing up as myself is most of the point.

Build it, if you are going to

I used HeyGen for the face, on their creator plan. New avatar, then the option to clone a real person, then upload a two-minute video of yourself talking to camera. For the voice I used ElevenLabs and gave it around two hours of clean raw audio. Then from Claude Code I handed it a script and it produced the clip.

Mine looks unnervingly like me and sounds close but not quite right, which is roughly where this technology is. Listen to the voice before you render anything, because audio is cheap to redo and video is not.

I want to make one AI avatar video of myself, disclosed, from a script I
have already written and edited.

Before any of it, answer these three questions with me and write my
answers into a file called avatar-rules.md, because these are the part
that matters:

1. What is my visible disclosure? It has to be something a viewer can
   notice without reading the caption. Pick one physical thing I would
   almost never wear otherwise, plus a caption line. Suggest options and
   let me choose.
2. Which of my content is this allowed for, and which is off limits?
3. What is the rule when I have a real recording? Write down that real
   audio always replaces the cloned voice, and the avatar gets rebuilt
   against it.

Then the build:

STEP 1, the face. Walk me through creating the avatar in my avatar tool,
click by click: which menu, which option for cloning a real person, and
what footage to upload. Tell me the length and framing of the source
video, and what makes a bad source clip.

STEP 2, the voice. Walk me through making a voice clone. Tell me roughly
how much clean audio to supply and what to avoid: background noise,
music, other voices, heavy processing.

STEP 3, the audio first. Take my approved script, generate the voice
track, and let me LISTEN to it before anything renders a face. If the
audio is wrong the video is wrong, and rendering is the expensive step.

STEP 4, the render. Drive the avatar tool and produce the clip. Before
you start, tell me what this render will cost me on my current plan, and
check the tool's current pricing page rather than quoting a number you
remember. Pricing here changes.

STEP 5, hand it back as raw footage. Captions, b-roll and graphics happen
afterwards exactly as they would for a real recording.

Do not publish it. Do not post it anywhere. Give me the file.

On cost, check the pricing page yourself rather than trusting any number in a guide, including mine. Both tools changed their pricing while I was building this, and avatar renders are charged in plan credits that do not map neatly to dollars. What I will say is that driving the tool through its normal web dashboard cost me a small fraction of what the same render cost through its API, so start there.

My honest advice: most people should skip this one. If you are not producing enough that recording is genuinely the bottleneck, an avatar solves a problem you do not have, and it costs you something with your audience that is hard to earn back.

Automation 6: your shipped work becomes content

If you build things, you are already producing receipts. Launches, fixes, the thing that broke on a Friday. Most of it evaporates because writing it up is a separate job you never do.

Two small pieces fix that. The first is a build journal: while you work, the AI keeps a running log of the steps, the decisions and the errors, so there is no separate write-up to remember. The second is a script that reads your own commit history and files each new one as a capture.

Then your scout has evidence to work with, and this is where the real value shows up.

One of my ideas sitting in the database right now came out of a build journal entry about a recap automation I made for my coaching program. The idea is not "look at my automation". The idea is that I have not written a follow-up email to a student in three months, because something else drafts every one of them before I open my laptop. That is a lesson a business owner cares about. The build is just the proof that I am not making it up.

It runs the other way too. I read a post on X about a method for pressure-testing an idea from several expert perspectives, thought it sounded useful, built it for myself, used it, and the build itself became a thing worth talking about. Someone else's idea, my implementation, my results, all traceable.

Build me the loop that turns work I have already shipped into content
ideas. Two halves.

HALF ONE, the journal. Set up a build journal so that whenever I build
something with you, you keep a running log as we go: the steps, the
decisions, the errors, and the moments where something surprised me.
Write it to a dated folder. When I say a project is done, produce two
files: a clean setup guide with the false starts stripped out, and a
list of the moments in that build that would make good content.

The second file is the one that matters. It is the difference between a
log nobody reads and a content source.

HALF TWO, the capture. Write a small script that:
1. Reads my own git history in [PATH TO MY REPO] with plain git log.
2. Works out the repository's web address from the remote so it can
   build a real link to each commit. If it cannot, record the commit
   hash instead of inventing a URL.
3. Finds commits I have not seen before, using a state file that stores
   the last hash it processed. Process the OLDEST unseen commit first so
   a backlog drains in order rather than being skipped.
4. Takes AT MOST ONE unseen commit per run. This is a deliberate flood
   guard. Twenty commits in a day must not become twenty content ideas,
   because then I stop opening the queue at all.
5. Writes it as one row in CAPTURE_INBOX through the same verified sheet
   writer we already built, with Platform "Git" and Status "new".

Then write a short rules file that my scoring step loads, saying:

- The viewer-facing idea has to be a lesson that somebody who will never
  see my code still cares about. Money, time, risk, or a work result.
- My build is the PROOF inside the video. It is never the pitch.
- If the only interesting thing about a commit is the technology, park
  it. Not everything I ship is content.
- Never invent a performance claim. If I do not have a real number, the
  idea does not get to imply one.

Show me the row it wrote and the lesson it proposes, and tell me
honestly whether a stranger would care.

Two rules in that prompt do the real work.

One commit per run. A productive Tuesday would otherwise put twenty ideas in your queue, and a queue you cannot face is a queue you stop opening.

The lesson leads, the build is the proof. This is the one people get backwards, and it is why most build-in-public content only ever reaches other builders. A cold viewer should understand the money, the time or the risk before they see a single line of your stack.

Start with your commits, because they are already on your machine and need no permissions. Your project tracker, your deploy logs and your team chat are all the same shape once that works, and each one is another source of receipts.

The five-part check

Detection tools will keep improving. Rather than trying to stay ahead of them, make them irrelevant. Before anything goes out, I answer five questions.

1. Source. Where did the idea, the experience, or the evidence come from?
2. Transformation. What did I add, test, challenge or clarify?
3. Trace. Can I still open the original source and the decisions that shaped the draft?
4. Disclosure. Would a reasonable viewer feel misled about how this was made?
5. Ownership. Am I willing to defend every line with my name attached?

Every one of the six automations exists to make one of those five answerable months later, when you no longer remember. The useful question was never whether AI touched the words. It is whether a real person supplied the substance and owns the result.

What went wrong for me

• Appending a row silently shifted my columns. Google's append trims trailing empty cells, so a fixed-width row loses its last blanks and every value after the gap lands one column to the left. Write to an explicit range instead, then read the row back and compare.
• A background job clobbered the wrong row. I wrote to a row by its number. Another job had inserted a new row at the top in between. Find the row by its ID immediately before every write.
• A 403 that was not a permissions problem. Twice. Once because a settings value kept its quotation marks, once because I asked Google for a narrower permission than the one I had been granted. Print the actual error rather than guessing.
• Two copies of the bot meant silence, not an error. Telegram returns a conflict and the bot simply stops answering. If it goes quiet, check whether you started it twice.
• A subscription is not an API key. A normal script needs metered API credentials unless you deliberately choose a runtime that supports signing in with a subscription. Finding that out late is expensive.
• Scheduled jobs spend money quietly. Pin which model a scheduled job uses before you schedule it, or a config change months later starts billing you overnight.
• Version pinning is not optional. I ran the newest version of my agent framework and it hung forever on startup with no useful error. Pin a version you have watched work.
• A job reported success while doing nothing. More than once. Verify by reading the thing it claims to have created, never by reading its own status message.
• A pre-filled template left 700 invisible empty rows. The first real entry landed at row 774. Clear the values, not just the rows you can see.

The afternoon version

If a server is more than you want to take on, this is the honest smaller version, and it takes one afternoon.

Build the spreadsheet. Build the Google connection. Build the voice-note bot and run it on your own laptop. Then skip every scheduled job and run the scout by hand inside your coding agent whenever you sit down to plan content, pointed at whatever you have collected since last time.

What you lose: nothing runs while you sleep, your phone never buzzes, and you have to remember. What you keep: the captures, the source trail, the scoring and the database underneath all of it.

My honest advice is to run it this way for a month first. If you find yourself sending voice notes without being nagged, the always-on version will pay for itself. If you do not, the server was never the problem.

What's next

Once the library exists, the question stops being what should I make, and becomes which of these thirty things is most worth making. That is when a morning digest starts to earn its place: a handful of scored ideas, with a cooldown so the same one does not resurface every day.

After that, the natural next builds are all the same shape as what you already have. Read the database, apply judgment, write back, notify.

If you want the wider system these six sit inside, including the folder structure, the real costs and a starter project you can download, that is The Content OS.