Standing Brief Custom Gpt Claude Projects Gemini Gems

A standing brief is the one page you wish every new chat already knew: who you serve, what "done" looks like, words you use, words you never use, and the artifacts the model is allowed to touch. In 2026 you can store that brief in Custom GPT instructions, Claude Projects, Gemini Gems, or a system prompt. The product names change. The job does not.

If you paste a new manifesto into every thread, you will drift. If you hide the brief inside a long knowledge dump, the model will ignore the parts that matter. Put a short, portable card in the slot each product actually reads first.

Matching standing-brief prompts are landing in the PromptDig library (Browse more prompts). Steal the card below, then park it where you actually work.

Write the brief once, as a card

Keep it under a page. If a new teammate could not use it on day one, it is too cute.

A standing brief that actually ports:

• Who we are, and who we are not for
• Jobs we do this quarter
• Voice: words we use, words we never use
• Artifacts we produce, and the ones we do not
• Facts the model may cite (only ones that exist)
• Hard stops: legal, brand, and data it must not invent

Then one line that saves you later: "If an input is missing, ask. Do not fill gaps with plausible numbers."

A skeleton you can paste into any of the four slots:

You are working for [team] on [product or practice].
Audience: [who]. Not for: [who].
Voice: [three traits]. Never: [words, jokes, claims].
Artifacts: [list]. Do not produce: [list].
Facts you may use: [paste only verified items].
If a number, quote, or policy is not in this brief or the user message, write TODO and ask.

That block is the product. Park it so you stop retyping it.

Custom GPT instructions: the public-facing slot

Custom GPTs have an Instructions field and a Knowledge upload. Put the standing brief in Instructions, not in a PDF. Instructions are what the model is told to treat as policy. Uploaded files are reference. If your voice rules live only in a PDF, they will lose to whatever the user types.

Keep Knowledge for examples: one good email, one good brief, one banned draft. Label them. "Example: weekly update. Match this density." Do not upload your entire wiki.

If the GPT is shared, assume a stranger will open it. Strip client names. Put secrets in the conversation, not in the instructions.

Conversation starters should name jobs ("Draft the weekly update from these bullets"), not vibes ("Help me write"). The brief already has the vibe.

Claude Projects: instructions plus a small library

Claude Projects give you project instructions and a file set that persist across chats. Use project instructions for the standing brief. Use files for source-of-truth docs the model should quote: a style sheet, a product card, a policy.

Cap the file set. Five current docs beat fifty stale ones. When a doc changes, replace the file. Models will happily cite last quarter's pricing if you leave it in the project.

Start a new chat inside the project for each job. Do not treat the project as one endless thread. The instructions stay. The conversation should not.

If you use Claude's memory or recents, do not let them compete with the brief. The brief is the policy. Memory is a convenience. When they conflict, the brief wins, and you should say so in the project instructions.

Gemini Gems: same card, shorter sentences

Gems are instruction packages. Gemini tends to follow short, imperative lines more reliably than a narrative manifesto. Convert the standing brief into a checklist:

• Always...
• Never...
• When the user asks for X, produce Y in this shape
• Ask before assuming Z

If you also attach Drive files, treat those files like Claude's project uploads: current, few, labeled. The Gem instructions still win over a buried paragraph in a Doc.

Gems are easy to duplicate. That is a feature until you edit one copy and forget the other. Name Gems by job plus date, not by model nickname.

System prompts: the API and app version

If you are calling a model from an app, the standing brief belongs in the system (or developer) prompt, versioned in git next to the code. Do not hide it in a user-message prefix that a client can overwrite.

Keep it identical in spirit to the GPT, Project, and Gem version. Fork only the control surface:

• Custom GPT: instructions plus a couple of files
• Claude Project: project instructions plus pinned docs
• Gem: short imperative list plus optional Drive files
• System prompt: the same card, plus tool and output-schema rules the chat products do not have

When you change a voice rule, change it in all four places the same day. Drift between tools is how a "we never invent stats" policy survives in Claude and dies in the GPT.

Keep one source, copy into slots

Store the canonical brief next to the prompts you actually run. Browse the library on PromptDig (Browse more prompts) for the matching standing-brief cards as they land, then share (Share a prompt) the version your team uses with the slot name in the title. A Gem checklist pasted into a system prompt will look like it "does nothing" because the schema section has nowhere to go.

Review the brief when a name changes, when legal sends a new stop list, or when a new person joins and gets a weird first draft. Weird first drafts are a brief bug, not a model bug.

The standing brief is not a second brain. It is the one page that makes every later prompt shorter. Write it once. Put it in the slot the product actually reads. Then stop re-explaining yourself.