Claude Code Prompts: 10 Task Briefs for an Agent That Ships the Channel Too
A Claude Code prompt is a task brief for an agent that already has your repository open. It does not need to describe the stack, because the agent reads it; it needs the rules the agent cannot infer, the boundaries of the change, and a check it can run when it thinks it is done. Claude Code's own best practices put the last part first: "Claude stops when the work looks done. Without a check it can run, 'looks done' is the only signal available, and you become the verification loop" (read on 26 September 2026).
These ten prompts are the jobs a builder does after the first version exists, written for that loop: a repository bootstrap, the handover of a Lovable export, auth with row-level security proven by queries, public pages with build gates, capture, invites, lifecycle email, an event taxonomy, a changelog and sales signals. Every one ends with a Verification section that names the command, the query or the curl, and every one carries the growth surface its channel needs, which is the point of this library. This site was built and is maintained this way; the numbers further down are from our own repository.
The “Try in Lovable” links on this page are affiliate links: we may earn a commission if you create an account through one. It costs you nothing and does not change which prompts are here.
Repository Bootstrap for Claude Code
What this prompt is for
A CLAUDE.md under 200 lines, path-scoped rules, a PreToolUse hook and a verify script, so every later prompt starts from the same facts and the same gates.
When to use it
The first session in any repository Claude Code will work on regularly, including a fresh Lovable export. Run it before any feature prompt, because every later prompt assumes the gates exist.
# Context Set up this repository for repeated Claude Code sessions. The goal is that a session started tomorrow by someone else, or by you after a week, holds the same facts and runs the same checks without re-explaining anything. Read the repository first; do not guess the stack. ## Core Features (Priority Order) 1. A CLAUDE.md at the root, under 200 lines: stack with versions, the commands to b
Channel-Optimized Pro Version
This prompt has a Pro version optimized for Organic SEO / AI Search. Unlock to get product-channel fit guidance and distribution-ready features.
Lovable Export Handover to Claude Code
What this prompt is for
Take a Lovable export as it comes from GitHub sync and make it safe to edit with an agent: generated files protected, the synced branch never rewritten, secrets out of the client.
When to use it
The day a Lovable project is cloned locally for the first time. Run it once, before any feature work, so the Lovable sync survives the agent.
# Context This repository is a Lovable export synced two ways with GitHub. Lovable keeps its own copy of the synced branch and will overwrite or lose edits if that branch's history is rewritten. Your job is to make the repository safe for agent edits without breaking the sync. ## Core Features (Priority Order) 1. Identify the generated files (the Supabase client and types under src/integrations,
Channel-Optimized Pro Version
This prompt has a Pro version optimized for Organic SEO / AI Search. Unlock to get product-channel fit guidance and distribution-ready features.
Auth, Roles and RLS with Verification Queries
What this prompt is for
Sign-up, workspace, three roles and an invite flow, with row-level security written in the same migration and proven by queries the agent runs as two different users.
When to use it
The first feature in any app where users belong to a workspace. Run it before screens, because retrofitting roles touches every one of them, and before any data is public.
# Context Build the foundation of a multi-tenant app in this repository: users sign up, get a workspace, and invite teammates who arrive with the right role. Read CLAUDE.md and the existing schema first. The invite must work before anything is polished. ## Core Features (Priority Order) 1. Email and password auth with session persistence across refresh 2. Workspace created on first sign-in, creat
Channel-Optimized Pro Version
This prompt has a Pro version optimized for Product-led Growth. Unlock to get product-channel fit guidance and distribution-ready features.
Programmatic Public Pages with Sitemap and Schema
What this prompt is for
A set of server-rendered public pages from one data source, with a generated sitemap, robots, canonical tags and JSON-LD, gated by a script that fails the build when a page ships thin.
When to use it
When the app has content that people search for: locations, integrations, templates, comparisons. Run it after the bootstrap prompt so the gates exist.
# Context Add a set of public pages to this app that a search engine can index without running JavaScript. The pages come from one data file or table, one URL per entity, and each must carry enough unique text to be worth indexing. Read CLAUDE.md and the routing conventions first. ## Core Features (Priority Order) 1. A data source with one record per page: slug, title, description, body sections,
Channel-Optimized Pro Version
This prompt has a Pro version optimized for Organic SEO / AI Search. Unlock to get product-channel fit guidance and distribution-ready features.
Landing Page with Insert-Only Lead Capture
What this prompt is for
One offer, one action, a server-rendered page and a capture table the client can write but never read, with UTM parameters stored and a success state that does not redirect.
When to use it
Before any paid or organic traffic is sent to an app that does not yet have a public page. Run after the bootstrap prompt so the SSR gate exists.
# Context Build the public landing page for this app in this repository: one offer, one primary action, email capture. It must render fully on the server, load fast, and store leads in a table the client can insert into but never read. Read CLAUDE.md and the existing routes first. ## Core Features (Priority Order) 1. A hero that states what the product does in plain words, with the email form abo
Channel-Optimized Pro Version
This prompt has a Pro version optimized for Email Marketing. Unlock to get product-channel fit guidance and distribution-ready features.
Invite Loop with Attribution
What this prompt is for
Share links that attribute the new user to the inviter, an accepted-invite notification, and a funnel table, built on top of the auth foundation.
When to use it
After cc-auth-roles-rls, when the product is used by teams and the first users should bring the next ones. Skip it for single-player tools.
# Context The app has auth, workspaces and roles. Add the loop that turns one user into a team: an invite link anyone in the workspace can share, attribution of who brought whom, and the confirmation that closes the loop. Read CLAUDE.md and the invite code first. ## Core Features (Priority Order) 1. A shareable invite link per workspace, copyable from the member list, with an expiry and a revoke
Channel-Optimized Pro Version
This prompt has a Pro version optimized for Product-led Growth. Unlock to get product-channel fit guidance and distribution-ready features.
Lifecycle Emails from Product Events
What this prompt is for
A three-email sequence triggered by stored events, sent from server code with a versioned template, a suppression list, and a delivery log the agent can query.
When to use it
Once leads or users exist in a table with a status column. Run after cc-landing-capture or cc-auth-roles-rls, never before, because the sequence starts from stored state.
# Context Add lifecycle email to this app: a short sequence that starts from a stored event, sent from server code through the provider named in CLAUDE.md, with every send logged. Read the leads or users table and the existing email code first. ## Core Features (Priority Order) 1. Three templates as versioned files: welcome, the one thing to do next, and a nudge if it was not done, each with a pl
Channel-Optimized Pro Version
This prompt has a Pro version optimized for Email Marketing. Unlock to get product-channel fit guidance and distribution-ready features.
Event Taxonomy and Funnel Page
What this prompt is for
A named event list the whole app emits, a server-side sink, and an internal funnel page that reads it, so every growth prompt after this one has numbers instead of guesses.
When to use it
Right after the first public page or the auth foundation, before any paid traffic. Every later prompt in this category logs to the taxonomy this one defines.
# Context Add analytics to this app that you own: a fixed list of named events, a server-side sink that writes them to a table, and a page that turns them into a funnel. Third-party tools can be added later; the table is the source of truth. Read CLAUDE.md and the routes first. ## Core Features (Priority Order) 1. An events data file: name, required properties, and the step of the funnel it belon
Channel-Optimized Pro Version
This prompt has a Pro version optimized for Paid Search. Unlock to get product-channel fit guidance and distribution-ready features.
Public Changelog and Feedback Board
What this prompt is for
A changelog generated from merged pull requests and a feedback board with voting, both public and server-rendered, so the product's progress is a page people can link to.
When to use it
Once the app ships weekly and has users who ask for things. Run after the SEO page set prompt so the public routes share its gates.
# Context Add two public pages to this app: a changelog written from merged pull requests, and a feedback board where signed-in users post and vote. Both render on the server and both are part of the sitemap. Read CLAUDE.md and the public routes first. ## Core Features (Priority Order) 1. A changelog data file appended by a skill that reads merged PRs since the last entry and drafts one entry per
Channel-Optimized Pro Version
This prompt has a Pro version optimized for Community-led Growth. Unlock to get product-channel fit guidance and distribution-ready features.
Usage Signals for B2B Sales
What this prompt is for
A scored list of workspaces by activity and seat growth, an exportable summary per account, and a weekly digest, so a founder doing sales knows who to call before the call.
When to use it
When the product is used by companies and someone is selling it by hand. Run after cc-analytics-funnel, because the score reads the rollup.
# Context Add sales signals to this app: a score per workspace from activity and growth, a summary page per account that a maintainer can read before a call, and a weekly digest. Read CLAUDE.md, the analytics rollup and the workspace schema first. ## Core Features (Priority Order) 1. A score per workspace computed nightly from the rollup: active members in 7 and 30 days, seats added in 30 days, k
Channel-Optimized Pro Version
This prompt has a Pro version optimized for B2B Sales. Unlock to get product-channel fit guidance and distribution-ready features.
Every Prompt, Every Kit, One Payment
All 10 prompts plus every Pro variant and build kit in one bundle, plus unlimited prompt generation, $199 once. Or sign up free to copy prompts one at a time.
Browse More Categories
Related Resources
The Complete Lovable Bundle
$199 once. Unlimited generation, every prompt, every kit, every future dropEvery prompt, every Pro variant, all four build kits and every future drop, in one Notion workspace. One payment, never a subscription.
Get the 121-Prompt BundleWhich growth channels do these prompts serve?
Every prompt in this category carries a distribution section naming the channel it is built for, so the generated app has a way of being found rather than only a feature set. The chart counts primary and secondary coverage together, computed from the prompt bodies when the site is built.
| Category | prompts |
|---|---|
| Email Marketing | 4 |
| Organic SEO / AI Search | 3 |
| Product-led Growth | 3 |
| Community-led Growth | 3 |
| Paid Search | 2 |
| B2B Sales / LinkedIn | 2 |
| Organic Socials | 1 |
| Paid Socials | 1 |
| X (Twitter) | 1 |
Computed from the channel mapping in each prompt at build time; a prompt can serve more than one channel.
What is a Claude Code prompt, and how is it different from a Lovable prompt?
Both describe a feature. The difference is who holds the context and who checks the result. Lovable reads your project knowledge and asks clarifying questions before building, then you test in the preview. Claude Code reads your CLAUDE.md, the files it opens and the commands it runs, then runs whatever check you gave it. Its overview defines it as "an agentic coding tool that reads your codebase, edits files, runs commands, and integrates with your development tools", and the best-practices page's advice follows from the verbs: "Give Claude a check it can run: tests, a build, a screenshot to compare. It's the difference between a session you watch and one you walk away from."
| Lovable prompt | Claude Code prompt | |
|---|---|---|
| Where the context lives | Project knowledge, up to 10,000 characters | CLAUDE.md, under 200 lines, plus .claude/rules/ by path |
| Who asks the questions | Lovable, before building, from the Before Building line | Claude, from the same line; answers are written to CLAUDE.md |
| Who checks the result | You, in the preview; Lovable self-tests some flows | The agent, by running the check named in Verification |
| What can be enforced | Nothing; every rule is advice | Hooks: "certain actions always happen rather than relying on the LLM to choose to run them" |
| Delegation | Plan mode research subagents, metered in credits | Subagents you define, with their own tools and context |
| What it costs | Credits per message; 1.8 to 10.4 in our runs | Plan usage or API tokens; Anthropic's enterprise average is about $13 per developer per active day |
So a Claude Code prompt in this library keeps the Lovable skeleton, Context, Core Features, Build Order, Safe-Guard, Before Building, and adds two sections. Repository Rules holds the constraints the agent must not cross (never edit generated files, never rewrite the synced branch, never a policy with using true), which on a builder would live in project knowledge and here belong in CLAUDE.md. Verification names what the agent runs before it reports done: the two RLS queries as different users, the SSR gate, the curl that shows the H1 in raw HTML. The Before Building line changes too: the answers are written to CLAUDE.md, because that is the file the next session reads.
How is a Claude Code prompt in this library built?
The one to read is the auth prompt, because it is the foundation every other prompt in the category assumes and because its Verification section is the model for the rest. The sections below are read from the prompt body. Repository Rules carries the three lines that keep a generated migration safe: row-level security in the same migration, the service-role key never client-side, and no role or workspace id accepted from the client on writes. Verification then makes the first rule provable rather than asserted: two queries, one as the owner expecting rows and one as a second user expecting zero, plus the tests for sign-up, the guard, accept and expiry.
- Context: The job, and an instruction to read CLAUDE.md and the schema first.
- Core Features (Priority Order): Auth, workspace, three roles, invites, role-gated UI.
- Repository Rules: RLS in the same migration; keys server-side; ids never from the client.
- Build Order: Migration and policies before any route.
- Verification: Two queries as two users; four tests; paste the output.
- Safe-Guard Instructions: Never weaken a policy; never edit a test to pass it.
- Before Building: Ask, then write the answers to CLAUDE.md.
Headings read from the prompt body of cc-auth-roles-rls in this library.
The Safe-Guard section quotes the rule Anthropic's own prompting best practices recommend spelling out: do not delete or edit a failing test to make it pass. It is in every prompt here that has tests, because an agent that can edit tests and is asked to make them pass has an obvious shortcut, and the docs say to close it in words.
What did prompts like these produce on this site?
This site is a Next.js repository maintained with Claude Code, with a CLAUDE.md, a verify script that runs an SSR gate, a URL-contract gate and an internal-link gate, two subagents checked in under .claude/agents, and 25 skills in the workspace. On 26 September 2026 the repository's git log showed 20 commits co-authored by Claude Code since midnight, 197 files changed, 8,084 lines added and 1,423 removed, counted with git log --shortstat: seven guides, the link graph and two measurement scripts. The Cursor vs Claude Code page carries the chart and what it does not show.
- Explore: read CLAUDE.md and the code
- Plan: plan mode, or the prompt's Build Order
- Implement: one change at a time
- Verify: run the named check, paste output
- Commit: a person reviews and pushes
The four-phase workflow from Claude Code's best-practices page (explore, plan, implement, commit), with the verification step the same page asks for, read on 26 September 2026.
One of the two subagents has a measured run. Asked to check every external citation on a guide published an hour earlier, it fetched 8 URLs in 31 seconds and 112,045 tokens and found one that had moved. That is the shape of every Verification section here: a check the agent can run, a report short enough to act on, and a cost you can see. The subagents guide has the file and the numbers, and the commands guide has the skills.
How do these prompts use CLAUDE.md, rules, hooks, skills and subagents?
Each mechanism appears where the docs say it belongs, and the bootstrap prompt sets all five up. CLAUDE.md holds "facts Claude should hold in every session" per the memory documentation, under 200 lines; the answers to every Before Building line go there. Path-scoped rules in .claude/rules/ "only apply when Claude is working with files matching the specified patterns", which is where the migration and public-page rules live. Hooks are for what must not be left to judgement: the hooks guide calls them "user-defined shell commands" that give "deterministic control: certain actions always happen rather than relying on the LLM to choose to run them", so the bootstrap prompt puts the never-edit-generated-files rule in a PreToolUse hook as well as in the file.
Skills hold procedures: per the skills documentation, "a skill's body loads only when it's used, so long reference material costs almost nothing until you need it", which is why the changelog prompt makes its drafting step a skill rather than a CLAUDE.md paragraph. Subagents take the jobs whose output you do not want in your conversation; the subagents documentation notes each "sends its own requests, which count toward the same usage limits as your main conversation", so every How to improve line here that suggests one names a bounded, read-only job.
Which Claude Code prompt to use
If the repository has never had a Claude Code session, start with Repository Bootstrap, and if it is a Lovable export, run the Handover prompt immediately after. Everything else assumes the gates and the CLAUDE.md those two create.
If the app has users who belong to a team, Auth, Roles and RLS is the foundation, then the Invite Loop. If the app has content people search for, the Programmatic Public Pages prompt, then the Changelog. If traffic is about to be sent, the Landing Page and the Event Taxonomy, in that order, so the first visitor is counted.
The Email and B2B Signals prompts come last, because both read tables the earlier prompts create: a leads or users table with status, and an analytics rollup.
Suggested build order
Gates first, then the foundation, then the surfaces, then the loops that read them. Running a growth prompt before the taxonomy exists means the events get invented per prompt, which is the one mistake the category is designed to prevent.
Bootstrap the repository
CLAUDE.md, rules, hook, verify script, one skill. Every later prompt assumes them.
Prompt: Repository Bootstrap for Claude Code
Build the foundation with proof
Policies and the two queries that show they deny what they should.
Prompt: Auth, Roles and RLS with Verification Queries
Define the events once
A typed event list, so no later prompt invents names.
Prompt: Event Taxonomy and Funnel Page
Then the surfaces
Public pages with the SSR and link gates; the landing page follows the same rules.
Prompt: Programmatic Public Pages with Sitemap and Schema
Then the loops
Invites, email and signals read the tables the earlier prompts created.
Prompt: Invite Loop with Attribution
Where Claude Code prompts usually go wrong
- Describing the codebase. The agent can read it. The ETH Zurich study of context files found repository overviews "are not helpful" while instructions "are well followed"; a prompt that spends its first paragraph on architecture spends tokens on the one thing the agent already has.
- No check. A prompt that ends at Build Order gets a report that says done. Every prompt here ends with a Verification section that names a command and asks for its output pasted, because the docs are explicit that the check is what lets a session close its own loop.
- Rules in the prompt that belong in the file. A constraint that holds for every session (never edit generated files, never force-push the synced branch) goes in CLAUDE.md or a hook, once. Repeating it per prompt means it is missing from the prompt that forgot.
- Letting the agent edit tests. Anthropic's prompting guidance says to state that removing or editing tests is unacceptable; the prompts here say it, and the bootstrap hook can enforce it for the test directory.
Frequently asked
Are these prompts for Claude Code only, or do they work in Cursor and Copilot?↓
They work anywhere an agent has the repository open and can run commands, which includes Cursor's Agent and Copilot's agent mode. Two sections are Claude Code-specific in wording: Before Building writes answers to CLAUDE.md, and the bootstrap prompt creates .claude/rules, hooks and a skill. In Cursor the equivalents are .cursor/rules and AGENTS.md; the Cursor rules guide on this site has three files that mirror the bootstrap prompt.
What does a Claude Code prompt cost to run?↓
On a Claude subscription, plan usage in five-hour and weekly windows; on the API, tokens. Anthropic's cost page gives the only published average: around $13 per developer per active day across enterprise deployments, with 90% of users under $30 a day. The one run we can price here is a subagent checking 8 citations: 112,045 tokens and 31 seconds. A foundation prompt with tests will cost more than that, and the docs' advice to use plan mode first is the cheapest way to avoid paying for the wrong approach.
Why does every prompt end with a Verification section?↓
Because Claude Code's own best-practices page says the check is what turns a session you watch into one you can walk away from, and because an agent reports done when the work looks done. Naming the command, the query or the curl, and asking for its output, replaces your review of a plausible result with the agent's review of an actual one. The Stop hook mentioned in the bootstrap prompt makes it mandatory.
Do I still need the Lovable prompts if I use these?↓
Yes, if you build in Lovable. The Lovable prompts produce the first version inside the builder; these prompts assume a repository the agent can edit and check, which is what a Lovable export becomes after the Handover prompt. The two libraries share the skeleton so the same feature can be described in either, and the growth channel is the same on both sides.
Should the rules in these prompts go in CLAUDE.md instead?↓
The ones that hold in every session, yes, and the bootstrap prompt moves them there: never edit generated files, never rewrite the synced branch, secrets server-side only. The prompts repeat only the rules specific to their job, such as the RLS policy shape in the auth prompt. The CLAUDE.md guide on this site shows what a year of not doing that separation looks like.
How were these prompts tested?↓
Against this site. The bootstrap, public pages, changelog and analytics prompts describe work that was done on this repository with Claude Code over the last two months, with the gates named in them running on every push. What has not been done is a timed, tokened run of each prompt on a fresh repository, and the page does not claim one; the numbers here are the day count and the subagent run, both from our own logs.
Related reading
- Claude Code commands and skills
Built-ins, a working SKILL.md, the 25 we run.
- Claude Code subagents
The config, two we run, one measured run.
- the CLAUDE.md file
Where every Before Building answer goes.
- Cursor rules
The same rules for the other editor.
- Cursor vs Claude Code
Editor or agent, priced and measured.
- coding prompts for ChatGPT, Claude and Copilot
The short form of these briefs.
- Lovable SaaS prompts
The same foundation, for the builder.
- backend prompts for roles, jobs and RLS
The policies these briefs prove.
- the SaaS starter kit
Executed schema and verification queries.
- Lovable SEO
What the public-pages gates protect.
- Cursor prompts
The same ten jobs, with rules where these have CLAUDE.md.
- cursorrules examples
The editor-side rule files, by framework.
Sources
All checked on 26 September 2026.
- Claude Code docs: Overview
- Claude Code docs: Best practices
- Claude Code docs: How Claude remembers your project
- Claude Code docs: Automate actions with hooks
- Claude Code docs: Extend Claude with skills
- Claude Code docs: Create custom subagents
- Claude Code docs: Manage costs effectively
- Anthropic docs: Prompting best practices
- Gloaguen et al., Evaluating AGENTS.md (arXiv 2602.11988)
Updated .
Written by
Marco Kohns
Founder of ProtoBites - Venture Growth Studio
Growth PM at a Silicon Valley scale-up (a16z and General Catalyst backed), ex-Techstars where he consulted 13 early-stage startups, Reforge-trained. Every prompt on this site comes out of shipping ProtoBites' own portfolio products.
Help shape this product
We're building this in public and your input genuinely matters.
If something felt confusing, missing, or especially useful, I'd love to hear about it. It takes ~30 seconds and helps me improve the parts that matter most.
Share quick feedbackGoes straight to the builder. No marketing questions. No auto-replies.