Voice

Voice records how writing should read (a message to a colleague, a release note, an explanation back to you) and applies the matching style automatically. It learns from your corrections to your agent's drafts.

How it works

Voice has three pieces: claims, the groups they belong to, and the voice conditions that say when a group applies.

Claims are single statements about how something should be written: "opens with the ask, never with pleasantries", "no em-dashes", "sign off with just the first name". A claim says nothing about when it applies. Like a fact, it is either verified (you said so) or unverified (your agent inferred it), and it keeps its history when it's revised. (The MCP tools call a claim an atom.)

Groups are named sets of claims: how I write on Slack, the essentials that always hold, how I review a pull request. A group is the piece you reuse. Groups can also include other groups: "how I write on Slack" can include "how I write generally", so it brings those claims along wherever it is applied. A group only says what to write, never when.

Voice conditions say when a group applies. Each condition points at exactly one group and can set any of six axes:

Axis	What it is	Examples
Direction	who is writing to whom	your agent writing to you; your agent writing as you, to someone else; your agent writing a stored record such as a commit message
Audience	the person or group being written to	a colleague, or a group like "clients"
Act	the kind of message	a Slack post, an email, a pull request, a PR review, an issue comment, a Notion page, a commit message, a document, a reply to you
Language	the language being written	English, French
Situation	what is going on	an incident, a nudge, an announcement
Model	the AI model doing the writing	claude-*

An axis you leave open means any. A condition that leaves every axis open is your general voice, and it always sits underneath the more specific ones. (The MCP tools call a voice condition a register.)

The model axis works like a rule's Model check: a pattern matched against the model name your harness (the coding agent you use: Claude Code, the Claude desktop app, Oh-My-Pi) reports, such as claude-* or openai/gpt-*.

Applying a voice somewhere new

To apply an existing group in a new situation, create a condition that points at it. Nothing is copied: add a claim to that group and every condition pointing at it picks the claim up.

Deleting a condition stops applying that voice there and leaves the group intact, still applied everywhere else.

The same voice in every project

A condition belongs to one profile by default: the project you were in when it was created. Make it global and it applies in every profile, including ones created later. You can also name a specific set of profiles, the same way you scope a shared skill.

Claims and groups are shared across all your profiles either way; there is one copy of each claim and one place to correct it. The condition's scope decides only where the voice applies.

The audience axis

You never type the audience. It points at one of your persona subjects: a colleague, or a group like "clients". Rename someone later, or add a nickname, and the conditions still match. If you ask for a voice for someone who isn't in your social map yet, your agent adds them first.

People live in one profile, so a condition that names a person stays in the profile it was written in. Sharing it wider, or moving it to another profile, is refused, and the refusal names the person. Conditions that name nobody (how you write in French, how you review a pull request) can be shared freely.

Audiences also follow your social map. If Neuronz.ai knows Sam is one of your clients, a message to Sam picks up your clients voice automatically. If you've also described how you write to Sam specifically, that condition wins: a voice for the person always outranks the voice for their group.

Which voice wins

The more axes a condition sets, the more specific it is, and more specific wins. The everything-open condition always ranks last.

A group that is only included by another takes its place from whatever brought it in, directly beneath that group. If two situations both include the same group (say, "how I write generally"), it ends up under both, and the situation-specific claims win where they differ.

If two conditions of the same specificity apply to the same situation and disagree, your agent is told about the conflict, and the group declared first wins.

Nothing is set up in advance. A profile with no conditions gets no voice guidance; groups and conditions are created from your own words the first time you say how something should read.

How it reaches your agent

Writing to you. On every prompt your agent gets a short note, not the voice itself: which voices apply, how many claims they hold, and an instruction to fetch the full voice with get_resolved_voice before its first reply. Your agent passes the name of the model about to write (or unknown), so a voice set for one model resolves correctly. Neuronz.ai remembers which voice your agent fetched in this session, so the note says plainly whether it already holds the current voice, the voice changed since it fetched it (you corrected a claim mid-session), or it has not fetched it yet. Only the last two ask it to fetch again. After your harness compacts the conversation, the note asks for a fresh fetch, since the earlier one may be gone.

Situation-bound voices, such as how reports should read during an incident, depend on a situation only your agent can judge. They are listed by name, each with the condition that brings it into play, and your agent is told to check the list before drafting and fetch that voice when its condition holds. When one applies, it outranks the everyday voice.

Writing to someone else. When your prompt looks like it involves writing to or about someone, your agent gets the list of conditions you have and an instruction to work out who the message is for and fetch that voice before drafting. When a message is about to go out through a tool, the voice is checked once more at that moment. That covers Slack (Slack's own server and the common community ones), email, GitHub and Gitea pull requests, reviews and issue comments, and Notion pages and comments. In omp this last check does not happen, for the same reason rules are not checked right before a tool call there (see harness parity).

What your agent receives

The claims themselves. Each condition that applies sends its group's claims as a short list of writing rules, grouped by tone, mechanics and structure. What you see on a group is exactly what gets sent, so an edit takes effect on the next message.

Groups can also hold examples: real messages in that voice, kept word for word. They travel with the claims.

When more than one condition applies, the groups are listed most-specific first, with a line saying that the earlier one wins where two disagree.

How it learns

• You correct a draft: the correction is saved as a verified claim in the group it belongs to and applies from then on, everywhere that group is applied.
• Your agent notices a pattern: it saves an unverified claim instead. That one is never applied. It waits for a moment when it would actually have mattered, then your agent asks you about it once, in passing.
• You answer: yes, and it becomes verified. No, and it's dropped and remembered as dropped. Or "right, but with everyone, not just them": the claim is kept and moved to the wider group, so it applies everywhere that group already does.

Your agent organises groups and conditions for you; you can ask for a specific arrangement, but you don't need to.

Setting one up on purpose

Most of the time you don't set anything up: you correct a draft and the correction sticks. When you want to state a voice outright ("from now on, write my pull request descriptions like this", "be blunter with Marie", "explain things back to me in French"), just say so. The plugin includes a voice-register skill your agent uses on its own for this.

Your agent reads what you already have first, so a voice you've described before is reused (one new condition pointing at the existing group) rather than copied. It keeps the when out of the claim, adds the person to your social map if you named someone new, picks the scope, and then checks that the voice applies in the situation you described. If two voices end up tied for the same moment, you're asked which one should win.

Keeping the claim and the condition apart

A claim should not contain its own condition: "speak plainly when you're talking to Marie", filed in your general group, would apply to everyone.

So when a claim names one of your colleagues, a kind of message, or a language that no condition on its group covers, it is still saved, but your agent gets back a suggestion: which words to move and into which condition. The check never blocks a write.

What it doesn't do

• Voice is not searched or recalled like your facts and documents. It is chosen by situation, never by similarity.
• Voice is not a rule. A rule is something your agent must obey. Voice governs how something reads. The test: if breaking it produces badly written output, it's voice; if it produces the wrong action, it's a rule.
• Voice never applies a guess. Anything your agent inferred stays out until you confirm it.

MCP tools

• Claims: add_voice_atom, update_voice_atom, delete_voice_atom, bind_voice_atom, unbind_voice_atom.
• Groups: add_atom_group, list_atom_groups, get_atom_group, update_atom_group, delete_atom_group.
• Voice conditions: add_register, list_registers, get_register, update_register, delete_register.
• Fetching and asking: get_resolved_voice, get_voice_ask, resolve_voice_ask.

See MCP tools.