Copy the prompt. Run the job.

I have a content format that's already converting for [product]: [describe
it]. I want to stop hand-picking one-off creators and build a real
pipeline instead.

Read GOALS.md and ICP.md, then help me set up the four stages:

1. SOURCING — draft an inbound application (a short form I can post in
   UGC group chats, on Reddit, or on a creator marketplace) that screens
   for the specific skill this format needs (talking-head confidence,
   reaction/facial expressiveness, whatever fits). Also draft outbound
   outreach copy for a VA to send to matching micro-creators.
2. ONBOARDING — write a short training course for new creators: what the
   product actually does, the exact format that's working (with real
   examples), the do's and don'ts, and a short quiz at the end so I know
   they actually absorbed it before they post.
3. MANAGEMENT — recommend a lightweight way to run this at 5-10 creators
   without it eating my week: a shared channel for feedback, a cadence
   for check-ins, and a rule for promoting my best creator into a
   part-time manager once volume justifies it.
4. SYSTEMATIZE — once this is working, what's the simplest referral or
   incentive structure to get my current creators to recruit more, and
   what's the minimum dashboard I need to see which creators/formats are
   actually producing signups, not just views?

Keep every draft as lean as possible — this has to run with just me and
maybe one part-time helper.

What to watch for

• The training course is the leverage point: creators who go through a real onboarding (not just “here’s the app, go post”) convert at a much higher rate than creators left to guess. Don’t skip it to save an afternoon.
• Don’t build this before find-your-format-then-clone-it has actually found a format worth scaling — a pipeline optimizes a working format, it doesn’t discover one.
• This assumes a product with high enough margins to absorb creator payouts across dozens of contributors. For lower-margin or service businesses, one or two trained creators plus your own posting is a more honest target than a 200-creator operation.

There's an established competitor in my space: [name it]. I want my first
customers to come from people already searching for or using them.

Help me run this:

1. Search "[competitor] alternative," "[competitor] vs," and the
   competitor's own community/forum/Reddit for the specific complaints
   people have (pricing, a missing feature, bad support). List the real,
   recurring ones.
2. Draft a comparison page for the complaint that's most winnable for me
   specifically — honest, not trashing them, just naming what's true.
3. If switching costs are the objection, sketch the smallest possible
   migration tool or manual process to move a user's data/setup from
   [competitor] to mine in one step.
4. Give me 10 places (their subreddit, forum, Indie Hackers, review
   sites) where people already post asking for alternatives, and draft
   how I'd show up there — genuinely helpful, disclosed, not spammy.

What to watch for

• This only works against a competitor people visibly complain about — check that the complaints are frequent and specific before building around them, not just a hunch that “they’re too expensive.”
• The migration tool is the highest-leverage single thing here: it turns “I’d switch if it weren’t a hassle” into an actual signup.
• Doing this by hand for the first 10-20 users (personally replying, personally building someone a migration) doesn’t scale forever, but it’s the fastest way to real customers before you have any traffic of your own.

I'm considering a SaaS/tool idea for [industry or platform, e.g. "Shopify
stores," "restaurants running delivery-app ads," "email/SMS marketing"].

Help me check whether an agency layer exists here, and if so, size it:

1. Does this industry have agencies who manage this function on behalf of
   many clients (not the end businesses doing it themselves)? Name the
   likely agency type.
2. Find the platform(s) those agencies build on (e.g. Klaviyo, Shopify,
   whatever the underlying tool is) and tell me whether that platform
   publishes a public partner/agency directory — most major platforms do.
   That directory is my prospect list, ranked by size, for free.
3. Because every agency in that directory is standing on the same
   platform, what's the one problem I can safely assume all of them
   share? Name it specifically, not generically.
4. Sketch a per-seat or per-client pricing model: what would an agency
   with 10 clients pay vs. one with 50? Seats for their team, seats for
   their clients if relevant.

If this industry doesn't have an agency layer, say so — some don't, and
the play doesn't work without one.

