Triteme

Triteme: Professional Writing for Humans to Read

Write clear, frictionless professional messages that a person actually wants to read and act on. Every message should remove friction (emotional, decision, or schedule friction) so the other person can keep saying yes.

How This Skill Is Organized

Triteme has a stable core and a growing use-case library.

• The core (this file) is the durable discipline: structured, concise, logical writing. It applies to every message and rarely changes.
• The use-case library (usecases/) holds situation-specific playbooks: asking, pushback, money, delays, scheduling, and more. It grows over time (see Growth Protocol at the end).
• examples.md is a verbatim before→after library to pattern-match against.
• voice.md captures how the user actually writes: read it to make output sound like them, not generic Triteme.

How to use it: read voice.md to match the user's voice, then apply the core to every message. When the situation matches an entry in the Use-Case Router, read that file and layer its play on top of the core. Don't load the whole library: pull only what the moment needs.

Two ways to use Triteme

• Drafting for another person (default). The user is composing a message to send to someone else. Use the whole skill: Core Discipline, Message Architecture, channel adaptation, sign-offs, and the use cases.
• Shaping an AI's reply to its user (AI to user). When an AI writes its own conversational reply to the person it works for, apply the Core Discipline and Anti-Patterns only. Skip the Message Architecture, setup labels, channel format, and sign-offs. The goal is a clear, frictionless answer, not a formatted message: never address or sign off to the user as if it were an outgoing message.

The Core Discipline: Concise + Logical

This is the spine. Before any use case, every message obeys these:

1. One message, one job. Decide the single outcome you want, write only what serves it, cut the rest.
2. Effort before ask. Put your labor on the table before any request appears.
3. Logical sequence. Order is an argument: actions chronologically, questions easiest→hardest, options preferred-first. Each line should make the next feel inevitable.
4. Specific over vague. Numbers, dates, names: never "a bit", "soon", "ASAP".
5. Narrow the decision. Present chosen options; never ask "what do you think?".
6. Facts over interpretation. State what's true and let it carry the message.
7. Stop early. When the job is done, send. If it won't fit the limits in Stopping Rules, it's a call, not a message.
8. No dashes as punctuation. Never use an em-dash (—) or en-dash (–). Use a colon, a comma, parentheses, or two sentences. This holds in every message, with no exceptions.

This skill is grounded in the Simple Rules framework: a handful of tailored guidelines that balance concrete guidance with the freedom to exercise judgment. Complex communication problems don't need complex solutions: they need the right simple rules applied to the right bottleneck.

Theoretical Foundation

The six rule types from the Simple Rules framework map directly onto professional messaging:

• Boundary rules → what to include and exclude in a message (no filler, no open-ended questions)
• How-to rules → the step-by-step logic for structuring different message types
• Prioritizing rules → sequencing list items and choosing what to address first
• Timing rules → when to send, when to follow up, when to stay silent
• Coordination rules → how to align multiple people without a meeting
• Stopping rules → when to stop writing and send, when to stop messaging and call

Keep the total number of rules you apply to any single message to a handful. If a message needs more than 4-5 rules to get right, the situation probably needs a call, not a message.

---

Message Architecture

Every message follows this skeleton. Not every message needs all five elements: short replies may only need acknowledgment + closing nudge. But the order never changes.

[Acknowledgment: short, matches their energy]
[Bridge: what I will do or what this is for]
[Setup label]:
1) [no cap, one complete thought (with context in parentheses if needed)]
2) [no cap, one complete thought]
3) [no cap, one complete thought]
[Closing nudge: short, ends with ?]

---

Element Rules

Acknowledgment

The acknowledgment sets the emotional temperature. Match their energy: don't impose yours.

| They did this | You say | |---|---| | Said yes / agreed | "Great." / "Perfect." / "That works." | | Changed direction / pushed back | "Okay." / "Understood." / "Fair enough." | | Shared information | "That's cool." / "Got it." / "Good to know." | | Shared something complex | "Okay, that makes sense." / "Right, I see where you're coming from." | | New thread / first message | "Hey [Name]." | | Weekend or off-hours | "Happy [day]." / "Happy [day] to you both." | | They went out of their way | "Appreciate that." / "I appreciate you turning this around so fast." |

Keep it proportional: a one-word answer from them gets a one-word acknowledgment. A detailed response can get a fuller one. But never let it become a paragraph. It's a launchpad, not a landing zone.

Never use: "Hope you're well", "Hope this finds you well", "No worries", "No problem", "Sorry to bother you."

Bridge

The bridge is where you earn the right to ask. Put your labor on the table before any request appears.

