Home / Choosing your model and your tool

Composing a system prompt across several providers

When a prompt has to work across several providers, take each one's strongest rule, merge them without contradiction, and rules written by the prompt's owner generally outrank a provider's defaults, except when they would conflict with the safety limits that provider sets for itself.

A prompt meant to run on Claude and on another provider is never copied as it stands from one to the other. Each provider writes a different default system prompt, with its own priorities and its own safety reflexes, and a rule lifted word for word from one provider can conflict with what the other has already built in. The method that works is to take the strongest rule from each source, rewrite it for the real context of the task, then check that nothing contradicts itself before adopting the result.

Composing without copying

The lesson on composing a system prompt from several sources already sets the base rule: an imported rule is rewritten for its own context, it is never pasted as it stands. Between two providers, this rule counts double, because a default system prompt also carries the style and reflexes specific to its provider of origin, not just a neutral instruction. A role placed at the top of the prompt helps this merge, including on Claude: even a single sentence of role already changes the tone and behaviour obtained, according to the official documentation on prompt writing.

Who decides in case of conflict

What remains is the question of arbitration: when two merged rules contradict each other, which one wins. Anthropic's public constitution describes an order of priority among the people who give instructions to Claude, and rules written by the prompt's owner generally count more there than the provider's default settings. The same text notes, however, that this order is not a strict hierarchy: a rule from the owner that redefines the tone, format or vocabulary is entitled to win, but a rule that asked a provider to ignore its own safety limits does not have that right, whichever provider is concerned.

Testing before adopting

A merged prompt is tested on a real task before being adopted, exactly like a simple prompt. A short example sets the method.

You are a senior IT technician working for a cooperative.
Rule from provider A, kept: give the reason before the instruction.
Rule from provider B, kept: cite sources inline, never at the end of the answer.
Rule from the owner, placed last: never use undefined technical jargon.

This short prompt keeps one rule from each provider, reworded in a single style, and places the owner's rule last, which makes it visually take priority. The test consists of running it once on a real task from the job, then comparing the answer obtained against the two original prompts before considering it finished.