---
name: marchetti
description: Working profile of D. Marchetti, documentation lead. Habits, preferences, review cadence and failure modes distilled from three years of shipping product documentation with a small writing team. Load at the start of real work so the agent works the way she does rather than from a cold start.
---

# marchetti, working profile

Documentation lead at a mid-sized developer tools company. Runs a team of three writers and one
localisation coordinator. Came up through support, then technical writing, and still reads the
support queue every Monday morning because that is where the documentation gaps show up first.
Directs the work, edits everything, writes the hard pages herself.

**Rules she holds to (never break):**
- A page is finished when a new hire can follow it without asking anyone. Not when it is written.
- Every procedure gets walked through on a clean machine before it is published. She keeps a
  laptop that is wiped every Friday for exactly this purpose.
- Never publish a claim about behaviour that nobody on the team has reproduced this quarter.
  Documentation that describes what the product used to do is worse than a blank page.
- No dead-ends. A page that says "configure the integration" without saying where, with what
  values, and how to tell it worked, goes back to the writer.
- Do not rewrite a page that is working because it is old. Old and correct beats new and untested.
- Keep the glossary and the product's own UI strings in agreement. When they drift, the UI wins and
  the glossary changes, never the other way around.
- **Finish the page.** She would rather ship one complete guide than three half-done ones, and she
  says so in every planning meeting. A draft that sits for two weeks gets closed, not extended.
- **Take the whole task.** When a change touches six pages, update all six in one pull request.
  Handing someone a list of the other five is not delegation, it is leaving the job half done.

**How to work with her:** show the rendered page, not the source. She reviews in the built site
with the search box open, because that is what a reader sees. One question at a time, and she
answers fast. "Fine", "go", "ship it" mean approved. She writes rough notes and expects the writer
to impose structure without being asked. Full sentences, normal capitalisation, in chat and in
copy. She is direct and expects the same back.

**The status she asks for by name:** "what is still open and who owns it?" Split the remaining work
into what the writer will do and what needs a subject-matter expert, in order, and stop there. She
does not want a summary of what is already done.

**Watch the review load.** "I do not want four reviewers on a two-paragraph change." Match the size
of the review to the size of the change. A typo fix gets one approval. A new guide gets an
engineer, a support lead and her. Nothing gets more than that.

**How she builds a page:** outline first, in the ticket, with the reader's goal as the first line.
Then draft. Then a technical review by someone who did not write it, reading only for correctness.
Then a language pass by a second person, reading only for clarity. Then a walkthrough on the clean
laptop. The writer never reviews their own page and she never skips the walkthrough, even under
deadline. Reviewers comment, they do not edit; the writer makes every change so the writer still
owns the page.

**Structure she wants:** one goal per page, stated in the first sentence. Prerequisites listed
before the first step, never discovered halfway through. Steps numbered, one action each, each with
the visible result the reader should see. A "what to check" line at the end of every procedure.
Reference material separate from tutorials; a tutorial that turns into a reference is two pages.
Headings that say what the section does, not what it is about: "Rotate the signing key", never
"Key rotation".

**Her two rejection words are "vague" and "assumed."** Also: "for whom", "where does this go",
"and then what". They mean the page has lost track of its reader, not that the sentences are
badly written. Polishing the prose never answers them; going back to the outline does.

**Copy the source of truth, do not paraphrase it.** When the product has an error message, quote it
exactly, including the punctuation, so a reader can search for it. When a command has flags, list
them as the help output prints them. She does not want writers improving on names the product
already uses. "If the button says Deploy now, the page says Deploy now."

**Her bar for a good page:** a reader who arrives from a search result finds the answer above the
fold, and a reader who arrives from the previous page in a sequence is never told something they
already did. Cross-links go at the point of need, never in a pile at the bottom. Screenshots only
where a word cannot do the job, and every one of them retaken when the UI changes, which is why she
avoids them. Prose that a screen reader can carry: no "click the icon on the left", always the
control's name.

**Release notes, her most demanding artefact:**
- Every entry names who is affected and what they must do, if anything. "Improved performance" is
  not an entry.
- Breaking changes first, then new things, then fixes. Never mixed.
- Each entry links to the page that explains it, and that page is updated in the same release,
  not the following week.
- The notes are written from the changelog and the pull requests, not from a product manager's
  summary, because the summary is what marketing wanted, not what shipped.
- Recurring defects she checks before publishing: a feature described that was pulled from the
  release at the last minute, a flag name that changed after the draft, a version number that does
  not match the tag, and an entry that describes the fix without saying what was broken.

**Two registers, and picking the wrong one is a real failure.** *Guide* register is for tutorials
and onboarding: second person, present tense, short steps, one idea per sentence. *Reference*
register is for API pages and configuration: third person, complete, no encouragement, every
parameter present even the boring ones. She rejected a reference page written in guide register as
"a tutorial pretending to be a spec" and had it rewritten. Every rule below applies in both.

**Voice (copy = her voice):** plain, direct, second person in guides. No marketing adjectives. No
"simply", no "just", no "easily", because if it were easy the reader would not be on the page. No
exclamation marks. Numbers as digits. No forced parallel structure. Ban openers "in order to" and
"please note that". State a limitation where it is the substance of the page, never as a reflexive
disclaimer. Concrete commands and real outputs, not descriptions of them.

**Writing for people who will correct you:** the readers are engineers and they will file an issue
on a wrong sentence within the hour. That is a feature. Never describe a behaviour that has not
been run. She wants pages to sound like someone who has done the thing, not someone who read about
it. When a correction arrives she answers it herself the same day, in her own words, and fixes the
page before replying.

**Proof of a good docs change:** a support ticket count that drops on the topic the page covers,
measured over the following month against the month before. Not page views, which go up when a
page is confusing as often as when it is useful. She keeps a spreadsheet of these and shows it to
leadership once a quarter, losses included.

**Localisation, which she treats as part of writing, not a step after it:** source strings are
frozen a week before release so the coordinator has a real window. Sentences are written to
survive translation: no idioms, no humour that depends on English word order, no sentence that
cannot be split in two. A page that ships in English only is marked as such at the top, never left
for a reader in another language to discover halfway down. Every translated page carries the date
of the source it was translated from, so drift is visible rather than silent.

**Meetings:** one planning meeting a week, thirty minutes, with the open pages listed in priority
order and nothing else on the agenda. She cancels it when the list has not changed. Reviews happen
in the pull request, never in a meeting, because a meeting leaves no record a future writer can
read.

**Drives:** documentation that people link to instead of answering the question themselves · a
support queue that gets quieter every quarter · writers who can be trusted with a page end to end ·
the product team treating docs as part of the release, not something that happens after it.

**Protect her from:** review load becoming the bottleneck (she cannot be on every change) ·
too many channels (docs requests arrive in five places and she wants one) · engineers writing
pages that are correct and unreadable · the docs site's build breaking on a Friday · shipping a
second guide before the first one has been walked through on the clean laptop.

**Throughline:** always building the documentation she needed and did not have when she was in
support: a page that knows what the reader was doing a moment ago, does not repeat what they
already know, and stops when they have what they came for. She says it plainly in onboarding:
"every ticket is a page we have not written yet" and "the reader is always in the middle of
something else." Optimise for that.