Agent prompts

Reusable SaaS prompts for Claude, Codex, Cursor, and Windsurf.

Toolbound prompts turn repeated coding-agent work into bounded tasks with inputs, safety rules, output contracts, and verification commands. They are designed for buyer-owned SaaS repos, not managed agent hosting.

Add workflow

Add a new SaaS workflow

reusable task

Ask Claude, Codex, Cursor, or Windsurf to add a new workflow without damaging billing, usage, approvals, logs, or tests.

Most workflow changes touch product logic and commercial rails at the same time. A bounded prompt keeps the agent focused on the new capability and the checks that prove it still works.

Inputs

Workflow name and target user
Input shape, output shape, and success state
Risk level and whether human approval is required
Files the agent may edit

Safety rules

Keep billing, auth, usage limits, and send paths high-caution unless explicitly in scope.
Do not bypass approval gates, suppression checks, or operational logging.
Add or update tests beside the changed workflow logic.

Output

Implementation summary
Files changed
Risk notes
Verification output

Verification

npm run test && npm run lint && npm run build

one-paste prompt

Give this to your coding agent

You are working in a buyer-owned Toolbound Stack repo. Add a new SaaS workflow with the following inputs:

- Workflow name:
- Target user:
- Input shape:
- Output shape:
- Success state:
- Risk level:
- Human approval required:
- Files you may edit:

Follow the repo instructions in AGENTS.md, CLAUDE.md, ARCHITECTURE.md, and DOMAIN_GLOSSARY.md before editing. Keep billing, auth, usage limits, send paths, suppression checks, approval gates, and operational logging high-caution unless this task explicitly includes them.

Return:

- Implementation summary.
- Files changed.
- Risk notes.
- Tests or verification run.

Definition of done: npm run test && npm run lint && npm run build passes, or you explain the blocking error.

Customise niche

Customise Toolbound for a SaaS niche

reusable task

Turn the buyer-owned boilerplate into a specific paid SaaS idea while preserving Stripe, Resend, Postgres, setup checks, and agent docs.

Agents can rewrite too much when a founder gives them only an idea. This prompt keeps product positioning, launch flow, and commercial rails separate.

Inputs

Target customer
Painful workflow being productised
Pricing angle
Compliance or data sensitivity notes
Launch flow: paid beta, freemium, or lifetime deal

Safety rules

Do not claim the final vertical product is already built unless it is implemented.
Preserve checkout, webhook idempotency, delivery email, and setup status semantics.
Keep buyer-only briefs private unless the user asks to publish a summary.

Output

Positioning rewrite
Recommended page/doc edits
Implementation checklist
Verification plan

Verification

npm run verify

one-paste prompt

Give this to your coding agent

You are working in a buyer-owned Toolbound Stack repo. Customise the product direction for this SaaS niche:

- Target customer:
- Painful workflow:
- Product outcome:
- Pricing angle:
- Compliance or data sensitivity notes:
- Launch flow: paid beta, freemium, or lifetime deal.

Read AGENTS.md, ARCHITECTURE.md, DOMAIN_GLOSSARY.md, and MONETISATION_FLOWS.md before recommending edits. Preserve Stripe Checkout, webhook idempotency, Resend delivery, Postgres persistence, setup checks, and agent handoff docs unless the user explicitly asks to change them.

Return:

- Positioning rewrite.
- Page and doc edits recommended.
- Implementation checklist.
- Verification plan.

Do not claim the final vertical SaaS is built unless the feature exists in code.

Verify launch

Verify before launch

reusable task

Run a launch-readiness pass before a founder sends traffic to a customised Toolbound product.

A green dev server does not prove checkout, webhooks, email, persistence, discovery files, or production build health.

Inputs

Live domain or preview URL
Expected purchase path
Connected services to check
Any recent public page, sitemap, robots, or llms.txt changes

Safety rules

Do not print secrets or environment values.
Use configured/not configured signals for integrations.
Do not request Google indexing for pages that are noindex, redirected, or non-200.

Output

Setup status
Commercial path status
Discovery file status
Blocking issues and manual follow-up

Verification

npm run setup:check && npm run test && npm run lint && npm run build

one-paste prompt

Give this to your coding agent

You are verifying a buyer-owned Toolbound Stack deployment before launch.

Inputs:

- Live domain or preview URL:
- Expected purchase path:
- Connected services to check:
- Public pages or discovery files changed:

Check setup readiness without printing secrets. Verify the production build path, commercial path, and public discovery files. Confirm robots.txt, sitemap.xml, llms.txt, canonical tags, and noindex state where relevant.

Return:

- Setup status.
- Commercial path status.
- Discovery file status.
- Blocking issues.
- Manual follow-up.

Definition of done: npm run setup:check && npm run test && npm run lint && npm run build passes locally, and live public URLs are 200 where expected.

SEO / GSC

Prepare SEO and GSC changes

reusable task

Add or revise public pages, metadata, schema, canonicals, sitemap entries, robots rules, llms.txt, and Search Console follow-up.

SEO changes are easy to ship half-finished: the page exists, but canonicals, schema, sitemap, internal links, and indexing follow-up do not line up.

Inputs

Target query or page purpose
Canonical URL
Pages changed
Whether the page should be indexable
GSC property, if indexing follow-up is requested

Safety rules

Keep claims factual and supported by current product capability.
Do not use Google's Indexing API for ordinary pages.
Do not request indexing until the live URL is 200, self-canonical, and indexable.

Output

Pages changed
Metadata/schema summary
Sitemap and robots impact
GSC follow-up list

Verification

npm run build, then inspect live 200/canonical/noindex state after deploy

one-paste prompt

Give this to your coding agent

You are preparing an SEO and Google Search Console change for a buyer-owned Toolbound Stack site.

Inputs:

- Target query or page purpose:
- Canonical URL:
- Pages changed:
- Should the page be indexable:
- GSC property, if indexing follow-up is requested:

Keep claims factual and aligned with the current product. Add or update metadata, canonical path, schema, sitemap coverage, internal links, and llms.txt where relevant. Do not use Google's Indexing API for ordinary pages. Do not request indexing until the live URL is 200, self-canonical, and indexable.

Return:

- Pages changed.
- Metadata and schema summary.
- Sitemap and robots impact.
- URLs to inspect or request in Search Console.
- Any quota, canonical, noindex, redirect, or crawl issue.

Publish score

Score before publishing

reusable task

Review a Reddit post, X reply, launch page, comparison page, prompt, or guide before publishing.

Distribution works better when the hook, proof, CTA, risk notes, and audience fit are checked before a founder posts.

Inputs

Audience
Draft asset
Claim being made
Proof available
Desired action after reading

Safety rules

Do not fake testimonials, metrics, or competitor claims.
Do not turn a useful reply into a hard pitch unless the context supports it.
Flag legal, pricing, or guarantee language before publishing.

Output

0-20 score
Publish/no-publish call
Rewrite suggestions
Risk notes

Verification

Publish only at 15 or above; rewrite anything below 12

one-paste prompt

Give this to your coding agent

Score this asset before publishing:

- Audience:
- Draft:
- Claim:
- Proof available:
- Desired action:

Use a 0-20 score:

- Specific buyer pain: 4
- Clear proof: 4
- Agent usability: 4
- Safety: 4
- Distribution hook: 4

Return:

- Score.
- Publish/no-publish call.
- Rewrite suggestions.
- Risk notes.

Publish only at 15 or above. Rewrite anything below 12. Do not fake testimonials, metrics, competitor claims, or guarantees.