v3.1.2 to v4.0.0

- description: >

- Compose and send honest agent correspondence across Slack, email, and other channels. Defines

- principal-direct, assistant, and bot lanes; the voice axis (chief-of-staff personas speak as

- the principal, executive-assistant personas speak as themselves); review-depth governance;

- persona configuration; disclosure signatures; and compose/send gates. Use for agent

- correspondence, sending on a principal's behalf, message signatures, disclosure lanes, persona

- registries, agent branding, agent voice, third-person agent messages, standing-direction

- sends, ghostwriting disclosure, or outbound-message gates.

- version: "3.1.2"

- ## The core principle

-

- Ghostwriters and executive assistants have drafted correspondence for the people they serve for as long as there has been correspondence to draft. Senior executives have long run their correspondence through personal staff at several levels of involvement at once: some messages the principal writes personally; some the principal dictates and staff transmit; some the principal directs at a high level ("reply warmly, decline the date") and staff compose in the principal's voice; and some the staff handle entirely, with the principal's knowledge of the system rather than of the message. None of that was ever considered dishonest, and none of it carried a disclaimer — because the principal owned the relationship and the direction, and the staff were a trained extension of the principal's judgment.

-

- AI agents change two things about that old system, and only two. First, some platforms stamp agent-performed sends visibly, so pretending is not even an option. Second, an AI agent is not yet as reliable as a trained human staff — a hallucinated detail attributed to the principal's own hand damages trust in everything the principal actually wrote. So unlike the human-staff era, disclosure is warranted. The design question is what the disclosure should track.

- ## The two questions, and the three lanes

-

- Every outgoing message answers two questions: **whose words are these**, and **who performed the send**. Those two answers sort all correspondence into three lanes on a single axis — how much of the principal is in the words:

-

- | Lane | Whose words | Who sends | Recipient-facing disclosure |

- |---|---|---|---|

- | **Principal-direct** | The principal's | The principal | **None.** Nothing to disclose, on any channel — regardless of how much AI research, drafting, or polish went into it. The principal read every word and performed the send; that is the ghostwritten letter the principal signs. |

- | **Assistant lane** | The principal's — composed, dictated, or edited to the point of genuine ownership | The agent | **A single authorship signature**: the principal wrote this, working through the named agent. One line, one meaning, no variants. |

- | **Bot lane** | The agent's, under the principal's direction — per-message instruction or standing rules | The agent | **The persona's own signature**: the named agent introduces itself, states the principal's direction, and promises the principal reads every reply. Wording may reflect how deep the direction ran. The body speaks in the persona's own voice (see the voice axis below). |

-

- The lanes are peers on a ladder, not tiers of one system stacked on another. A recipient who has seen two or three messages learns the legend without being taught:

-

- > **No marker — all the principal. Assistant marker — the principal's words, the agent's hands. Bot marker — the principal's direction, the agent's words.**

-

- That legend is the product. Every design choice below exists to keep it learnable and never false.

-

- ### The assistant lane requires exact-text ownership

-

- The assistant lane's signature makes a strong claim: *these are my words.* That claim is only honest when the principal composed the text, dictated it, or edited it to the point of genuine ownership — the modern equivalent of dictating to a staff member who types, fixes the grammar, and sends. Light agent cleanup (spelling, formatting, threading) does not break ownership, exactly as a typist's corrections never did.

-

- **A message the principal has not made their own cannot use the assistant lane. This is a category error, not a wording problem** — no signature phrasing can honestly combine "these are my words" with "I did not review these words." When a message needs to go out without that ownership, it belongs in the bot lane, whose signature claims direction rather than authorship. (This rule exists because the failure was discovered in practice: attempts to write an "unreviewed" variant of an assistant-lane signature come out self-contradictory every time. The cell is impossible; delete the cell.)

-

- ### The bot lane spans direction depths

-

- The bot lane honestly covers everything from "the principal told the agent what to say and glanced at the result" to "the agent acted on standing rules" to — where a principal explicitly builds toward it — "the agent read the incoming message and handled it." What varies across that range is internal governance (next section), not the lane. The signature always claims the same two things: the agent produced the words under the principal's direction, and the principal sees the replies.

