Conventional Conversations

v0.1 — a specification

Say what kind of message you're saying, before you say it.

Text strips out tone. Conventional Conversations borrows the idea behind Conventional Commits — a small, explicit tag at the front of a message — so the reader parses your intent instead of guessing it from their own mood.

require(risk):
stage rollout — prod exposure too high before Friday.
This isn't a suggestion. I need your risk read before we ship.

Examples

The same few words, different intents

Each message below is unambiguous the moment you read the tag — no tone to misjudge, nothing to reread at 11pm wondering if they're upset.

ask(advice):
should we ship Friday, or wait for QA?
Looking for your input. No pressure either way.
tell(decision):
shipping Friday. Rolled back the migration change.
Decision's made — letting you know, not asking.
require(feedback):
review this by EOD — need sign-off before I merge.
Not optional. I need your eyes on this today.
offer(clarification):
happy to walk through the diagram again if the arrows were confusing.
No judgment if this was unclear — I'll re-explain, just say the word.
ask(clarification):
what did you mean by "soon" — end of day, or end of week?
Genuinely uncertain what you meant, not being difficult.
tell(feeling):
frustrated with how many times this deploy process has broken this month.
Naming it so it's not left for you to read between the lines.

Why

Tone doesn't survive the trip through text

Spoken conversation carries tone for free — pitch, pace, a raised eyebrow, a pause. Text carries none of it. So the reader supplies the missing tone themselves, usually out of their own emotional weather rather than yours. A message written calm at 2pm gets read anxious at 11pm. A one-line reply meant as efficient reads as curt.

Most fixes for this ask you to write more: soften with an exclamation point, pad the request with "just wondering," apologize before you've even asked. That adds noise without adding signal — the reader still has to infer intent, just from a longer message.

Conventional Conversations asks you to write less, but write it explicitly. State what kind of message this is before you say it — the same way a commit states whether it's a fix or a feature before it says what changed. The tag carries the intent so the words don't have to perform it.

Specification

Grammar and rules

force(scope): message
  1. Every message MUST begin with a force, chosen from: ask, tell, require, offer.
  2. The force MAY be followed by a scope in parentheses naming the topic — advice, decision, feedback, info, clarification, risk, plan, feeling, or a term specific to your context.
  3. feeling names the category, not the specific emotion — the emotion itself belongs in the message. Write tell(feeling): frustrated with this deploy process, not tell(frustrated): ...
  4. The tag MUST be followed by a colon and a space, then the message.
  5. ask signals the sender is soliciting a response and has no expectation beyond that.
  6. tell signals the sender is stating something as settled from their side — no response required.
  7. require signals the sender needs the named content produced or delivered. It is a call for content, never for agreement with it — require(advice) means "give me your recommendation," not "obey it."
  8. offer signals the sender is making themselves available. It carries no obligation for the recipient to accept.
  9. Scope terms SHOULD be drawn from a list shared across a team, so tags stay legible to everyone reading them. Teams MAY extend the list for domain-specific needs.
  10. A message with no natural scope MAY omit the parenthetical and use the bare force — ask: got a minute?
On "require." It reads sharper than the other three by design — that's the point of tagging urgency explicitly instead of leaving it to punctuation. Once a team knows the definition in rule 7, the word does its job without carrying blame.
On "require(feeling)." Every other scope names something that can be produced on request — a decision, a number, a plan. A feeling can't be compelled the same way, so require(feeling) reads best as an invitation to self-report, not a demand: "give me an honest read on how this landed" rather than "give me your feelings by Friday."

Reference

The full matrix

Every force paired with every scope should read naturally in plain speech. Here's all 32 — check yours against it before adding a new scope.

scope \ force ask tell require offer
advice What should I do? I think you should do X. Give me your recommendation. Happy to weigh in if useful.
decision Have you decided? I decided X. Decide by Friday. I can make the call.
feedback Thoughts on my draft? Draft was clear — cut section two. Review this by end of day. I can review it if you want a second pair of eyes.
info What's the deploy time? Deploy's at 5pm. Send me the numbers. I can pull the numbers.
clarification What did you mean by that? To clarify, I meant X. Clarify this by tomorrow. Happy to clarify if it wasn't clear.
risk What could go wrong here? This risks downtime. Give me your risk read before we proceed. I'll flag risks as I spot them.
plan What's the plan? Here's the plan: … Send me a plan by Monday. I can draft a plan.
feeling How are you feeling about this? I'm frustrated with this. Give me an honest read on how this landed. I'm here if you want to talk it through.

Scope list is illustrative, not exhaustive — see rule 9. require(feeling) is the one soft cell — see the note above.

FAQ

Questions

Isn't tagging every message awkward?

Not every message needs one. Reach for it when the cost of misread tone is highest: async threads, cross-timezone handoffs, anything you'd normally soften with three exclamation points. Face-to-face and low-stakes chat don't need it.

What if none of the eight scopes fit?

Use the bare force with no scope (rule 10), or extend the list for your context. The four forces are meant to stay closed and small; scopes are meant to grow with the team using them.

Isn't "require" harsh?

It's a defined tag, not a tone of voice — the way fix in a commit message doesn't mean someone's to blame. Once a team knows require means "I need this content," not "obey me," the word does its job without the edge.