As I begin testing out this and other more tunable/steerable parameters with Fable, I’ll report back and I’ll publish an updated to what I shared on this week’s call when the topic of writing with LLMs and the usual “artificial LLM flavor” that lingers in the mouth of your mind when reading too much AI-generated stuff….
I’ll post an update here when I update this gist with the new Fable 5.1 tunings.
Click to expand: LLM Writing: Fable 5.1 Density & the Mannered Prose Anti-Pattern
In the latest Fable release of version 5.1 they include this on writing density and what they call “mannered prose”, with this prompting guidance here:
Claude Fable 5.1's writing is generally a step up from earlier Claude models, with fewer stock phrases and less unexplained jargon. In some cases, though, its prose is denser than Claude Fable 5's: sentences run longer and there are fewer paragraph breaks. An instruction that defines the anti-pattern, mannered prose, helps. Add it to a user message (preferred) or the system prompt:
Mannered prose substitutes metaphor and flourish for direct statement. Instead of "a parameter worth varying," the mannered writer produces "a dial worth turning." Instead of "this point still matters," they write "this point earns its keep." The phrases exist to display the writer, not to convey the idea, and readers can tell. That is why mannered prose irritates: it makes the reader work harder so the writer can perform. It is also imprecise. Metaphors drag in connotations the writer did not choose and cannot control. The fix is to say what you mean. When a literal phrase is available, use it.
The short version also tends to work:
Please remove all mannered prose.
Here are the actual methods I’ve been using about how I shape the writing output from LLMs that uses something called “perspective taking” (also “standpoint” from Ethnography).
Use this whenever you draft Chat, email, a briefing, or a prompt for an agent. Do not start by summarizing what you know. Start by naming who will read this, in what job, and what they will do with it.
Roles only in this guide — write to the hat, not the person. The same human may be CPO on one message and “person walking staging” on the next; those are different cards.
Related: HATS patterns (quote → TLDR → own thread). Drafts before send live in msg-drafts/.
Fill a role card. If you cannot fill it, you are not ready to draft.
| Field | Question |
|---|---|
| Role | Job title, not a person. One primary reader. |
| Today | What they do with this kind of information now. |
| Fear | What this message could make worse (ambiguity, extra work, looking uninformed, losing a workaround). |
| Gain | What “good” looks like for them if this lands. |
| Needs from us | The one artifact they can actually use (scan, decide, teach, click, implement). |
| Job with this text | Scan / decide / teach / do a task / implement. Pick one. |
Facts (shared): A batch of UI fixes is on staging. We need a review of chrome (labels, buttons, headers), not of which papers happen to be in the list. Reviewers should look, not Reject / Claim / change a domain on rehearsal data. Detail lives in a review issue.
CPO / product owner — job = scan and sign, then tell the rest of the C-suite whether we are on track.
Staging has the locked changes. Please check buttons and labels (not which papers are in the list).
- Unclaimed: domain is ordinary text again; Change domain is a button next to Reject.
- Propose a reviewer: header copy is now the COI-before-submit sentence.
- Student home: three tags; “Also in flight” is gone.
Looking is enough — don’t Reject, change a domain, or Claim a real paper. Review issue if you want the picture book.
They asked for this shape in the room: one scannable page, bullets, priority order, links out. Not a stack of issues.
Product manager (reports to CPO; also implements) — job = keep the CPO scan intact, and ground the work in the PRD (personas × jobs × workflows).
CPO scan is above — same three bullets, same “look, don’t write.”
PRD slice: this batch is Unclaimed domain control, Propose-reviewer header, Student-home tags. Each maps to an AE/student job, not to an issue number. Issue-level detail stays behind the link; do not flatten this into ticket numbers.
They need more than the exec brief and less than the issue dump. Issues are painfully detailed; the PRD is the middle altitude.
CWO / sponsor (chief worry, then chief wish) — job = hear change-management, readiness, and scale — not feature chrome.
Staging review is a product gate, not a launch gate.
What this does not mean: we are ready to onboard the next large cohort, or to turn the old system off.
Open worry: can the next cohort finish the job in the new portal, and do we have a rollback if chrome is wrong? Yes — look-only review; easy rollback if anything is off.
Ask of you: none this week unless the CPO flags a readiness risk.
They convert from worry to wish once risks are named and de-risked. Features are the wrong altitude.
These five terms are the scaffold. They are working definitions — what they mean once you use them to write — not dictionary entries.
| Term | Working definition | Fill-in |
|---|---|---|
| Purpose | Why this artifact exists in the org. The job it does. | “This is a CPO scan so the product owner can sign a batch without opening every issue.” |
| Intent | What you want the reader to do or believe after reading. One verb. | Sign / correct / look-don’t-write / teach / decide go-no-go. |
| Context | The minimum the reader must know to act — in their vocabulary, at their place in the process. Drop shorthand they do not share. | Staging vs old system; “chrome not paper titles”; no Claim on rehearsal data. |
| Outcomes | How you will know it worked. Visible, checkable. | They walked the three surfaces; they corrected the recap; they marked the roster; they can teach the path. |
| Structured output | The form that matches purpose + role. Not “a message.” A named shape. | CPO scan · PRD change order · issue · Chat TLDR + thread · sponsor one-slide · user email · facilitator script. |
If purpose, intent, context, and outcomes are clear and you still write a wall of notes, you skipped structured output. The form is the product.
| Altitude | Audience | Form | Contains | Does not contain |
|---|---|---|---|---|
| 1. Scan | CPO / product owner | One page or one Chat. Bullets. Priority/urgency order. Links out. | State change, this-week table, shipped vs still-open by job, numbered asks | Issue novels, SHA archaeology, every sitting note |
| 2. PRD | Product manager | Change order: persona × page × job × bucket | Who the user is, the workflow, what “done” means | Agent-ready reproduction steps |
| 3. Issue | Implementer / agent | One slice, after the human gate | Acceptance criteria, where to click | The CPO’s inbox |
| Up | CWO / PI / sponsor | Decision brief or verbal pack | Readiness, risks, scale, what we need blessed | Feature lists, issue numbers |
| Out | AE / student / account holder | Their job in their words | What they will see, what to do, what will change for them | Internal names (“umbrella,” “clone,” “island”) |
| Sideways | Ops teammate | Numbered steps in their words | What to run, what “done” looks like | C-suite strategy, unexplained shorthand |
| Chat | Mixed space (see §3) | Top-level TLDR + thread off that TLDR | One-breath outcome in main; commands / caveats / links in the thread | A dump in main; an ack buried on someone else’s old thread |
A common failure is one artifact that tries to be all six altitudes. That is the Goldilocks miss: too much volume and too much density. Recipients either deep-dive everything or ignore everything.
When the structured output is Chat, always produce two parts. Do not hand over a single blob and hope someone splits it.
| Part | Where | Job | Length |
|---|---|---|---|
| Top-level TLDR | New message in the main stream of the space | Bystanders close the loop without opening Calendar, an old thread, or this thread | One breath. Quote + outcome. Skimmable on a phone. |
| Thread details | Replies off our TLDR, not off the original ask | Commands, Zoom, attendees, caveats, links, SHA, “don’t click Reject” | As long as needed. Named deep-dive. |
This is the default for any requested change (calendar, access, deploy, comms) that others need to see closed. Pattern IDs: HATS-P1 (quote → TLDR → own thread), HATS-P2 (closed loop for bystanders). The failures it prevents: HATS-A1 (wilco-only / silent action), HATS-A2 (buried-thread ack).
Spaces like product/dev often do not thread. People stream in main. If you only reply on the asker’s old thread, the person who can see Calendar still cannot see the ack, and bystanders never learn the loop closed. If you only act and say nothing (wilco), the action is invisible unless someone already has the calendar open.
The “readback” has to be public and short. Details belong in a thread we own, so main stays a signal and the thread is the optional deep-dive.
| Situation | Post |
|---|---|
| Someone asked in main; others need to see it done | New top-level TLDR. Quote them. Thread off that. |
| The ask lived in an old thread (timeslot, last week’s issue) | Still a new top-level. Do not ack only on the old thread. Optional one-liner on the old thread that points at the new TLDR. |
| One decision covers two existing threads | New top-level that covers both. Optional one-liner in each old thread pointing here — only if the extra ping is worth it. |
| Continuing a review the owner already opened (picture-book walk, recap they asked for) | Reply in that thread. Do not fork a second top-level unless bystanders now need the outcome. |
| Look-only / “on an island” with no shared-lane impact | Chat optional. If you post, still TLDR + thread — do not invent urgency in main. |
Required, in order:
- Mention the primary role (Chat user mention).
- Quote the request in their words when you are closing their loop. Do not paraphrase away the ask.
- Outcome in one breath — done / ready to look / locked for next pass / needs a decision.
- The one action for the reader, if any (look, don’t write; mark the roster; say if this is wrong).
- One link if the next click is load-bearing (review issue, staging URL). More links go in the thread.
Top-level may include a short bullet list when the reader is a CPO scanning chrome — three jobs, not ten tickets. If the bullets need explanation, the explanation is thread.
- Numbered steps / commands (
git pull,just hooks). - Zoom, attendees, timezone, calendar event IDs.
- Caveats (“docs-only pushes do not deploy”; “easy rollback to <sha>”).
- Picture-book / issue / Drive links.
- “Don’t Claim / Reject / change a domain on rehearsal data.”
- Anything a bystander does not need in order to know the loop closed.
Drafts that will be pasted or posted as rrid-dev@ use Chat markup:
| Need | Write |
|---|---|
| Bold | *bold* — not **bold** |
| Link | <https://example.org|label> |
| Mention | <users/…> or the space’s mention form |
| Bullets | • or - — keep the TLDR short enough that bullets are optional |
Do not auto-post. Draft both parts for review. The role who owns the relationship signs the send.
When you ask an agent (or a teammate) for a Chat message, require this skeleton. Name the file YYYY-MM-DD-<audience>-<channel>.md under msg-drafts/ if it is outbound ops.
# Draft — <role> in <space> (<date>)
**Status:** draft — do not post until <owner> approves
**Space:** <space name / id>
**Placement:** new top-level | reply in existing thread <url>
**Role card:** <role> will use this to <scan | decide | teach | do a task>
**Purpose / intent / outcomes:** <one line each>
---
## Top-level
<mention> <quote of their ask, if closing a loop>
<one-breath outcome>. <one action, if any>. <one link, if load-bearing>
---
## Thread
<details, commands, caveats, extra links.
---
## Optional — old threads to point here
- <url> — one-liner only if the extra ping is worth itSame method as §1; form is Chat.
Top-level
Your new branch is on the island URL. The old URL stays until we mark-and-sweep. Docs-only pushes to
maindo not deploy; code changes do. You’re on ops pages this week; ask the product manager what “par” means for the week.
Thread
In the webapp repo you deploy from:
git pulljust hooks— once per clone, not per worktree.After that, a real app push to
mainwill say it deploys the team site and wait fory. Docs-only: it tells you it will not deploy.
Bystanders in the space learn: island is up, docs don’t deploy, that person owns ops pages. Nobody needs the commands unless they are that person.
Top-level
Friday’s batch is on staging. Picture-book review is in the issue. Look at chrome (headers / CTAs / labels), not paper titles. Please don’t Reject, change a domain, or Claim on rehearsal data.
Thread
Rollback is the previous staging SHA if anything is off. Surfaces to walk: Unclaimed (Reject + Change domain button), Propose-reviewer header, Student home tags. Issue has before/after stills.
Append this to the agent prompt in §4:
Structured output: Google Chat as TWO parts — do not merge them.
Space: <name>
Placement: new top-level (default) | reply in <thread url>
Quote their ask (their words): <text or "n/a — we are originating">
Top-level must include: mention, quote-if-closing-loop, one-breath outcome, at most one action, at most one load-bearing link
Thread must include: <commands / caveats / extra links / don't-write rules>
Markup: Chat, not Markdown (*bold*, <url|label>, user mention)
Do not post. Draft only.
Optional one-liners on old threads: <urls or none>
- Name the primary role (one). Secondary readers get a link or a second artifact, not a mashup.
- Fill the role card (today / fear / gain / needs / job with this text).
- Fill the five terms in one sentence each. If a sentence is fuzzy, stop.
- Pick the form from the altitude table. Write in that form only. If the form is Chat, write top-level and thread as separate sections.
- Draft in the reader’s words. Outcomes and jobs, not systems. If they do not say “umbrella” or “clone,” you don’t either.
- Skim as that role. Two passes only: (a) can I glean the important bits in one screen (or one TLDR)? (b) is there a named place to go deeper (link, PRD, or our thread)? Cut until both are yes.
- Put asks in a list. A CPO scan ends with “Asks of you.” A user note ends with the one action. A sponsor note ends with the decision to bless. A Chat TLDR ends with the one action or with “done.”
- Do not auto-send. Drafts are for review. The role who owns the relationship signs the send.
Write for this role: <ROLE>
They will use this text to: <SCAN | DECIDE | TEACH | DO A TASK | IMPLEMENT>
Purpose: <why this artifact exists>
Intent: <one verb — what they should do after reading>
Context: <only what this role needs, in their vocabulary>
Outcomes: <how we will know it worked>
Structured output: <named form — CPO scan / PRD / issue / Chat TLDR+thread / sponsor brief / user email>
Role card:
- Today:
- Fear:
- Gain:
- Needs from us:
Facts (do not dump these at their altitude; roll them up):
<bullets>
Constraints:
- No names of people; roles only if this will be shared.
- No internal shorthand the role does not use.
- One screen unless the form is a PRD, issue, or Chat thread.
- Link out for detail; do not flatten altitudes.
- End with numbered asks (or one user action).
- If Chat: output ## Top-level and ## Thread as separate sections; Chat markup; do not post.
- Writing to the pile — everything you learned, in the order you learned it.
- Name-as-audience — “this is for [person]” instead of “this is a CPO scan.”
- Shorthand that assumes a clone — “umbrella,” “webapp (once per clone),” ticket numbers as the story.
- Wilco-only — you did the thing and said nothing the role can see in main.
- Buried-thread ack — the answer lives on the asker’s old thread; bystanders never see the loop close.
- One blob instead of TLDR + thread — commands and caveats in main, or a TLDR with no owned thread for the deep-dive.
- Issue-first — filing implementer tickets before the CPO scan and PRD gate.
- One note for two jobs — CPO sign-off and end-user impact and ops steps in the same paragraph. Split, or write the user-facing piece so the CPO can forward it unchanged.
- I can say the role and the job with this text in one line.
- Purpose / intent / context / outcomes / form are filled.
- A person in that role can act without opening the links (or the Chat thread).
- Detail exists behind a link or in our thread, at a lower altitude.
- Asks are numbered (or there is exactly one user action, or the TLDR is “done”).
- I have not used a word the role has not used.
- If Chat: top-level and thread are separate; placement is decided (new main vs existing thread); markup is Chat; it will not post until approved.