What to watch for

• The prospecting is the cheat code here: you don’t need cold outreach lists or paid data — the partner-directory page IS the list, already ranked by size and influence.
• One sale reaches many end-users. Price per seat (agency staff seats, client seats), not a single flat subscription, or you leave the real value of the model on the table.
• This is a strong fit for unglamorous, overlooked B2B niches — it won’t look as exciting as a consumer app, but the churn and deal sizes tend to be far better. Don’t discount an idea just because it’s boring.

My ideal customer is: [describe your ICP]. I want to find people who
already have their trust and reach a lot of them at once, rather than
selling direct one at a time.

Help me:

1. Name who sits "one level above" my ICP: coaches, consultants, agencies,
   or influencers my ICP already pays or listens to for advice in this
   space.
2. Rank what makes one of them a strong connector: size of their network,
   how much trust/reputation they carry with my ICP specifically, and
   whether they're good at selling.
3. Draft a personalized outreach pitch to one specific connector —
   referencing their actual work, not a template — framed as a high-value
   one-time conversation, not a cold pitch to try my product.
4. Propose a commission structure (recurring, not one-time) that's
   generous enough to make recommending me worth their reputation, and a
   simple way to track and pay it out.

What to watch for

• A connector pitch is a high-ticket sales conversation, not a numbers game — one good connector can be worth more than a hundred cold outreach attempts to end users.
• Pick connectors by trust and fit, not just audience size. Someone with a smaller but highly-trusted, highly-relevant following often converts better than a big generic account.
• Different play from selling a tool directly to agencies (find-the-agency-layer-in-your-market). There, the agency is the customer. Here, the connector never buys anything — they’re your channel to the people who do.

Here's what I've posted about [product] in the last [timeframe]: [paste
links, or describe each post and what happened — views, signups, sales].

Read GOALS.md and ICP.md. Then:

1. Which of these, if any, actually converted (not just got views — got
   signups or sales)? Tell me plainly if the honest answer is "none yet."
2. For whichever one worked best, name exactly what made it work: the
   hook, the format (demo, day-in-the-life, before/after), the length, the
   first three seconds.
3. Write me 5 variations of that exact format, same structure, different
   specifics — treat it as a template to refill, not a new creative brief
   each time.
4. Give me a posting cadence I can actually sustain (name a number, not
   "post more") until one of these variations either breaks the pattern
   or confirms it.

If nothing has converted yet, don't invent a winner. The plan is to keep
posting daily until a pattern shows up — give me a starting format to
test based on what the product does.

What to watch for

• The mistake this fixes: treating every post as a fresh creative problem. Once something converts, the job becomes cloning it, not reinventing it.
• Any content is better than no content — the founders who won here posted daily for weeks before anything hit. Don’t judge the format after one try.
• This assumes a product simple enough to show solving a problem in under 30 seconds. If your business doesn’t demo that fast (most services, most B2B), the format-and-clone loop still applies, but the channel is usually search or word-of-mouth, not short-form video — see the content-engine plays instead.

