Set Project Instructions for a Consistent Voice
What it is
Using per-Project instructions to set the voice, format, and rules for one body of work — so every chat in that Project follows them, without those rules leaking into unrelated work.
Why it works
Global custom instructions are too blunt when you juggle several contexts — one client's playful tone shouldn't touch another's formal one. Project instructions scope the rules to where they belong, so each Project stays internally consistent and your global defaults stay clean.
When to use it
When a Project has its own voice or constraints distinct from your defaults — a specific client, a publication with a house style, a codebase with conventions.
When not to use it
For rules that genuinely apply everywhere (your general tone, answer length) — those belong in global custom instructions, not repeated per Project.
Prompt
[In a Project's instructions] For all chats in this Project: voice is <tone>, format answers as <structure>, always <key rules>, never <anti-patterns>. These override my global defaults where they conflict.Example
A 'Acme Client' Project set to 'formal, British English, cite the policy number' keeps every draft consistent, while your 'Personal Blog' Project stays casual.
Common mistakes
- Forcing project-specific voice into global instructions and skewing everything.
- Leaving Project instructions blank and re-specifying tone in each chat.
- Contradicting global defaults without saying which should win.