The bottleneck for adding features to a product used to be typing. It isn’t anymore. An AI coding agent will scaffold a search box, wire up a webhook, or draft a settings page faster than you can open the right file. The bottleneck now is knowing what to ask for, and shipping the result without turning a good afternoon into a bad on-call week.

This is a prompt library for the first part. It’s a collection of prompts that produce genuinely useful features, each written to give the agent enough context to do the job well instead of confidently doing the wrong thing. At the end there’s a short section on the second part, because a feature that ships badly is worse than one you never built.

A note on how to use these: replace the bracketed parts with your actual stack, paste the relevant files or a description of them, and always ask for a plan before code on anything non-trivial. The prompts below assume you’ll do that.

1. Add dark mode

Add a dark mode toggle to my [React + Tailwind] app. Requirements: respect the user’s OS preference on first load via prefers-color-scheme, persist their explicit choice to localStorage, and expose the current theme through a context so any component can read it. Don’t hardcode colors in components, define semantic CSS variables (--bg, --text-muted, etc.) and switch them at the :root level. Show me the token list before you touch any components.

The “show me the token list first” line matters. Dark mode goes wrong when an agent recolors 40 components individually instead of centralizing the palette. Force the abstraction up front.

2. Add full-text search

I want to add search to my app over [posts and comments]. Walk me through two options first: (a) a database LIKE/ilike query, (b) a proper full-text index. Tell me which one fits [Postgres, ~50k rows, needs typo tolerance] and why. Then implement the recommended one, including a debounced search input, a results component, and an empty state. Keep the query server-side, no client-side filtering of a full dataset.

Ask for the trade-off analysis before the code. Search is the classic case where the naive implementation works in the demo and falls over at real scale.

3. Add in-app notifications

Add an in-app notification system. I need: a notifications table (id, user_id, type, payload JSON, read_at, created_at), an API to list and mark-as-read, a bell icon with an unread count in the header, and a dropdown panel. Use optimistic updates so marking-as-read feels instant. Don’t build email or push yet, just the in-app inbox. Propose the schema and API shape before implementing.

Scoping the agent out of email and push here is deliberate. Left unbounded, it will build three delivery channels when you asked for one.

4. Add a public API with keys

Add API key authentication so customers can call our API programmatically. I need: key generation (show once, store only a SHA-256 hash), a middleware that validates the key and attaches the owning account to the request, per-key rate limiting, and a settings page to create and revoke keys. Never log or return the raw key after creation. Show me the security-sensitive parts, hashing and validation, first so I can review them before the UI.

5. Add webhooks (outbound)

Add outbound webhooks so customers get notified when [an order ships]. Requirements: a subscriptions table, HMAC-SHA256 signatures on every payload with a per-subscription secret, delivery via a background queue (not inline in the request), and retry with exponential backoff on non-2xx responses. Include a signature-verification snippet I can paste into our docs. Design the retry and signing scheme before writing the delivery worker.

6. Add an onboarding checklist

Add a first-run onboarding checklist for new users. Steps: [create a project, invite a teammate, connect an integration]. Requirements: derive completion state from real data (did they actually invite someone?) rather than a manual “mark done” flag, show progress as “2 of 4”, and let the user dismiss it permanently. Store dismissal per-user. Suggest where in the layout it should live before building it.

Deriving state from real signals instead of a checkbox is what separates an onboarding checklist that stays accurate from one that lies to users on day two.

7. Add CSV import

Add CSV import for [contacts]. Requirements: drag-and-drop upload, a column-mapping step (their headers to our fields), row-level validation with a preview of the first 10 rows, and a summary of “X imported, Y skipped” with downloadable errors. Stream large files rather than loading the whole thing into memory. Show me the validation and mapping logic before the UI.

8. Add role-based permissions

Add role-based access control with roles [owner, admin, member, viewer]. I want a single source of truth: a permissions matrix mapping roles to actions, one can(user, action, resource) helper used everywhere, and both API-side enforcement and UI hiding of disallowed actions. Don’t scatter role checks through the codebase. Show me the matrix and the helper signature first.

9. Add audit logging

Add an audit log that records who did what. Capture [create/update/delete on billing, members, and API keys]: actor, action, target, before/after diff, timestamp, IP. Write logs from a single choke point rather than sprinkling calls everywhere. Add a filterable admin view. Propose where the single write point should live given my current architecture.

10. Add a comment system

Add threaded comments to [documents]. Requirements: one level of nesting (replies, not infinite threads), @-mentions that notify the mentioned user, edit and soft-delete, and markdown rendering that’s sanitized against XSS. Render optimistically on post. Show me the sanitization approach explicitly, that’s the part I most want to review.

11. Add data export (GDPR-friendly)

Add a “download my data” feature. Generate a ZIP containing the user’s [profile, projects, and activity] as JSON, produce it in a background job, and email a time-limited download link when ready. Don’t block the request on generation. Make it easy to add new data types to the export later. Sketch the job flow before implementing.

12. Add a settings page that scales

Refactor our scattered settings into one coherent settings area with sections [profile, notifications, security, billing]. I want a layout that makes adding a new section trivial, form state that warns on unsaved changes before navigating away, and per-section save (not one giant form). Propose the structure and the “add a new section” pattern before building any single section.

The part the prompts don’t cover: shipping it

Every prompt above produces a feature. None of them, on their own, tells you how to release that feature to real users safely. That’s a separate discipline, and it’s the one that decides whether “I added a cool thing this afternoon” ends well.

The pattern that works, regardless of how the code got written:

  1. Merge it turned off. Put the new feature behind a flag so the code can ship to production while staying invisible. Deploying and releasing become two separate decisions instead of one scary event.
  2. Turn it on for yourself first, then your team, then 1% of users, then 10%, then everyone, watching error rates and latency at each step.
  3. Keep a kill switch. If the new search feature starts hammering your database, you want to disable it in seconds by flipping a flag, not by reverting a commit, rebuilding, and redeploying while users watch spinners.

You can bolt this on to any of the twelve features above with one more prompt:

Wrap this feature in a feature flag check so it’s off by default and can be enabled per-user or for a percentage of traffic. Read the flag from [our flag provider / an environment variable for now] and fall back to “off” if the lookup fails. Make the flag name and default obvious.

That single habit, merge dark, roll out gradually, keep a kill switch, is what lets you use AI to add features at speed without the corresponding increase in incidents. The agent makes building cheap. Controlled rollout makes shipping safe. You want both.

ShipSilently gives you feature flags that evaluate in under a millisecond at the edge, so gating a new feature never slows down the request. Start free and ship your next feature dark.