I launched [product] as a subscription/freemium and it isn't converting:
[describe what's happening]. I'm bootstrapped, not funded.

Help me evaluate switching to a one-time or lifetime-deal price instead:

1. Could this product run on a bring-your-own-keys model (the user supplies
   their own AI/API key) so I carry near-zero variable cost per user?
   If yes, sketch what that setup actually requires.
2. Recommend a starting lifetime-deal price low enough to prove demand
   fast, with a rule for raising it as the first 100-200 users come in
   (early buyers get the best deal, on purpose).
3. Is my product a fit for a one-time price (a tool with a clear finished
   feeling), or does it need ongoing value that only a subscription
   captures? Don't force a lifetime deal onto a product that needs
   recurring revenue to make sense.
4. Draft the pricing-page copy explaining the one-time price plainly,
   no artificial urgency.

What to watch for

• This is a bootstrapped-specific move: funded companies can subsidize a slow freemium funnel while they find product-market fit; a bootstrapper usually can’t afford that runway. A lifetime deal front-loads cash and gives you a committed, vocal early user base faster.
• Bring-your-own-keys only works when your product’s core value isn’t the AI inference itself — check that the value proposition survives when the user, not you, pays for usage.
• Don’t treat this as the permanent model. Several founders using this pattern plan to move to recurring pricing once volume and trust are established — a lifetime deal is a bootstrapping tool, not necessarily the end state.

This post/format converted organically: [describe it, and the numbers —
views, signups or sales it produced]. I'm deciding whether to put money
behind it.

Read GOALS.md. Then:

1. Tell me what I actually need to track to call this a win or a loss:
   spend, views, and whatever counts as a conversion for this business —
   name the exact metric, not a vague "engagement."
2. Recommend a small first test budget and duration (don't let me
   over-invest before there's a real signal).
3. Give me the go/no-go math in plain terms: what return counts as
   "keep scaling this" vs. "kill it and try the next format" — spell out
   what breakeven looks like for my numbers, don't just say "aim for
   positive ROAS."
4. Write the brief I'd hand a UGC creator or use for an ad, reusing the
   exact hook and structure that already worked organically — don't let
   it drift into a generic ad.

Assume most individual creatives lose money and that's fine — the point
is finding which ones don't, cheaply, before scaling spend.

What to watch for

• Don’t skip the organic proof step. If a post hasn’t converted for free yet, paying to promote it just buys the same lesson at a higher price.
• This whole loop (UGC creators, paid ads, ROAS) assumes consumer-app or SaaS margins high enough to absorb losing creatives while the winners pay for themselves. For lower-margin or service businesses, treat this as a “prove distribution before spending” template, not a paid-ads recommendation — the spend levels here won’t make sense at every margin.
• Track spikes, not perfect attribution. If a post’s view-spike lines up with a signup-spike, that’s a good enough signal to act on — don’t wait for clean attribution that influencer/UGC marketing rarely gives you.

I have an app/SaaS idea: [describe it in 2-3 sentences]. I've personally
felt this problem myself: [say how, specifically].

Read PRODUCT.md and GOALS.md. Then help me scope the smallest version of
this that I could charge money for by the end of this week:

1. Cut every feature that isn't the one thing solving the core pain point.
   Name what I'm tempted to add and why it can wait.
2. Recommend the leanest stack for a solo build: hosting, auth/database,
   payments, and (if relevant) the one API this depends on. Default to the
   boring, fastest-to-ship option over the "correct" one.
3. Write the actual scope as a task list I can hand to Claude Code, ordered
   so payment collection works before anything else is polished.
4. Flag anything in scope that's actually a distribution problem
   disguised as a feature request — that gets solved by marketing, not code.

Don't suggest a beautiful logo, a design system, or a roadmap of future
features. The only goal is: real users, paying, this week.

What to watch for

• If you haven’t personally felt the pain point, this playbook is premature — validate the idea first (see the idea filter, idea-filter-before-you-hire-the-team), then come back here.
• This works best in high-margin, fast-to-demo products — a consumer app or SaaS tool. If you’re building a service business, the “ship this week” compression doesn’t transfer the same way; scope a pilot client instead.
• Charge from day one. A free tier with no paying users tells you nothing about whether the pain is real enough to solve.

I'm considering building: [describe the idea and the pain point it solves].

Help me run a three-part check on this before I build anything, using
whatever short-form platform (TikTok, Instagram, YouTube Shorts) my
audience actually lives on:

1. VIRAL — has content about this exact pain point or format already hit
   real numbers (100K+ views) on MULTIPLE similar posts from small
   accounts (under 5K followers)? Small-account virality means the
   content wins on its own, not on someone's existing reach. Tell me what
   to search for to check this, and how to tell a real pattern from one
   lucky post.
2. SCALABLE — could I produce 50-100 variations of whatever format wins,
   without burning out? Name the cheapest realistic way to get that
   volume (AI-generated content, or low-cost overseas UGC creators) for
   this specific idea.
3. CONVERTIBLE — if I found content like this, what would I look for in
   the comments to know it would actually convert to signups, not just
   views? ("what's the app," "where do I get this" vs. generic
   engagement.) Give me the actual language to watch for.

Score each of the three honestly. If any one is weak, tell me plainly
whether that's a build-anyway-but-expect-a-slow-start problem or a
kill-it problem.

What to watch for

• This checks the growth motion, not the business model — pair it with the idea filter (idea-filter-before-you-hire-the-team) for the business-model side; they answer different questions.
• Don’t substitute a big-account viral post as proof — that tells you about the account, not the idea. The under-5K-follower bar is the whole check.
• This assumes a product simple enough to demo or tease in a single short-form clip. If your business can’t be shown solving a problem in under 30 seconds, this framework doesn’t apply as directly — validate through search intent or direct outreach instead.

I'm deciding whether Google (organic + paid search) should be my one
growth channel for [product]. My buyers are people actively searching for
a solution, not scrolling social media.

Help me plan it:

1. Find 15-20 bottom-of-funnel keywords: low competition, clear buying
   intent, close to my exact value proposition (not generic informational
   terms — those are losing to AI answers now).
2. For each keyword, sketch a landing page brief that answers the intent
   directly and can serve BOTH an organic ranking attempt and a paid
   search ad, so I only create the content once.
3. Recommend a starting paid-search budget and a target CPA based on my
   pricing, plus the math for what "working" looks like (CAC under ~30%
   of first-year revenue as a sane ceiling).
4. Give me a realistic timeline: which keywords might rank organically in
   3-6 months, and which should run as ads from day one while I wait.

What to watch for

• Pick one channel and get good at it before adding a second — mediocre effort spread across ten channels loses to depth in one.
• This works best for products people actively search for by name or category (SaaS tools, B2B services). If nobody searches for what you’re building yet, this isn’t your first channel — you need to create the demand first, which is a different playbook.
• Reuse the same content and keyword research for both organic and paid; don’t run two separate content operations for the same intent.

If you’ve been talking to Claude for a while already, in a project or a long-running chat, use this first. Claude has likely seen more of your actual writing than you’d guess.

I need you to write my VOICE.md file: a memory file that captures how I
actually write, so future drafts sound like me. You have a long history
of me typing to you directly here. Use it.

1. Look back through our conversation history and find two or three
   places where I wrote something substantial in my own words, not a
   quick one-line instruction. Quote them verbatim if you can find them.
2. Beyond direct quotes, tell me honestly what patterns you've noticed:
   sentence length, structure, favorite words or phrases, what I say
   often, what I never say.
3. List words and phrases I'd never use, based on what you've seen me
   edit out or react badly to.

Write VOICE.md directly: real quotes where you have them, your honest
characterization where you don't, and the avoid list. Label anything
that's your observation rather than my exact words, so I can tell the
difference.

No history to draw on yet? Start fresh instead:

I need to build a VOICE.md file: a short memory file that captures how I
actually write, so drafts sound like me instead of a generic assistant.

Ask me these questions one at a time, waiting for my answer before the
next one:

1. Paste two or three things you've written yourself, unaided: an email,
   a post, a message, anything real.
2. What are three words or phrases you'd never use? What do you cut on
   sight when you see it in a draft?
3. Is there a real person or publication whose writing you'd point to and
   say "closer to that"?

Once I've answered, write VOICE.md: the real samples, the avoid list, and
a short "not me" section I can add to over time. Don't invent or smooth
over anything. If an answer is thin, say so instead of padding it out.

What to watch for

• The history-mining version usually works better if you’ve genuinely been using Claude a lot. The blank-page version is the fallback, not the default.
• Treat the first version as a draft. Add to the “not me” list the next time a Claude draft comes back sounding wrong.
• A quick chat reply can be a legitimate sample. Real and rough beats polished and generic every time.

Here's the cancellation email / exit survey / support thread from a user who
churned: [paste the real thing].

Read GOALS.md for what we're currently prioritizing. Then tell me:
1. What they actually said, separated from what I might be tempted to read
   into it
2. Whether this looks like a one-off or matches a pattern you'd expect to
   recur
3. One specific, concrete thing I could change this month that plausibly
   addresses it — not a vague direction
4. Whether this should actually change GOALS.md, or if it's noise

Don't be diplomatic. If the honest read is "this doesn't matter much," say so.

What to watch for

• One angry email is a data point, not a mandate — the “one-off vs. pattern” check matters more than it looks like it does. Don’t rebuild your roadmap around a single loud voice.
• Paste the actual message. A paraphrase strips the specific phrasing that usually carries the real signal.

I'm going to describe my company out loud, roughly and out of order: [dump
everything you know — what you do, who you sell to, how you make money,
your stage, what makes you different, how you like things written].

Turn this into a clean CLAUDE.md: what we do, who we sell to, how we make
money, current stage, what makes us different, and a short voice note. Plain
markdown, no headers deeper than needed. Flag anything you had to guess at
or smooth over instead of silently filling the gap.

What to watch for

• The “flag anything you guessed” instruction is the whole point — a confident-sounding gap-fill is worse than an honest blank, since you’ll trust the file later without checking it.
• Treat the first version as a rough draft, not a finished file. Read it back and fix anything that sounds like a generic company instead of yours.

Here's a prospect: [paste whatever public info you have — their site, a post
they wrote, their LinkedIn, anything real]. Here's ICP.md for who we're
actually trying to reach and why.

