Standing Instructions
Standing instructions let you give the AI a persistent set of rules or context that apply to every chat turn in your project — without repeating yourself each time.
What they're for
Standing instructions are ideal for things that are always true about your project:
- App-wide constraints — "Never let the user delete records — archive them instead."
- Style preferences — "Always use Tailwind CSS. Never use inline styles."
- Data rules — "All dates are in UTC. Always display them in America/Denver local time."
- Access logic — "Only users with the 'manager' role should see the Approvals tab."
- Naming conventions — "Facilities are called 'stations' in this app, not 'warehouses'."
Without standing instructions, you'd have to re-state these rules in every message — or correct the AI each time it forgets.
How to set them
Open the Project Settings panel (gear icon in the top-right of the IDE), then enter your instructions in the Standing Instructions field. Click Save.
They take effect on the next chat turn — no deploy required.
There's a 2,000 character limit. A character counter shows how much space you've used.
How they work
Standing instructions are injected into every chat request as a persistent system prompt, in addition to the platform's built-in instructions and your project's code context. The AI reads them before every turn.
This means they apply automatically — you don't need to mention them in your messages.
Tips for writing good instructions
Be specific and concrete. Vague instructions like "keep it clean" don't do much. Specific ones do:
- "Every button that writes data must show a confirmation dialog."
- "Use
console.error()with a descriptive message for every catch block."
Write rules, not preferences. The AI takes these as firm constraints, not suggestions:
- "Always validate that driver IDs are non-empty strings before using them in queries."
- "Every API handler must return JSON, never plain text."
Describe your domain. The AI doesn't know your business:
- "A 'leg' is a single stop on a route. A 'route' contains multiple legs."
- "Active means status = 'active'. Do not filter by any other field."
Don't repeat what's already in the code. If the convention is clear from the existing files, the AI will pick it up. Standing instructions are for things the code alone doesn't communicate — intent, edge cases, business rules, and team preferences.
What to leave out
Standing instructions are for project-level context, not request-level detail. Avoid:
- Step-by-step implementation plans (just say what you want in chat)
- Temporary instructions that only apply to one feature (say them in that message)
- Redundant rules already enforced by the code structure
Instructions that are too long, too detailed, or irrelevant to most turns will dilute the signal. Keep them focused on things that apply broadly and would genuinely change the AI's behavior.
Example: a solid set of instructions
This is a driver ops tool. Users are dispatchers and managers — not engineers.
Rules:
- Never expose raw UUIDs in the UI. Always display human-readable labels.
- All monetary values are in USD cents. Display them as dollars with 2 decimal places.
- Drivers are referenced by "driver_id", never "user_id".
- "Active" routes have status="active" AND start_time <= now < end_time.
- Deleting is not allowed. Use soft deletes: set deleted_at = now().
- The app uses Tailwind only. Never add inline styles or a <style> block.This gives the AI the domain context and hard constraints it needs to make the right calls without being asked each time.
Updating instructions
You can edit standing instructions at any time. Changes apply immediately to the next turn — no redeploy needed. You can also clear them entirely to remove all persistent context.
If a standing instruction is causing unexpected behavior, try removing it to see if the problem goes away.
Questions
Reach out in #eng_product_platform_team if you're not sure what to include.