Write the New AI Copy Genres as a Content Kit

Workflow area: Content & UX Writing · Tier: Advanced · Hands-on time: ~40 minutes

Your voice guide covers buttons and errors. It says nothing about how to word a hedge when the model is unsure, what a refusal sounds like in your brand, or what example prompt sits in the empty chat box — because those genres are new. Teams improvise them per feature, and the improvisations diverge: one surface over-apologizes its refusals, another hedges everything into mush, a third's suggestion chips promise capabilities the feature lacks. These strings do heavier lifting than ordinary microcopy — they set expectations, calibrate trust and teach capability boundaries. Shape of AI catalogs the surrounding patterns (Wayfinders, Trust Builders); this playbook writes the words that fill them, as a kit any writer or designer can extend.

When to use — and when not to

• Use it when your product ships its second AI surfaceone feature can improvise; two features improvising is how the same product ends up with two AI personalities.
• Use it as the content layer of your AX pattern workpb-40's entry points, pb-44's memory disclosures and pb-48's failure states all need strings; this kit is where those strings come from.
• Use it after the voice engine exists (pb-27)the kit extends the voice system into the new genres; without a base voice, you're inventing two things at once.
• Skip genres your product doesn't shipno memory features means no memory-disclosure copy; write the kit for surfaces that exist or are on the roadmap, not the full taxonomy for completeness.
• Skip kit-writing for one-off experimentsa prototype's strings can be improvised; the kit is for genres that will recur across shipped surfaces.

The recipe

1. 1.

   Inventory your AI surfaces and map them to genres. Walk every shipped and planned AI touchpoint and tag which genres it needs. The core eight: prompt placeholders (the empty input's teaching text), suggestion chips (tappable starter prompts), capability onboarding (first-run "what this can and can't do"), uncertainty hedges (how the system says "I'm not sure"), refusal language (how it declines), feedback requests (asking "was this helpful" without begging), AI disclosure labels ("AI-generated" marks), and loading/working copy (what the wait says). Your product's subset of these is the kit's table of contents.

2. 2.

   Write the genre rules — each genre has its own physics. Before generating a single string, define per genre: its job, its failure modes, and three or four rules. This is the judgment layer, and it's yours. For example:

   Copy

   GENRE: Uncertainty hedges
   JOB: calibrate user trust downward exactly as far as warranted —
   no further.
   FAILURE MODES: hedge-everything (mush, trains users to ignore
   hedges), hedge-nothing (false confidence), blame-the-user.
   RULES:
   1. Hedge the CLAIM, not the sentence: "This may be outdated —
      last updated Jan 2025", never "I might be wrong about all this."
   2. Name the reason for uncertainty when known (stale source,
      thin evidence, ambiguous question).
   3. Pair every hedge with a next action: verify link, refine ask.
   4. Never hedge as personality ("I'm just an AI!") — hedge as
      information.
   
   GENRE: Refusals
   JOB: decline clearly, without moralizing, and route forward.
   RULES:
   1. State that it can't help with the request in one plain clause.
   2. No lectures, no repeated apology, no fake regret.
   3. Offer the nearest thing it CAN do when one exists.
   4. Same voice as the rest of the product — refusal is not a
      register change.
   

3. 3.

   Generate the kit strings with the voice engine. Feed your pb-27 voice system plus the genre rules, one genre at a time, with real surface context:

   Copy

   Using the voice system above plus the genre rules for [GENRE],
   write strings for these surfaces:
   
   Surface: research assistant, empty input field
   Genre: prompt placeholder + 3 suggestion chips
   Context: users can ask about [DOMAIN]; feature cannot [LIMITS].
   Constraints: placeholder max 60 chars; chips max 32 chars; chips
   must only promise things the feature genuinely does well.
   
   Return 3 options per string with one-line rationale. Flag any
   chip that risks overpromising given the stated limits.
   

   Good output looks like this:

   Copy

   PLACEHOLDER (opt A): "Ask about your reports — try a specific
   question" — teaches specificity, names the corpus.
   CHIPS: "Summarize last week's report" / "Compare Q2 vs Q3" /
   "Find mentions of churn"
   FLAG: "Predict next quarter" rejected — feature retrieves, does
   not forecast; chip would overpromise.
   

4. 4.

   Run the keep/edit/rewrite pass with genre-specific scrutiny. Judge each string against its genre's failure modes, not just voice: chips against actual capability (every chip is a promise), hedges against the hedge-everything trap, onboarding against overclaiming, refusals against moralizing. Log rationale as in pb-27 — the log is what future writers learn the genre from.

5. 5.

   Assemble and publish the kit. Per genre: the job, the rules, approved exemplars with context, near-miss counterexamples ("rejected because…"), and character constraints. Publish where strings live — Frontitude library, design system docs (pb-24 pattern), or the voice Project — and wire the kit back into the pb-27 system prompt so every future generation knows the genres natively. Add the genre checks to your pb-35 pre-review rubric so drift gets caught at submission.

6. 6.

   Test the load-bearing genres with users. Placeholders, chips and onboarding claims shape what users try; hedges and refusals shape whether they trust the answers. In your pb-37 live prototype sessions, watch: do users' first prompts mirror the chips (they will — chips teach)? After a hedge, do users verify or shrug? After a refusal, do they retry, reroute or leave? Revise the kit on evidence, not taste.

Make it yours

• Shape of AI as the pattern atlas: for each genre, study how documented products fill the equivalent pattern — then write your version in your voice; the kit's structure travels across products even though the words never do.
• Frontitude as the kit's runtime: store approved genre strings as a synced library so designers pull real kit copy into AI-feature frames instead of typing "Ask me anything…" from memory.
• Agency variant — kit as deliverable: for client work, the genre kit is a sellable artifact alongside the voice system: same structure, client's voice, priced as the thing that keeps their AI features coherent after you leave.

Quality check

• Every chip and onboarding claim maps to a real capabilitycapability copy is a contract; one overpromising chip generates more distrust than ten bland ones.
• Hedges carry information, not anxietyeach names what's uncertain and why, paired with a next action; blanket hedging got rejected in the log.
• Refusals are plain, unapologetic and routedno moralizing, no double sorry, an alternative offered where one exists.
• The kit has counterexamplesnear-misses with rejection rationale; a kit of only winners doesn't teach the boundaries.
• The genres entered the systemvoice prompt updated, pre-review rubric extended, kit published where writers work; a kit in a drawer is a workshop, not infrastructure.