Draft a cold email that:
- Opens with something specific to them, not a compliment that could apply
  to anyone
- Gets to the point in the first two sentences — no throat-clearing
- Makes one clear ask, not three
- Is under 100 words

Flag anything in your draft that could apply to literally any prospect —
that's the part that needs to get more specific or get cut.

What to watch for

• If you only give it a company name, it’ll invent generic-sounding personalization. Give it something real and specific to reference, or skip the personalization line entirely rather than fake it.
• Compare the first draft against your own gut before you send anything at volume — this earns trust over a week of use, not on the first try.
• No ICP.md yet? See what is ICP, and how to actually write yours first — this prompt leans on it directly.

We're launching: [describe what, in your own rough words]. Read VOICE.md for
how I write and PRODUCT.md for context.

Draft a launch post that:
1. Opens with what changed for the user, not with our internal milestone
2. Explains the problem this solves in one paragraph, plainly
3. Says what it doesn't do yet, if anything — under-claim rather than overclaim
4. Ends with one clear next step for the reader

Keep it under 300 words. I'll tell you what's wrong; don't try to guess and
hedge everything.

What to watch for

• If the draft reads like a press release, that’s VOICE.md needing more of your actual writing in it, not a prompt-wording problem.
• Resist puffing up the “what it doesn’t do yet” section into a roadmap teaser — say the limitation plainly and move on. Under-claiming is the credibility move here, not filler.

