How to Add a Claude Style From Instructions and Examples

A writing style for Claude is not a setting the model stores: it is a set of instructions and examples you provide at the start of a session or save in a project. Getting it to hold consistently means writing it precisely, testing it on real inputs, and saving the version that works.

Tools like fenbs let you keep the approved style instructions alongside the lessons from refining them, so any connected assistant reads the current version rather than a first draft.

What a style instruction is

A style instruction tells Claude how to shape its output: the reading level, sentence length, tone, vocabulary choices, and anything else that distinguishes your voice from a generic answer. It is a written brief, not a preference the model infers from your history.

Claude has a built-in Styles feature for setting a voice in the product interface. If you want a style that works across Claude, Claude Code, or other AI apps, a written instruction that you control and save yourself is more portable. For background on how Claude styles work in the product, the post on claude styles explained covers the built-in feature. The built-in feature and a written instruction can work together: the built-in feature for quick sessions, the written instruction for work that spans multiple apps or team members.

How to write a style instruction

Start with the three or four things that matter most about your voice. Trying to capture everything at once produces instructions that are too long to maintain and too vague to test.

• Sentence length: short and direct, or longer and elaborated.
• Vocabulary level: plain language a non-specialist understands, or technical terms the audience already knows.
• Tone: formal, conversational, neutral.
• What to avoid: jargon, filler phrases, hedges, passive voice, or specific overused words.

Write each point as a short instruction rather than a description. "Keep sentences under twenty words" is testable. "Write in a clear and engaging way" is not.

Adding examples that anchor the style

Examples communicate a style faster than a list of rules. Take one paragraph written in the voice you want and add it to the instruction with the label "Write in this style:". A before-and-after pair is even more useful: the before shows what to avoid, the after shows the standard.

Keep examples short, around fifty to one hundred words. Longer examples shift the attention from the style pattern to the topic. The model needs to learn the voice, not the subject matter.

You can use a short passage from your own past writing or a hypothetical example you draft to match the voice. Either works as long as it represents the style consistently, not just for that one topic.

Testing whether the style holds

A style instruction is only useful if it produces the right output on inputs you did not write it for. Test it on at least three different real tasks before treating it as done.

1. Open a fresh session and paste or load the style instruction.
2. Give Claude a real writing task: a draft email, a paragraph to revise, a short explanation.
3. Check the output against the rules in your instruction. Does it match on every point?
4. For any rule that was missed, rewrite that rule more specifically or add an example that shows the failure case corrected.
5. Repeat with two more different inputs before finalizing.

If the style instruction produces good output for direct tasks but breaks on revisions or rewrites, add a separate example that shows revision in the right voice. Drafting and revising often need slightly different guidance.

For style applied to code comments or technical output, claude code output styles covers how Claude Code handles formatting and output style instructions separately from prose.

How to do this with fenbs

1. Create a free account and add a project for the work that uses this style.
2. Add the style instruction and examples to Skills and prompts in fenbs with a name like "Brand voice" or "Report style".
3. Record the test results in Lessons learned: what broke the first version and what fixed it.
4. Connect your AI apps over MCP from Integrations so they can read the current approved style instruction before each session.

When a style instruction needs replacing

Replace the instruction when the voice you want has genuinely changed, not just when one output was off. A single bad output usually means an input that the instruction did not cover: add an example for that case.

When replacing, keep the old version until the new one passes the same set of test inputs. That comparison shows what the earlier version was quietly getting right that you might not have written down.

A style instruction that works for one project may need adjustment for a different audience or format. Save the working version before adapting it. A report style and a client email style often share most of their rules but differ on sentence length and assumed vocabulary. Start from the closest existing version rather than from scratch: the shared rules are already tested and do not need to be rewritten.