Writing great prompts
What you get back tracks what you ask. A strong prompt names the outcome, hands over the context Gentlybot can’t infer, scopes the work, and says how you’ll know it worked.
The anatomy of a strong request
You don’t need every part every time — a quick question needs less than a change that ends in a pull request. But the best prompts tend to carry these four things, in roughly this order.
The outcome
Lead with what you want to be true when the run is done — the behavior, the answer, the artifact — not the implementation. Gentlybot is good at figuring out how; it can’t read your mind about what.
Customers can’t tell when a CSV export finishes. Add an in-app notification when it completes.
The context it can’t infer
Point at the parts of the world Gentlybot can’t see from the code alone: the customer, the flow, the ticket, the error text, a screenshot, the file you already suspect. Every pointer you give saves a round of searching and sharpens the result.
This is the Reports page (app/pages/reports.vue). Exports run in the worker — see the Slack thread in #support from Acme.
The definition of done
Say how the result should be judged. For a question, what decision are you trying to make? For a change, what should you be able to do afterward — and should Gentlybot prove it in the browser?
Show me the toast firing in the sandbox after a real export completes.
The guardrails
Name what’s out of scope or must not change. Constraints make a run more focused, not less capable — they stop it from wandering into surface area you didn’t mean to touch.
Don’t touch the export logic itself — just surface the completion. Keep it to the web app.
Before and after
The weak prompts aren’t wrong — Gentlybot will do something reasonable with them. The strong ones just get you to the right result in one pass instead of three.
How does auth work?
I’m scoping SSO for a prospect. Walk me through how a user session is created and validated today — where the session is issued, how it’s checked on API calls, and where SAML/OIDC would plug in. Cite the files.
The strong version says why you’re asking (a decision about SSO), which lets Gentlybot answer at the right altitude and flag what’s missing for the thing you actually care about — instead of a generic tour.
The export is broken, can you fix it?
Acme reports their usage export downloads an empty CSV (screenshot attached, ticket SUP-482). Reproduce it in a sandbox, tell me whether it’s a bug or a config issue on their account, and if it’s a bug, open a PR with a test that covers it.
Names the symptom, the evidence, and what a good ending looks like. Gentlybot can reproduce before it theorizes, and you get a bug-or-expected answer plus a fix — not a guess.
Add dark mode.
Add a dark theme toggle to the top nav that persists per user. Follow the existing theme tokens in app/assets/css/main.css — don’t introduce new colors. Verify the dashboard and settings pages look right in both modes and record it.
Scopes the change (nav toggle, per-user), reuses existing patterns instead of inventing, and defines proof. “Add dark mode” could mean a week of work across every screen; this is one reviewable PR.
Can we do scheduled reports?
A customer wants reports emailed on a weekly schedule. Before any code — is this feasible on our current stack? What would it touch (worker, email provider, DB), what are the risks, and roughly how big is it? Draft a plan I can share with engineering.
Asks for a plan, not a build. You get scope, risks, and affected surfaces you can circulate for a decision — cheap to produce and easy to say no to.
Hand over the context it can’t guess
Gentlybot reads your code, and — when connected — your PRs, tickets, Slack, and docs. But it starts a run cold. The single highest-leverage thing you can do is point it at what you already know, so it spends its time solving instead of searching.
- File paths or symbols you already suspect (app/pages/reports.vue, useExports).
- A PR or commit — “like we did in #312” — so Gentlybot follows the established pattern.
- A screenshot or recording of the bug, pasted straight into the thread (or dropped in Slack).
- The actual error text and a stack trace, verbatim — far more useful than “it crashes”.
- A Jira issue or Slack thread for the customer context, the account, and the history.
- A Notion page or docs repo for the intended behavior when the code alone is ambiguous.
Habits that compound
One change per thread
A thread that does one thing produces one clean, reviewable PR. Bundling “add the toast and also refactor the worker and fix that other bug” gives you a diff nobody wants to review. Start a second thread instead.
Narrow beats broad
A tightly scoped request finishes faster, verifies more thoroughly, and is easier to trust. Grow the scope across follow-ups once you’ve seen it work, rather than asking for everything up front.
Refine, don’t restart
The thread keeps its context. If the first pass isn’t right, reply with a correction — “that’s the admin export, I mean the customer one” — instead of opening a fresh thread and re-explaining from scratch.
Ask for the proof you need
If seeing it matters, say so: “record the flow,” “show me both light and dark,” “screenshot the empty state.” Verification runs against your real app in a sandbox, so the evidence is real.
Then pick how far it should go
A great prompt still runs in a mode — whether Gentlybot only answers, drafts a plan for you to approve, or goes all the way to a pull request. Choosing the right one is the other half of getting great results.
Choosing a mode