Here's our feature list: [paste it, however rough]. Here's USERS.md for what
our users actually complain about.

For each feature, write one line of benefit copy that answers "so what does
that actually get me" — tied to a real complaint from USERS.md where you can
connect one, not a generic benefit. If a feature doesn't obviously map to
anything in USERS.md, say so instead of forcing a connection.

No hype words. No "revolutionize," "seamless," "game-changer." Plain claims
a skeptical reader would believe.

What to watch for

• The instruction to avoid hype words is doing real work here — check the draft against it, since models default toward inflated language unless told plainly not to.
• A feature with no honest connection to a real user complaint is a signal, not just an awkward line to smooth over — it might not be worth the copy space.

I have a meeting with [name/company] in a few minutes about [topic]. Read
[relevant notes, past emails, or CRM entry if available].

Give me, in one short screen:
1. Who they are and why this meeting is happening
2. What was discussed or decided last time, if there's a history
3. The one thing I should make sure to ask or confirm this time
4. Anything I said I'd follow up on that I haven't yet

Keep it to what I need in the next five minutes, not a full history.

What to watch for

• This is only as good as what you point it at — if the relevant context lives somewhere Claude can’t read (a verbal conversation, a text message), say so up front rather than getting a confident summary missing the actual key fact.
• Use this as a last-five-minutes tool, not a replacement for actually knowing your important relationships.