Formula:

I + [physical verb] + [the thing] + [so / before / in advance of] + [their benefit or next event]

Use physical verbs: build, edit, send, rework, share, put together, sort out, lock in, wrap up, get going.

Never use corporate verbs: finalize, commence, facilitate, ensure, endeavour, leverage, utilize, action (as verb), circle back, touch base, loop in.

The reason physical verbs matter: "build" and "rework" sound like real work. "Prepare" and "facilitate" sound like nothing. People respond to effort they can picture.

Example:

"I'll rework the proposal before our call so we stay on track."
"I'll send two options over tonight so you can review in the morning."
"Let me put together a breakdown and share."

Setup Label

The label tells the reader what kind of list is coming and what kind of response is needed. It always ends with a colon.

"To discuss:"          → they need to prepare
"Next steps:"          → they need to confirm
"As agreed:"           → they need to verify
"Questions:"           → they need to answer
"Two options:"         → they need to choose
"So:"                  → they need to correct or confirm your understanding

List Items

Format: 1) [no cap, one complete thought (context in parentheses if needed)]

Why this format works:

• 1) not 1.: closing parenthesis reads conversational, period reads formal
• No capital after the number: lowercase signals "conversation, not contract"
• Parentheses for context: keeps the main point clean while adding necessary detail
• One thought per item: if you need a second thought, start a new item

Sequencing logic (this is a prioritizing rule: order matters):

| Item type | Sequence | Why | |---|---|---| | Actions | Chronologically | Feels inevitable: each step leads to the next | | Questions | Easiest → hardest | Builds compliance: they're in answering mode by the hard one | | Options | Preferred first, alternative last | Anchoring: first thing read becomes the default |

When presenting two options, put "Or" on its own line:

1) roll the cost into the first retainer payment
Or
2) keep this as a separate one-off payment

Item count: 3-4 on WhatsApp. Up to 6 on email (group into two labeled sub-sections if 6).

Closing Nudge

The nudge has one job: make it obvious what the reader should do next.

| You need | You write | |---|---| | Confirmation | "Sound like a plan?" / "That sound right?" | | A reply that unlocks your work | "Let me know and I'll [next action]." | | A decision | "Which works best for you?" | | Nothing yet | "Speak [day]." / "Look forward to [next event]." |

Never close with "let me know your thoughts": too open, too easy to delay. Never close with only sentiment.

---

Use-Case Library (Router)

These are the situation playbooks. Apply the core to every message; when the task matches a row below, read that file and layer its play on top.

| Situation | Load | |---|---| | Asking someone for something / making a request | usecases/ask-for-something.md | | They pushed back, said no, or rejected an idea | usecases/handle-pushback.md | | Money, late payment, delays, or any awkward topic | usecases/uncomfortable-topics.md | | Need to create urgency without nagging | usecases/create-urgency.md | | Someone is late or dropped the ball | usecases/lateness-dropped-balls.md | | Locking in what was agreed after a conversation | usecases/lock-decisions.md | | Being flexible on timing without going passive | usecases/accommodate-without-losing-position.md | | Following up on a pending request without chasing | usecases/nudge-without-nudging.md | | Surfacing analysis, a concern, or a direction to a senior | usecases/share-thinking-with-senior.md | | Writing as someone's PA / representative | usecases/write-on-behalf.md | | First-contact outreach to an external partner or vendor | usecases/approach-external-partner.md | | Reporting a blocker or constraints, without blame | usecases/report-a-blocker.md |

If no use case matches, the core alone is enough. If a new situation recurs, add a use case: see Growth Protocol. The full catalog lives in usecases/README.md.

---

Etiquette Rules

These are boundary rules: they define what to do and not do in specific interpersonal dynamics.

Warmth is functional, not decorative. Every warm line must also do work. "Happy Saturday" lands right before a deliverable. If a warm line doesn't transition into content, cut it.

Acknowledge instead of apologize. "I appreciate your evening has begun" not "sorry for the late message." Apology puts you below; acknowledgment keeps you level.

Never let them see the sweat. Deliver like it was effortless. Don't mention working on weekends. Don't mention effort. Just deliver.

Narrow the decision, don't open it. Never ask "what do you think?": always "which of these two?" Do the thinking, present the narrowed options. Their job is to confirm or redirect, not to generate.

Volunteer the next action before asking for anything. Lead with what you'll do, follow with what you need. Every request feels light when you've already carried the heavier half.

When someone says no, pivot immediately. Accept in one word, redirect in the next sentence. No defending, no "are you sure?"

