Typing Your Requests
Prompting patterns that get great results
The quality of what Nexgile Code produces tracks the quality of what you ask for — not because the agent needs ceremony, but because it plans from your words. A request that names the goal, the constraints, and what “done” looks like produces a tight todo list and few surprises. This page gives you the patterns that consistently work.
Anatomy of an effective request
Section titled “Anatomy of an effective request”Three ingredients, one or two sentences each:
- Goal — the outcome, not the method: what should be true when this is done?
- Constraints — what to use, what to avoid, where to work: libraries, patterns, files in scope.
- Acceptance signal — how the agent (and you) will know it worked: a test that passes, a command that succeeds, a behavior to demonstrate.
Add rate limiting to the login endpoint in @/src/routes/auth.ts.Use the existing middleware pattern from @/src/middleware/ — don't addnew dependencies. Done means: 5 attempts per minute per IP returns 429,and `npm test` still passes.The agent turns that directly into work items: implement the middleware, wire the route, verify with the test run. Notice the @ mentions — attaching the files you’re talking about removes a whole round of discovery.
Good vs. vague, side by side
Section titled “Good vs. vague, side by side”| Vague | Effective |
|---|---|
| “Fix the login bug” | “Login fails with ‘invalid token’ after password reset. Start from @problems and the failing test in @/tests/auth.spec.ts. Done when that test passes.” |
| “Make the app faster” | “Profile @/src/api/search.ts and cut the p95 of the search endpoint. Don’t change the public API. Show me before/after timings from the benchmark script.” |
| “Add tests” | “Add unit tests for @/src/utils/dates.ts covering timezone edge cases and invalid input. Use Vitest like the rest of the repo. Target the untested exported functions first.” |
| “Clean up this file” | “In @/src/services/order.ts only: extract the three duplicated total-calculation blocks into one helper. No behavior changes — existing tests must pass unchanged.” |
| “Write docs” | “Write a README section explaining how to run the project locally: prerequisites, env vars from @/.env.example, and the exact commands. Keep it under 60 lines.” |
The pattern in every effective version: a concrete anchor (file, error, test), an explicit boundary, and a checkable finish line.
Scope it explicitly
Section titled “Scope it explicitly”The agent honors scoping language, and it’s the cheapest guardrail you have:
- “Only touch
src/parser/— do not modify the public API inindex.ts.” - “Change the minimum needed to fix this; no drive-by refactoring.”
- “Read anything you like, but propose edits only for the files I mentioned.”
For boundaries that should apply to every task — naming conventions, forbidden directories, required test commands — put them in a rules file instead of retyping them. .nexgilerules is injected into every prompt, so conventions stated there don’t depend on your memory. Files the agent should never even see belong in .nexgileignore.
Iterate with follow-ups — don’t restart
Section titled “Iterate with follow-ups — don’t restart”A task is a conversation. When the first result is 80% right, say what’s wrong in the same chat and let the agent continue with full context:
- “Good, but the error message should name the field that failed validation.”
- “Revert the change to
config.ts— that part was fine as it was.”
You have three natural feedback points: replying after completion, attaching feedback while approving a tool call (“approve, but rename it parseDate”), and attaching feedback while denying one (“no — use the existing helper instead”). Rejection with a reason is steering, not failure; the agent re-plans from your words. Start a fresh task only when you’re changing subject — long chats accumulate context you pay for, as explained in Context Management.
For big work, plan before you build
Section titled “For big work, plan before you build”Anything spanning several files deserves the Architect-first pattern: describe the goal in 🏗️ Architect mode (the default), refine the plan it proposes — plans are cheap to edit — then approve the switch to 💻 Code for implementation. The full pattern is covered in Using Modes. For work with an unknown cause rather than an unknown design, start in 🪲 Debug instead and bring evidence: @problems, @terminal, the failing commit hash.
The Enhance Prompt button
Section titled “The Enhance Prompt button”The wand icon (✦) at the bottom of the chat box sends your draft to the model to be rewritten — expanded with context, clarified, and rephrased — and puts the result back in the input box for you to review and edit before sending. It’s useful when you know what you want but the phrasing is thin. Two notes:
- Type your draft first, then click the wand; the enhanced text replaces your draft in place.
- By default enhancement uses your current API profile, but you can pin a dedicated (cheaper) one in Settings → Prompts, where the enhancement template itself can also be customized.
Treat it as a drafting aid, not an oracle: you remain the author of what gets sent.
Images and URLs
Section titled “Images and URLs”- Images: paste from the clipboard or drag-and-drop onto the chat box (PNG, JPEG, WebP), or use the image button — available whenever the selected model supports image input. Screenshots of broken UI, design mockups, and error dialogs are all fair game; the agent sees them alongside your text. If the button is disabled, the current model doesn’t accept images — check model behavior.
- URLs: pasting a URL inserts it into your message, and any
scheme://address is recognized as a mention. The agent receives the exact address as part of your request.
The 20-second pre-send checklist
Section titled “The 20-second pre-send checklist”Before you hit send on anything non-trivial:
- Right mode? Planning → Architect. Known change → Code. Unknown cause → Debug. Question → Ask.
- Goal stated as an outcome? Someone else could read it and know when to stop.
- Files attached? Every file you already know matters is an
@mention. - Boundaries drawn? What must not change is written down.
- Finish line checkable? A test, a command, or a demonstrable behavior — not “make it better”.
Skipping the checklist doesn’t break anything; it just moves the same clarification work later into the task, where it costs tool calls and approvals instead of one sentence now.