I'm interviewing users about [the problem area or feature you're exploring].
My working theory is: [state your hypothesis honestly].

Write me 8-10 interview questions that could prove my theory wrong, not just
confirm it. Avoid any question that hints at the answer I want. Prefer
"tell me about the last time you..." over "don't you think..." Flag any
question in your draft that's secretly leading, and tell me why.

What to watch for

• If you paste your hypothesis in, the model will sometimes still soften questions to agree with it — check the “why” flags it gives you, since that’s where it’ll admit which ones are still leading.
• Good questions ask about specific past behavior, not opinions about the future. If a question could be answered “I think I’d probably…” rewrite it.

Here are my last two investor updates: [paste them]. Here's this month's
actual data: [paste the real spreadsheet or export — not a summary of it].
Here's GOALS.md for what we said we'd focus on.

Draft the next update:
1. The headline number, and how it compares to last month, plainly
2. What we said we'd do last time, and whether we did it
3. What's working, what isn't, one paragraph each
4. The specific ask, if there is one

Match the voice and structure of my last two updates. Flag any number you
had to infer rather than pull directly from what I gave you.

What to watch for

• This only works if you paste the actual numbers. A one-line description of your metrics gets you a vague, unconvincing draft — the model can’t invent precision you didn’t give it.
• Read the “what we said we’d do” section carefully before it goes out — that’s the paragraph where founders are most tempted to let a generous draft round up.

