How to Write Custom Instructions That Stay Useful

Custom instructions are best used for stable preferences that should apply across many conversations. They are a poor place for today's deadline, a temporary client brief, or a long collection of exceptions. The goal is not to pre-prompt every possible task; it is to reduce predictable corrections while leaving room for specific requests.

Decide What Belongs There

Useful durable instructions include:

• your role and normal audience;
• preferred units, spelling, and date format;
• recurring terminology;
• a default level of explanation;
• evidence and uncertainty rules;
• accessibility or formatting needs;
• a short list of boundaries.

Task-specific facts belong in the current prompt. Project-specific policy belongs in that project's instructions. Confidential information, credentials, and personal data should not be added merely for convenience.

Write Observable Rules

“Be professional” is subjective. Replace it with instructions that can be checked:

Write for technically informed business readers.
Lead with the decision or outcome.
Define specialized terms the first time they appear.
Use US English and ISO dates.
For current product claims, prefer first-party sources and include direct links.
Separate documented facts from inference.
If essential context is missing, state the assumption before proceeding.

Avoid trying to control every sentence. Excessive formatting commands can make simple answers cumbersome and conflict with tasks that need a different structure.

Organize by Priority

Use a compact hierarchy:

1. safety, privacy, and evidence requirements;
2. audience and decision context;
3. language and formatting preferences;
4. optional style choices.

State how exceptions work: “Follow the current task when it explicitly requests a different format.” Without that rule, a permanent preference for short answers may undermine a later request for a detailed report.

Add Conditional Instructions

Some rules should apply only to certain work:

When reviewing code, report a concrete failure scenario and verification step
for each finding. When summarizing research, preserve dates, units, and source
qualifiers. When brainstorming, label speculative ideas and do not present
them as existing features.

Keep the conditions broad and few. If the instruction file resembles a complex decision engine, separate the workflow into dedicated project templates.

Test With a Small Evaluation Set

Create five representative prompts: a quick factual question, a writing task, an analytical comparison, a task with missing context, and a request whose explicit format conflicts with the default. Save acceptable outputs or a scoring rubric.

Evaluate:

• instruction adherence;
• factual discipline;
• usefulness for the intended audience;
• unnecessary verbosity or formatting;
• correct handling of task-specific exceptions.

Change one instruction at a time and rerun the set. This makes it possible to identify which wording improved or degraded behavior.

Diagnose Common Failures

If an instruction is ignored, shorten it, move it higher, or make it observable. If every answer repeats disclaimers, limit the uncertainty rule to material claims. If responses sound generic, add audience and decision context rather than a long list of adjectives. If instructions conflict, remove the less important rule instead of adding another exception.

Review instructions monthly or after a major role or workflow change. Delete rules you routinely override. An instruction that no longer reflects your work adds hidden friction to every conversation.

A Complete Example

I manage a small software product and write for engineering and operations
leaders. I value specific recommendations supported by current evidence.

Default response behavior:
- lead with the practical outcome;
- use concise US English and explain uncommon terms;
- distinguish facts, assumptions, and recommendations;
- cite primary sources for current or consequential claims;
- do not invent quotations, data, or product capabilities;
- mention material limitations and a verification step;
- follow an explicit task format when it differs from these defaults.

For decisions, compare trade-offs and state what would change the recommendation.
For code, preserve existing conventions and propose tests for behavior changes.

This example is short enough to maintain and specific enough to test.

Treat Instructions as Configuration

Version important instruction sets outside the chat product, especially for a team. Record why a rule exists and who owns it. Do not assume identical behavior across models or product updates; rerun the evaluation set when the environment changes.

Custom instructions work when they remove repetitive setup without hiding critical assumptions. A small, tested set of durable rules will outperform a large prompt that attempts to anticipate every future conversation.