State the situation, never your interpretation. When someone is late or drops the ball, report facts. Don't ask "are you joining?": say "we're on the call."

---

Register & Seniority: Writing Up and On Behalf

How you write shifts with who reads it. These are the user's defaults for writing to seniors and for writing as someone's representative.

Writing up (to a senior)

• Accept with "I'd be very happy to…", not "I will…": willingness, not presumption.
• Ask with "Could I…" / "Would it be possible…", not "Can I…".
• Thank the specific thing: "Thank you for the invitation," not "thanks."
• Inform, don't instruct. Surface ideas with "I'm thinking," "I noticed," "probably": never "you should."
• Invite correction: close proposals with "Does this sound right to you?"
• Frame your learning as an investment: "I'll give you the highest return on that."

Writing on behalf of a principal

• Anchor authority to them: "As per [the principal]'s request," not "I'd like to remind you."
• As a junior writing to seniors, offer support, don't issue orders: "feel free to reach out if I can help," not "kindly coordinate with your teams."
• External-facing, stay objective and don't expose the assistant role: "This meeting is to…", not "I'd like to set up a meeting for my manager."
• Sign with the attribution: "On behalf of [the principal]."

Delivering problems

• State the current state, not blame: "Production credentials have not been generated yet," not "they never provided them."
• Stay forward-looking: "the next step is to expand," not "it never launched."
• Flag inferred vs. sourced: never present an assumption as fact.

Quick patterns

• Accepting from a senior: "Thank you very much, [Name]. I'd be very happy to [do X]. Really looking forward to it!"
• Correcting a mistake about you: keep it light, in the same message, with a smile: "By the way, just a small note: it's Mr. [Surname] 😄"

> Match warmth to the relationship: see voice.md for the user's two registers.

---

Stopping Rules

Know when to stop writing and when to stop messaging:

• If your message exceeds 12 lines (WhatsApp) or 20 lines (email), you need a call, not a message
• If your list exceeds 4 items (WhatsApp) or 6 items (email), you need a meeting
• If you've gone back and forth 3+ times on the same topic without resolution, suggest a call
• If you're about to write a paragraph explaining your feelings about a decision, stop: write the decision only
• If you're about to apologize for something that isn't your fault, stop: acknowledge instead

---

Channel Adaptation (Timing & Coordination Rules)

WhatsApp

Line breaks between every element
Acknowledgment stands alone on its own line
Bridge is 1 line
List is 3-4 items max
One emoji maximum, only as closing signal
Never send paragraphs: if it looks like a paragraph, break it
Total: under 12 lines

Email

Subject line mirrors the setup label
Acknowledgment + bridge merge into one opening paragraph (2-3 sentences)
Setup label gets its own line before the list
List can be 3-6 items (group with sub-labels if 6)
Closing nudge becomes a short final paragraph (1-2 sentences)
Sign off: "Cheers, [Name]" or just "[Name]": no "Best regards" / "Kind regards"
Total: under 20 lines

WhatsApp Example

Understood.
I'll rework the payment structure and send tonight.
Two options:
1) one-off payment for April (keeps it simple)
2) roll it into the first retainer instalment (starts 1st May)
Which works best for you?

Email Example

Subject: Payment structure, two options

Hi [Name],

Understood on the approach. I've reworked the payment
structure into two options so you can pick what fits best.

Options:
1) one-off payment for the April session and deliverables
   (keeps the retainer agreement separate, starting 1st May)
2) roll the April costs into the first retainer instalment
   (single agreement, simpler paperwork, starts 1st April)

Would be great to lock one of these in before Thursday
so I can get the SOW finalised. Which works best?

Cheers,
[Name]

---

Anti-Patterns (Boundary Rules: What to Never Do)

• Never open with "Hope you're well" before a strategic or internal ask: it's filler there. (A brief "Hope you are doing well" is fine in a transactional/relational email to a service contact you depend on.)
• Never send a contentless "Just checking in" / "Just following up." It works ONLY when tied to a specific item plus an offer of help (see usecases/nudge-without-nudging.md); otherwise state what you need
• Never send a message without an action you'll take or a clear ask
• Never close with only sentiment
• Never write a list without a setup label
• Never capitalize after a list number
• Never use 1. or 1:, always 1)
• Never ask "what do you think?": narrow the decision
• Never apologize for something that isn't your fault
• Never start with "I wanted to...": just do the thing
• Never write "as per my last email" or "as previously mentioned"
• Never use more than one exclamation mark per message
• Never use more than one emoji per me

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: quanvu309
• Source: quanvu309/triteme
• License: MIT

Install and usage instructions live in the source repository linked above.