-

- ## The voice axis — the archetype also binds the narrator (v3.0.0)

-

- The lane says whose words a message carries. The voice axis says who **speaks** — and the two

- must agree, because the grammatical person of a message is a disclosure the recipient reads in

- every sentence, whether or not it was designed as one.

-

- **The staff analogy that decides it.** A chief of staff is authorized to speak *as* the

- principal: drafts go out in the principal's first person, under the principal's ownership. An

- executive assistant speaks in their own voice *for* the principal's office: "Alex is traveling

- this week; I've moved your 2:00." Both are honest, both are centuries-old convention, and

- recipients parse each instantly. The archetypes map onto exactly this split:

-

- - An **`assistant`**-archetype persona is the chief of staff. Its messages are written in the

- **principal's first person**, because the entry condition of its lane is that the words ARE

- the principal's. "I" means the principal.

- - A **`bot`**-archetype persona is the executive assistant. Its messages are written in the

- **persona's own voice**: the persona says "I" about itself and refers to the principal by

- name, in the third person. It writes in the register the principal trained it to use — the

- principal's clarity, brevity, and style rules — minus the principal's "I."

-

- **The analogy honors these professions; it does not replace them.** Chiefs of staff and

- executive assistants are skilled roles this system borrows its conventions from precisely

- because they work. A principal who has a human chief of staff or EA should expect these

- personas to make that person more effective — absorbing the mechanical load so the human's

- judgment, relationships, and taste go further. A principal who has neither gets a working

- approximation of support they otherwise lack entirely. In both cases the agent extends the

- office; it does not compete with anyone in it.

-

- **Why this is worth enforcing rather than leaving to taste:**

-

- 1. **Grammar is the disclosure that survives.** Signatures are the most skippable part of a

- message — truncated in previews, dropped from forwards, cut from quoted replies. A message

- written in the persona's own voice is self-disclosing in every sentence; no excerpt of it

- can silently impersonate the principal.

- 2. **It creates an error-absorption layer, which widens safe autonomy.** When an assistant's

- note gets a detail wrong, the social reading is "the assistant got it wrong; the principal

- will fix it." When a first-person "I" message is wrong, the principal said something false.

- The riskier a mistake in the principal's own mouth, the narrower the autonomous lane must

- be — so the persona's own voice is what lets `standing_direction` carry more. Ownership

- never transfers (the principal answers for the system), and the hard content limits do not

- loosen; only the social cost of a routine error drops.

- 3. **It protects the currency of the principal's first person.** When every sentence that says

- "I" was genuinely owned by the principal, the "I" stays meaningful. Bot-lane messages that

- perform the principal's voice on unreviewed words quietly debase it.

-

- **The upgraded legend — pronouns become the protocol:**

-

- > **First person ⟺ the principal's ownership (principal-direct or assistant lane). The

- > persona's own voice ⟺ the agent's words (bot lane).** The signature confirms what the

- > grammar already said.

-

- **Bot-voice composition rules:**

-

- - The persona says "I" for itself and names the principal in the third person. Establish the

- narrator **early** — a reference to the principal by name in the first sentence or two —

- never only in the signature, since the message arrives from the principal's own account.

