# Editing & Adapting Outputs for the Intended Audience > A first Claude draft is rarely the version you hand to its actual reader. Adapting output for audience runs on two concrete mechanisms: few-shot before/after examples of the target register, and persistent configuration, account instructions, project instructions, or Skills, for audiences you'll hit again. "Just ask Claude to be more casual" skips both. **Domain:** CCAOF-D2 · Output Evaluation & Validation (21% of the exam) **Canonical:** https://claudearchitectcertification.com/concepts/adapting-outputs-for-audience **Last reviewed:** 2026-05-04 ## Quick stats - **Adaptation levers:** 2 (few-shot examples + persistent config) - **Exam domain:** CCAOF-D2 - **Domain weight:** 21% - **Configuration layers:** 3 (account, project, Skills) - **Refinement loop stages:** 4 (draft, check, adjust, re-check) ## What it is A first Claude draft is rarely the version you hand to its actual reader. This objective is about the deliberate step of re-shaping an output, tone, vocabulary, length, and format together, to fit who will consume it: an executive, a customer, a technical peer, a regulator. Anthropic frames this less as one clever prompt and more as an iterative loop: draft, check against success criteria, adjust, re-check. Audience-targeting is a named benefit of prompting, not an afterthought. Anthropic's own business-performance guidance lists it as a core payoff: "prompt engineering helps customers deliver targeted experiences for their desired audiences and industries... you can cater to very specific personas and their needs." The exam objective covers four related actions on the same output, edit, adapt, refine, and compare, adjusting a draft and then checking it against an alternative version before deciding which one ships. ## How it works Lever one: few-shot before/after examples. Anthropic's "6 Techniques for Effective Prompt Engineering" reference demonstrates audience-adaptation directly, converting "the platform implements end-to-end encryption protocols to safeguard data integrity" into plain language by first giving Claude two worked before/after examples of jargon-to-plain-language conversion. "Providing examples helps the AI understand the pattern, style, or format you're looking for more clearly than descriptions alone." This is the right lever for a one-off or first-time adaptation to a specific audience. Lever two: persistent configuration for recurring audiences. Claude's personalization features, account-wide "Instructions for Claude," project-level instructions, and Skills (the current name, migrating from the earlier "Styles" branding), exist specifically so tone and format for a given audience or workflow persist without re-explaining them every turn. Skills are described as letting a user "adjust the tone and format of Claude's responses" and "apply communication patterns based on your own writing or preferences." This is the right lever once you'll hit the same audience or workflow repeatedly, not a one-off request re-typed each time. Refinement is scoped to controllable success criteria. Anthropic's prompt-engineering overview frames editing as testing a draft against explicit success criteria and adjusting from there, not vague "make it better" iteration. "Does this land for an engineer who needs the root cause?" is a testable criterion; "does this sound better?" is not. Compare before shipping either version. When one source needs to reach two audiences, the pattern is running two separate adaptation passes, not writing one version that tries to split the difference. Each pass gets its own audience framing and its own few-shot reference, and the two outputs are compared side by side before either goes out, rather than assuming a single "balanced" draft serves both readers. ## Where you'll see it in production ### Incident postmortem for two audiences Runs two adaptation passes on the same source content, one framed for engineering leadership with root-cause detail, one framed for customers in plain language, then compares both before sending either. ### Recurring customer-support tone Sets the desired tone once via project instructions or a Skill instead of re-typing a tone request in every new support ticket. ## Comparison | Mechanism | When to use it | What it actually does | | --- | --- | --- | | Few-shot before/after examples | One-off or first-time adaptation for a specific audience | Shows Claude the target register directly (e.g. a jargon sentence rewritten in plain language) rather than describing it abstractly | | Persistent configuration (account instructions, project instructions, Skills) | A recurring audience or workflow you'll hit again | Tone and format persist without re-explaining every turn; Skills can apply communication patterns learned from your own writing | ## Exam-pattern questions ### Q1. A PM needs to simplify a technical incident postmortem for a customer-facing status page, and this is the first time this audience adaptation has come up. What's the better move? Give Claude one or two concrete before/after examples of jargon-to-plain-language conversion, the few-shot lever, rather than a vague instruction. The distractor "just tell Claude to 'make it simpler' and trust it to guess the right register" skips the example-driven mechanism the exam objective tests. ### Q2. A support team needs the same customer-facing tone applied across dozens of tickets every week. What's the better setup? Persistent configuration, account or project instructions, or a Skill, so the tone and format persist without re-explaining them on every ticket. The distractor "re-explain the desired tone in the prompt for every new ticket to stay flexible" ignores the configuration lever meant exactly for recurring audiences. ### Q3. A PM needs one incident summary to reach both engineering leadership (needs root-cause detail) and a customer status page (needs plain language, no internal system names). What's the recommended approach? Run two separate adaptation passes, each with its own audience framing and few-shot reference, then compare both outputs before sending either. The distractor "write one balanced version that tries to satisfy both audiences at once" skips the compare step and risks under-serving both readers. ### Q4. What is the current Claude personalization feature that lets a user apply communication patterns from their own writing automatically? Skills, the current name for this feature, migrating from the earlier "Styles" branding, described as letting Claude "adjust the tone and format" and "apply communication patterns based on your own writing or preferences." The distractor "Styles and Skills are two separate, unrelated Claude features that must both be configured for personalization to work" misreads a naming migration as two distinct systems. ### Q5. A reviewer edits a Claude draft and decides it's done because "this version reads better than the last one." What's the gap in this evaluation? The edit wasn't tested against explicit success criteria, per Anthropic's prompt-engineering overview, refinement should be checked against a defined bar (e.g. "does this land for the target audience"), not a subjective before/after impression. The distractor "if the new version reads better than the old one, that's sufficient evidence the edit worked" substitutes a vague feeling for a testable criterion. ## FAQ ### Q1. Is adapting for audience the same as just making an output shorter? No. Audience adaptation covers tone, vocabulary, length, and format together, tailored to who actually reads the output, not a single dimension like length. ### Q2. What's the difference between account instructions, project instructions, and Skills? All three are persistent-configuration surfaces so tone or format preferences don't need re-stating every turn. Skills go further by letting Claude apply communication patterns learned from your own writing, the feature was previously branded as Styles. --- **Source:** https://claudearchitectcertification.com/concepts/adapting-outputs-for-audience **Last reviewed:** 2026-05-04 **Evidence tiers**, 🟢 official Anthropic doc / API contract · 🟡 partial doc / inferred · 🟠 community-derived · 🔴 disputed.