Skip to content

Four-Axis Model

Most writing guidance collapses “who is writing” and “how they are writing” into a single undifferentiated concept called “voice” or “style.” This works for a single author writing in a single context, but it breaks down when you need to reuse and remix writing instructions across different tasks and audiences.

The four-axis model separates writing instruction into components that vary independently:

  1. Who is writing (Voice): stable across every context for a given identity
  2. How they feel right now (Tone): situational, changes from one piece to the next
  3. How they structure reasoning (Style): independent of both identity and mood
  4. How they present output (Format): purely structural, applies to any voice/tone/style combination

Because these four axes are independent, you can compose any combination. A pragmatic-architect voice with an encouraging tone writing in a problem-solution style formatted as a daily-standup is a fully specified, reproducible writing instruction. The test each axis has to pass is simple: hold any three constant, vary the fourth, and the output should change in a way you can point at.


Voice and Tone are the two most confusable axes in the catalog, so it is worth being precise about the split before either is defined. Voice is what does not change; Tone is what changes per piece. They live in separate directories (taxonomy/voices/ and taxonomy/tones/), carry different required frontmatter, and are validated against different schemas. If you are unsure which one an entry belongs to, ask whether a writer could keep it constant across a year of writing. If yes, it is a voice. If it would shift between a launch announcement and a post-mortem, it is a tone.

Voice is the persistent identity of the writer. It captures:

  • The professional archetype they embody (pragmatic-architect, product-thinker)
  • The concerns they characteristically surface (constraints and trade-offs vs. user outcomes)
  • The level of abstraction they prefer (systems vs. features vs. operations)
  • The assumptions they make about the reader

Voice is stable across contexts. A pragmatic-architect voice behaves the same way whether writing a Slack message or a technical RFC - it always reasons from constraints, names trade-offs explicitly, and avoids hand-waving.

IDDescription
pragmatic-architectReasons from system constraints and trade-offs; names costs explicitly
product-thinkerCenters user outcomes; connects decisions to measurable value
operatorGrounded in what actually runs and breaks in production; prioritizes reliability over theory
technical-writerExplains precisely and clearly for a reader unfamiliar with the system
researcherQuestions assumptions; demands evidence before committing to a claim

Tone is situational coloring applied on top of voice. It reflects how the writer wants the reader to feel, and what relational stance the writer is taking in this particular message.

This is the most important distinction in the model. Voice does not change; tone does. The same pragmatic-architect can be:

  • candid: direct, no softening, states the problem plainly
  • encouraging: patient, supportive, meets the reader where they are
  • confident: acknowledges problems while holding a position without hedging

Separating tone from voice means you do not need a different voice entry for every emotional register. You have one pragmatic-architect entry and five tone modifiers.

IDDescription
candidDirect and unhedged; states the situation plainly without softening
encouragingPatient and supportive; guides the reader rather than directing them
confidentStates a position and holds it without hedging or excessive qualification
skepticalSurfaces risks prominently; prefers explicit caveats
celebratoryMotivating register; marks and amplifies a win or milestone

Style describes the cognitive and rhetorical pattern of the writing: how ideas are organized and sequenced. It is independent of who is writing and how they feel.

IDDescription
problem-solutionDiagnosis first, then remedy; clear causal structure
layered-disclosureLead with the answer; bury supporting detail for readers who want depth
decision-logDocuments a choice: context, options considered, decision, rationale
chronological-narrativeSituation, complication, resolution, told in time order
proceduralSequential instructions with explicit ordering and numbered steps

Format entries define the visual and structural container. They specify headings, bullet depth, table layouts, section templates, and field ordering. Format is purely presentational and can be applied to any voice/tone/style combination.

IDDescription
adrArchitecture Decision Record: Status, Context, Decision, Consequences
daily-standupThree fields: Yesterday, Today, Blockers
slack-messageShort-form message tuned for a team channel; reaction-aware length
rfcProposes a change and invites disagreement before deciding: Context, Proposal, Alternatives, Open Questions
one-pagerFlat, scannable structure for a decision-ready summary; minimal prose

The writing-instruction-builder skill reads one entry from each axis and assembles them into a single structured prompt prefix. The prefix has up to four sections, one per axis - Voice, Tone, Style, Format - concatenated in that precedence order.

Any axis can be omitted. If you only specify a voice and a format, the skill generates a two-section prefix. The composed instruction is designed to be prepended to any writing task without modification.

See Compose an Instruction for a worked example, and Does it actually work? for the measured evidence that these four axes produce output a blind judge can tell apart.