I need to hire for: [the role, in your own words — even if it's rough].
Read PRODUCT.md and GOALS.md for context on what we're building and where
we're headed.

Write a JD that:
1. States the actual problem this hire solves for us in the first two lines,
   not a generic role description
2. Lists 3-4 concrete things they'll do in month one
3. Is honest about our stage — don't imply resources or scale we don't have
4. Names the specific experience that actually matters, and skips generic
   requirements that would apply to any candidate anywhere

What to watch for

• Watch for generic corporate-JD language creeping in — “fast-paced environment,” “wear many hats” — and cut it; a sharp candidate reads past it anyway.
• If you can’t answer “what do they do in month one” specifically, that’s a sign the role itself isn’t defined yet — worth fixing before the JD goes out, not something to paper over with vaguer language.

Here are my raw notes / the transcript from today's meeting: [paste it].

Pull out, separately:
1. Decisions that were actually made — stated as decisions, not discussion
2. Action items, each with a specific owner (flag any with no clear owner)
3. Things that were debated but explicitly left unresolved
4. Anything that contradicts what's in GOALS.md or DECISIONS.md, if anything

Don't invent an owner if the meeting didn't assign one — flag it as
unassigned instead of guessing who probably has it.

What to watch for

• Meetings are often vaguer about ownership than they feel in the room — the “flag unassigned” instruction matters, since a guessed owner is worse than an honest gap.
• If several things got “decided” that quietly conflict with GOALS.md, that’s worth a second look before you write them into DECISIONS.md as final.

Here's our current metrics export: [paste the real data]. Here's
METRICS_DEFINITIONS.md for exactly what each term means at our company.

Produce a one-screen summary:
1. The 3-5 numbers that actually matter this month, with direction (up/down)
2. One line each on why they moved
3. The single biggest risk, stated plainly
4. What "on track" means this quarter, per GOALS.md, and whether we're on it

Use our exact definitions from METRICS_DEFINITIONS.md — don't substitute a
generic definition of a term like "ARR" if ours is different.

What to watch for

• Spend real time getting METRICS_DEFINITIONS.md pedantically precise once — vague definitions here quietly poison every summary built from them afterward.
• If a number moved and you don’t actually know why, let the draft say “unclear, worth investigating” rather than accepting a plausible-sounding guess.

Here's COMPETITORS.md with who we track and why. Check their public pages,
changelogs, and any recent posts or launches.

For each one, tell me:
1. What actually changed since last time — skip it if nothing did
2. Whether it's a real threat to us specifically, or just activity
3. One thing worth reacting to, if anything, and what "reacting" would
   actually look like

If nothing meaningful changed anywhere, say that plainly instead of padding
the report to look thorough.

What to watch for

• Run this monthly, not daily — daily just trains you to skim past it, and most competitors don’t move fast enough to justify more frequent checks.
• “Just activity” is a real, useful category — not everything a competitor does is a signal you need to respond to. Resist the urge to react to noise.

I want to build [describe the idea in a sentence or two, however rough].
Read PRODUCT.md and USERS.md in this folder for context.

Write a one-page PRD:
1. The problem, in one paragraph — who has it, how you know
2. The proposed solution, in plain language
3. What's explicitly out of scope for v1
4. Three to five acceptance criteria a reviewer could actually check
5. The one thing you're least sure about, flagged as a question, not a fact

Keep it to one page. If a section would make it longer, cut detail, not sections.

What to watch for

• If the draft is confident about things you’re actually unsure of, that’s the model filling gaps with plausible-sounding guesses — push back and make it flag its assumptions instead.
• A PRD that reads well isn’t the same as one that’s buildable. Read the acceptance criteria out loud — if you can’t picture checking them against a shipped feature, they’re too vague.

Here's what I'm about to build: [paste your PRD, spec, or a real description].

Imagine it's three months from now and this shipped, but it failed — nobody
used it, or it caused a real problem. Write the retrospective explaining why.
Be specific: name the failure mode, not just "adoption was low."

Then give me the top 3 risks from that retrospective ranked by how likely they
are, and one concrete thing I could do this week to reduce each one.

What to watch for

• The model will happily invent dramatic failure modes if you let it — ask it to ground each one in something plausible given your actual users and stage, not a generic startup horror story.
• This works best run once, seriously, before you start — not as a recurring ritual. Running it on everything trains you to ignore it.

Here's my pitch / deck outline: [paste it].

Play a skeptical, experienced investor who's seen a hundred pitches like
this. Ask me the five hardest questions you'd actually ask before writing a
check — market size skepticism, why now, why us, the obvious competitive
threat, the weakest part of the traction story. Don't soften them.

After I answer each one, tell me honestly whether my answer would satisfy
you or if I'm dodging.

What to watch for

• Tell it explicitly not to go easy on you — left to a default, it’ll sometimes ask questions gentler than a real investor would.
• This is a rehearsal tool, not a fundraising strategy — the honesty is only useful if you actually answer in writing and let it push back, not just read the questions and nod.

Here's a prompt I keep reusing, slightly rewritten each time: [paste it].

Turn this into a Claude Code slash command: figure out what should stay fixed
versus what should be an argument I pass in each time, write the command
file, and give it a short, memorable name. Show me the exact file and where
it goes. Then tell me how to invoke it with an example.

What to watch for

• The value is in correctly splitting “always the same” from “changes every time” — if the command comes out with everything hardcoded, it’s not actually reusable, just a renamed copy.
• Check current capabilities in Claude Code for the exact command-file format and location, since this is the kind of mechanic that gets refined over time.

Here's GOALS.md for what we're building toward this quarter. Here are the
roles I expect to hire for: [list them, even roughly].

For each role, draft a JD:
1. The actual problem this hire solves, in the first two lines
2. 3-4 concrete things they'll do in month one
3. Honest about our current stage — no implied resources we don't have
4. The specific experience that actually matters for this role

Flag any role on my list where you're not sure it's actually a hiring
problem versus something closer to a workflow gap.

What to watch for

• Batch-drafting doesn’t mean batch-hiring — draft all the JDs now, but still post and interview for each role only when you’re actually ready to run that process well.
• The “is this actually a hiring problem” flag is worth reading carefully — see the role you’re about to hire for for the fuller version of that question.

Here's the transcript from a podcast [I was on / we recorded]: [paste it].
Read VOICE.md for how I write.

Pull out:
1. The 3-4 strongest standalone ideas or quotes — things that work outside
   the context of the full conversation
2. One longer post (300-500 words) expanding on the single best idea
3. 4-5 short social posts, one per strong moment, in my voice
4. One question worth asking my audience, inspired by something raised in
   the conversation

Cite the approximate timestamp or section each piece came from, so I can
verify it against the actual recording.

What to watch for

• Only pull ideas that were actually said — a transcript can be messy, and it’s easy for a summary to smooth a rough sentence into something clearer-sounding than what was actually said. Verify anything you plan to quote directly.
• Spread the repurposed pieces out over real time (two weeks, not two days) — a burst of five posts about one appearance reads as content-mill, not genuine.

Review this diff like a skeptical senior engineer, not like the person who
wrote it. Check for:
1. Logic errors or edge cases the code doesn't handle
2. Anything that looks copy-pasted without being adapted
3. Places where the naming or structure doesn't match the rest of the
   codebase's existing conventions
4. Anything you'd flag in code review even if it "works" — unclear names,
   dead code, a comment that's now wrong

Don't rewrite anything. List findings with file and line, ranked by severity.

What to watch for

• Run this in Claude Code, pointed at the actual diff — not a description of the change pasted into chat. It needs to read the real files to catch anything real.
• It’ll sometimes flag stylistic nitpicks alongside real bugs with equal confidence. Triage by severity yourself; don’t fix everything it lists.

Here's a support message: [paste it].

Read VOICE.md for how I write. Draft a reply that:
- Actually answers what they asked, not a generic acknowledgment
- Sounds like me, not like a support macro
- Is honest if the answer is "no" or "not yet" — don't oversell a workaround
- Flags anything you're not sure is accurate about our product, instead of
  guessing

This is a draft only. I'll read it and send it myself.

What to watch for

• Draft-only, always. Never wire this to auto-send — one confidently wrong answer to a real customer costs more trust than a slow reply.
• If it keeps sounding like a support macro despite VOICE.md, that’s a sign the file needs more real examples of you actually writing to a frustrated customer, not just marketing copy.

Here's a real update: [paste a recent post, changelog entry, or a rough
description of something real that happened]. Read VOICE.md for how I write.

Turn this into 5 distinct social posts, one per weekday:
1. The headline version — the core update, stated plainly
2. The "why it matters" angle — what problem this solves for someone
3. A behind-the-scenes angle — what building it was actually like
4. A question to the audience related to the update
5. A callback/recap tying it together

Each one should stand alone — no post should require having read the
others. Flag any post that's just restating #1 without a distinct angle.

What to watch for

• Five posts from one real update only works if the update has enough real substance — don’t force five distinct angles out of something genuinely thin.
• Read all five before scheduling any — repetition is easier to spot across the full batch than one at a time.

Read [your notes folder / recent docs / whatever you keep this week's mess
in]. Give me one screen covering:
1. What actually changed this week
2. Decisions I made but haven't reflected in GOALS.md yet
3. Open items and who owns them
4. The thing I've been avoiding that I probably shouldn't be

Write it in my voice, per VOICE.md. Keep it under 300 words — if it's longer,
you're including things that don't matter this week.

What to watch for

• This is the first workflow worth making recurring, per the 90-day roadmap — run it by hand a few times before you turn it into something that runs on a schedule.
• “The thing I’ve been avoiding” is the line most founders are tempted to skip reviewing carefully. Read that one first, not last.