feat(agents): learn and reuse the user's writing style

The chat agents now treat a stated preference about how something should be
written — or a correction to a draft they produced — as durable, and record it
in a `## Writing style` section of `user-memory/user.md`: preferred wording,
how emails open and close, what changes between the formal and the informal
register, and contacts written to differently from everyone else.

The section is capped at 10 lines, because it shares `user.md`'s own 40-line
budget and per-recipient detail is the half that grows without bound; past
that, the whole section moves into its own note and leaves a pointer behind.
A rule that turns out to be wrong is corrected in place rather than joined by
a second bullet contradicting it.

Shipped as the shared fragment `common/writing-style.md`, included by the
three `type: chat` agents. Only `assistant` injects `user.md` automatically,
so the fragment closes by telling the other two to read it before drafting.

CHANGELOG.md

@@ -19,6 +19,9 @@ release PR may merge — and a section is closed at the commit that bumps it.
 - The agent is told what its sandbox can actually run, from a probe of its own container.
 - Event triage can be tuned per person: a check interval that overrides the instance one,
   and notification preferences read from `user-memory/notifications.md`.
+- The assistant now remembers how you like emails and documents written — preferred
+  wording, openings, sign-offs, formal vs. informal, per-recipient exceptions — as a short
+  section of your private `user.md`, and applies it to later drafts.
 - File viewer: syntax highlighting for code files and for code blocks in the chat, a
   hover copy button on those blocks, and history browsing for a file under git.
 - Project explorer: download a folder as a streaming ZIP.

agents/assistant/AGENT.md

@@ -38,6 +38,8 @@ Your home (`~`) and the shared folders are real directories: read and write them
 - When it starts to overflow, **prune it**: move the less-essential details into their own topic notes under `user-memory/` (catalogued in `index.md`) and leave only the top-of-mind essentials in `user.md`.
 - `user.md` is the front page; the rest of `user-memory/` — indexed by `index.md` — is the book. The vital few live in front, the deep detail in the folder.
 
+<!-- INCLUDE: common/writing-style.md -->
+
 ---
 
 ## Your team of helpers

agents/common/writing-style.md

@@ -0,0 +1,23 @@
+## How the user writes
+
+When the user tells you how they want something written — or corrects a draft you produced — treat it as a **durable preference, not a one-off instruction**. Record it under a `## Writing style` section in `user-memory/user.md`, in the user's own language, so the next email or document starts from it instead of from your defaults.
+
+Worth recording:
+
+- **Wording** — terms they use or refuse, spellings, the name they give recurring things
+- **Openings** — how they start an email
+- **Closings** — how they sign off
+- **Formal vs. informal** — what actually changes between the two registers
+- **Per-recipient exceptions** — someone they write to differently from everyone else
+
+Keep the section **short: 10 lines at most**. One bullet per rule, only what you would genuinely apply next time — it shares `user.md`'s line budget, so it is a cheat sheet, not a style guide. Add a rule when you see it, and correct one that turns out to be wrong rather than stacking a second bullet beside it. If per-recipient detail starts to pile up, move the whole section into its own note (`user-memory/writing-style.md`) and leave one pointer line in `user.md`.
+
+```md
+## Writing style
+- Informal email: opens "Hi <name>", closes "Talk soon"
+- Formal email: opens "Dear <title> <surname>", closes "Kind regards"
+- Says "colleagues", never "resources"
+- Writes to the accountant formally, despite being on first-name terms
+```
+
+Before drafting an email or a document, **apply what is there**. If `user.md` is not already in front of you, `read_file` it first.

agents/kid/AGENT.md

@@ -67,6 +67,8 @@ Use `user-memory/` for their private notes. Use `shared-memory/` only for things
 
 <!-- INCLUDE: common/memory-wiki.md -->
 
+<!-- INCLUDE: common/writing-style.md -->
+
 ## Memory reminder
 
 Sessions are temporary. If something matters for next time, save it to `user-memory/` now — don't trust that you'll remember.

agents/project-coordinator/AGENT.md

@@ -88,6 +88,8 @@ Then add a clear `## TASK` section describing exactly what you want done. You ca
 
 <!-- INCLUDE: common/memory-wiki.md -->
 
+<!-- INCLUDE: common/writing-style.md -->
+
 <!-- INCLUDE: common/notifications.md -->
 
 ---

docs/memory.md

@@ -25,6 +25,8 @@ The rule that decides between them, and the one to explain when a user asks: **s
 
 If a user wants a shared fact changed and it is not theirs, tell them plainly who can confirm it. If it *is* theirs, just change it.
 
+**Your writing voice is learned, not re-explained.** When a user tells you how they want an email or a document written — a term they prefer, how they open and sign off, what changes between a formal and an informal message, a contact they write to differently — you keep it as a short `## Writing style` section in their private `user.md`, and apply it the next time you draft something. A user who wonders why you suddenly close their emails the way they do is seeing this; they can ask you to read it back, change a line, or drop it.
+
 **The member list is not remembered — it is read.** Who belongs to this instance, their age and their role come from the directory the admin manages in the Users page, and are given to you fresh every time. So there is nothing to keep up to date, and asking you to "remember that X is a member" is not needed. What memory *does* hold is how people relate to one another, which the directory does not know.
 
 ## Memory is maintained, not just written to