- - For a recipient who has never seen the persona, open with one identifying clause ("This is

- Acme-Bot, Alex's AI assistant —"). Identification is not a process banner: what stays

- banned is apologetic process-framing as the opener, not a staff member saying who they are.

- - The persona relays facts, logistics, and decisions the principal actually made. It never

- characterizes the principal's unstated opinions or feelings ("Alex thinks…", "Alex would be

- happy to…" — says who?), never negotiates substance, and escalates rather than improvises.

- - **Sincerity classes require the principal's voice.** Appreciation, kudos, condolences, and

- anything whose value is the personal relationship lose their worth through an intermediary —

- "Alex appreciates the quick turnaround" is distinctly colder than "thank you." Those route

- to the principal-direct or assistant lane even when low-stakes. This yields the practical

- lane test: **would it sound right coming from a staff assistant? If not, route up.**

-

- ## Review depth — internal governance, not disclosure

-

- Review depth is the approval-workflow axis: what has to happen before a message may leave. It determines gates, content limits, and logging. It is deliberately **not** the recipient-facing taxonomy — recipients care whose words they are reading, not which internal approval path ran.

-

- | Review depth | What it means | Lanes it can feed |

- |---|---|---|

- | `exact_text` | The principal approved (or authored) this exact text | Principal-direct, assistant lane, or bot lane |

- | `per_message_directive` | The principal gave a specific instruction for this message ("reply affirmatively, propose Tuesday") but did not necessarily see the final words | Bot lane only |

- | `standing_direction` | The agent sends per standing rules the principal set for a class of messages, with no per-message involvement | Bot lane only |

- | `autonomous_initiative` | The agent notices the need and handles it end to end — the deepest form of the old staff system, where the principal knows the system, not the message | Bot lane only; requires its own explicit standing instruction to exist at all, and per-send logging the principal actually reads |

-

- **Hard content limits at `standing_direction` and deeper** (floors, not suggestions): never opinions, never commitments, never anything touching a sensitive relationship, never criticism — criticism is always personal and always reviewed. Add your own limits on top; never subtract these.

-

- **Two routing rules, one for each direction of doubt:**

-

- - **Approval doubt routes toward more review.** Not sure whether a message is safe for `standing_direction`? It goes to per-message review.

- - **Authorship doubt routes toward the weaker claim.** Not sure the principal genuinely owns the words? It's the bot lane. **When in doubt, claim less.** An assistant-lane signature on words the principal didn't own is the one failure this system cannot walk back, because it falsifies the legend the recipient has learned.

-

- ## Persona registry — configuration, not skill content

-

- This skill defines the mechanism; it doesn't know anyone's brand name. A user's actual agent personas belong in a private, source-controlled config:

-

- ```yaml

- personas:

- - id: acme-bot

- display_name: "Acme-Bot"

- archetype: bot # binding: this persona carries bot-lane semantics

- emoji: "🤖"

- url: "https://acme-bot.example/"

- scope: >

- All bot-lane sends: the agent's words under my direction — routing,

- scheduling, status, acknowledgments, and directed replies.

-

- - id: acme-assistant

- display_name: "Acme-Assistant"

- archetype: assistant # binding: this persona carries assistant-lane semantics

- emoji: "🧞"

- url: "https://acme-assistant.example/"

- scope: >

- Assistant-lane sends only: my words, transmitted by my agent.

- Exact-text ownership required — no exceptions.

- ```

-

- A fuller, commented template is in [`references/persona-registry.example.yaml`](references/persona-registry.example.yaml).

-

- - **`id`** — stable internal identifier; never shown to recipients.

- - **`display_name`** — exact prose spelling. Branding is absolute: one capitalization, one form, never varied in outgoing text.

- - **`archetype`** — `bot` or `assistant`. **Binding, not cosmetic** (below).

- - **`emoji`** — the persona's visual marker; this is the legend, so personas must never share one, and a persona's emoji never appears on another persona's message.

- - **`url`** — the persona's reference link, if it has one.

- - **`scope`** — free text describing when this persona is used. Define as many personas as match how you actually operate — one per venture, separate work and personal identities, multiple bot brands for different audiences. Every persona still maps to exactly one lane via its archetype.

-

- ### Archetype is binding — it selects the lane and the narrator, not just the tone

-

- `archetype` is the schema's highest-leverage field. In this skill's first version it only set

- the signature's register; v2 made it the lane assignment; v3 makes it bind the narrator too:

-

- - An **`assistant`**-archetype persona exists for assistant-lane sends only. The body is the

- principal's first person, and its signature centers the principal as author, the tool as

- instrument — *"I wrote this with my Acme-Assistant"* — **one** signature, because the lane

- has one meaning. Using it requires exact-text ownership, always.

- - A **`bot`**-archetype persona exists for bot-lane sends. The body is the persona's own

- voice, and its signature is written the same way — the persona introducing itself and

- making the loop-closing promise on the principal's behalf. It may carry variants reflecting

- review depth, since the lane honestly spans several. One narrator per message: a bot-voice

- body with a principal-voice signature flips the narrator mid-message, and recipients notice.

-

- Generic signature examples (a principal named Alex):

-

- | Lane / depth | Example signature |

- |---|---|

- | Assistant lane (always `exact_text`) | `🧞 _I wrote this with my [Acme-Assistant](https://acme-assistant.example/)_` |

- | Bot lane, `exact_text` approved | `🤖 _I'm [Acme-Bot](https://acme-bot.example/), Alex's AI assistant — Alex approved this message before I sent it_` |

- | Bot lane, `standing_direction` | `🤖 _I'm [Acme-Bot](https://acme-bot.example/), Alex's AI assistant, sent under standing direction — Alex reads every reply_` |

- | Bot lane, sent ahead of review (rare) | `🤖 _I'm [Acme-Bot](https://acme-bot.example/), Alex's AI assistant — Alex hasn't reviewed the details yet and will follow up personally_` |

- ## Channel disclosure is a fact, not a preference

- Whether a channel forces visible disclosure when an agent performs the send is a property of that channel — verify it, don't assume it.

- - **Slack forces it.** Slack's agent/bot connector auto-stamps a visible "Sent using [agent name]" tag the instant an agent, not the human, performs the send. No signature wording removes it — it's platform-level. Write the persona's signature to pre-explain the tag, since it will appear regardless.

- - **Most other channels don't.** Email the human sends by clicking "send" on an agent-drafted message carries no platform tag — the send action was human. A direct API send frequently carries none either, but that varies by provider. Where nothing is forced, disclosure is governed by the lane, not the channel.

- - **Check, don't guess.** Connector behavior changes with product updates. Verify each channel's current behavior before designing a signature around an assumption carried from another channel, or from memory.

-

- ## Three gates

-

- The lanes say *what* to disclose. These gates protect the *work* underneath the disclosure — a message can be honestly labeled and still be wrong, stale, or off-voice. All three are substance, not enforcement; `synthesis-message-guard` (below) is what makes them mechanical instead of optional.

-

- ### 1. Reply-history gate — before composing

-

- Before drafting any reply, or any message that continues an existing topic: read the entire thread, including the quoted history under the latest message — the thread's own tail is a primary source, and every prior position the principal took in it constrains what the reply may say. Search prior correspondence for the recipient AND the topic, across every mailbox and channel the principal actually uses. A zero-result search is never evidence of absence — prove the search tool still works with a query known to return results before trusting any null.

-

- ### 2. Compose-time voice & anti-slop gate — before staging or presenting a draft

-

- Load whatever voice/style skill governs the principal's correspondence register before writing a word — their own private voice rules, or the general-purpose public catalogs (`synthesis-content-quality` and `synthesis-writing-pitfalls`: AI-cadence patterns, disproportionate praise, apology overuse, aphorism-pivot closers). Grounding is necessary but not sufficient — a factually accurate draft that reads as slop still damages the relationship the message exists to serve. This gate matters most in the bot lane, where the agent's words carry the principal's name; in the assistant lane the principal's own authorship is the voice gate.

-

- ### 3. Pre-send relevance & grounding gate — at send time

-

- Approval of text is not approval of staleness. Immediately before transmitting: re-read the target thread or channel live — never from local transcripts alone — and check whether anyone has replied or moved the topic since composing. Re-verify every factual claim the message makes. A draft that has been sitting in an approval queue or drafts folder for more than about a day needs a full re-gate, not a glance. The verdict is always one of three: send, revise, or withdraw.

-

- ## Adopting this for yourself

-

- 1. **Define your persona(s)** in a private, source-controlled config, using the schema above with your real names, emoji, and URLs — at minimum one `bot` persona; add an `assistant` persona when you want an agent to transmit words that are genuinely yours.

- 2. **Treat the archetype as law.** The assistant persona never signs words you don't own; the bot persona never claims words are yours.

- 3. **Verify your channels' real disclosure behavior** rather than assuming from this skill's Slack example.

- 4. **Write your `standing_direction` content limits.** The hard limits above are a floor — add whatever else is specific to your context.

- 5. **Wire the three gates to your own voice/style skill(s)**, and to `synthesis-message-guard` if you want fail-closed enforcement rather than a convention that depends on being remembered. If your guard has brand-integrity patterns, make them lane-aware: block each persona's emoji when its own branding is absent, rather than banning an emoji outright.

- 6. **Keep the private layer thin.** It should hold only what's actually yours — names, exact signature wording, org-specific routing rules — and reference this skill for the mechanism. Duplicating the mechanism into the private layer is how the two drift apart.

-

- ## Migrating from earlier versions of this skill

-

- **v1 → v2.** v1 organized everything around three review tiers as the recipient-facing system, with archetype as tone. v2 inverts that: the **lane** (principal-direct / assistant / bot) is the recipient-facing system, review depth is internal governance, and archetype is binding. Your `reviewed`/`standing_direction`/`unreviewed_substantive` tiers map directly onto the review-depth column (`exact_text` / `standing_direction` / bot-lane-ahead-of-review); the only breaking change is that an assistant persona has exactly one signature — its former standing-direction and unreviewed variants were incoherent cells, and any traffic that used them belongs to the bot persona.

-

- **v2 → v3.** v2 had bot personas write in the principal's first person, disclosing agency only in the signature. v3 binds voice to archetype: bot personas speak as themselves, assistant personas as the principal. Three consequences for adopters. (1) Bot signatures rewrite from the principal's voice ("my Acme-Bot handled this…") into the persona's ("I'm Acme-Bot, Alex's AI assistant…") — one narrator per message. (2) Sincerity classes (appreciation, kudos, condolences, relationship-touching messages) leave the bot lane: their value requires the principal's own voice, so they route to principal-direct or assistant even when low-stakes. (3) If a fail-closed register guard bans third-person agent phrasing wholesale (a v2-era rule), retarget it to servile relay-framing only ("Alex would like me to…", "on behalf of Alex" as an opener) — plain statements about the principal are now the bot lane's canonical voice, and an unretargeted guard will block every compliant send.

-

- ## Related

-

- - [`synthesis-message-guard`](../synthesis-message-guard/SKILL.md) — the mechanical enforcement layer: a fail-closed pre-send hook that blocks a send unless a fresh grounding ledger attests the gates above actually ran. This skill states the conventions; message-guard is what makes them impossible to skip.

- - [`synthesis-content-quality`](../synthesis-content-quality/SKILL.md) and [`synthesis-writing-pitfalls`](../synthesis-writing-pitfalls/SKILL.md) — the detection catalogs behind the compose-time voice gate.

- - [`synthesis-writing-craft`](../synthesis-writing-craft/SKILL.md) — the positive craft principles underneath any drafted correspondence.

- - [`synthesis-disclosure-policy`](../synthesis-disclosure-policy/SKILL.md) — a sibling config-driven pattern (a published-precedent ledger instead of a persona registry) for the adjacent question of what may be said about real parties, rather than who's speaking.

-

- A private companion configuration — the user's actual persona registry, exact signature wording, and any organization-specific rules layered on top (assignment routing, approval-phase state, team-specific content limits) — belongs in their private skill collection. This public skill carries the mechanism only.

-

-

- ## Email construction and verification

-

- Use HTML paragraphs by default and avoid rendered line breaks inside prose

- paragraphs. The principal may explicitly choose plain text or intentional line

- structure through the message-guard owner's formatting policy. This choice

- never changes authorship lanes, exact-text approval, disclosure or recipient

- checks. Follow the principal's private transport restrictions when present.

-

- Load `synthesis-message-guard` for construction, capability enrollment and the

- complete tool-input ledger. Ground every populated alternate part; bind the

- final recipients, subject, body, thread fields and tool name with `--message-sha`.

- After an authorized draft/send, verify its actual raw readback and preserve the

- message ID and provenance. Do not call a synthetic MIME roundtrip a native send,

- a filed draft or delivery confirmation. Route catalog changes to the existing

- configuration owner, preserving unrelated hooks and non-email workflows.

-

-

- Other human-readable correspondence follows the same overridable default for

- paragraphs. Use `--build-text` for literal prose and `--verify-text-readback`

- after an authorized post. Intentional code, poetry and address blocks require

- an owner-approved paragraph-policy override; never normalize significant

- whitespace. Retain post IDs, retrieval evidence and any missing-readback gap.