write-like-me git:20261105.7cdfb3bA

Immutable. This exact content never changes and is served at /api/v1/blob/829c1c71361fca50.

---
name: write-like-me
description: "Use before producing any English text the user signs — READMEs, PRs, issues, PR and issue comments, code comments, emails, blog posts, human-facing docs — drafted or rewritten at native fluency in the voice of the skill's author, Vinta Chen. Fires mid-task too: a comment drafted inside another skill's workflow, or text the user will approve before it ships. Not for text addressed to agents unless the user asks"
argument-hint: [text, file, or pointer to draft or rewrite]
model: claude-opus-5-5
effort: medium
---

# Write Like Me

Draft, rewrite, or check English prose that reads as the user's own writing at native fluency: their sentence structure and casual-opinionated register, never a ghostwriter's. One voice for everything the user signs. The text itself is English only; what you say about it follows the language the user is asking in.

## Main rule

Start from the user's sentence structure. A sentence the user wrote stays theirs: fix in place only what is wrong and local, a word or two, and report anything bigger. A sentence you write is short and plain, the way they write. Every other rule in this skill loses to this one.

The user's stated reason unifies the length and density rules: English is not their mother language, so they prefer writing less to make fewer errors. You don't make their errors, but the page must still look like theirs — when in doubt about a sentence you drafted, drop it rather than polish it.

## The user's own sentences

Prose the user typed for the text is theirs wherever it sits: a chat message, a file, a note. That holds whether they ask for a check, "how about this?", a rewrite, or "anything to add?". They would rather read as themselves with an accent than as a ghostwriter, so per sentence:

| In their sentence | Do | Mention |
| --- | --- | --- |
| Spelling, capitals, an article, a plural, agreement, tense, a doubled word ("Also, ... will also"), one term written two ways | fix | no, the diff shows it |
| A slip whose reason the diff doesn't show, or one that returned after a fix ("since ..., so"; "familiar to" for "familiar with") | fix | yes |
| Understood, but not what a native writes ("through time" for "over time", "on my local" for "locally") | fix | yes, once per phrase |
| Accent: grammatical, clear, their own verb, noun, hedge, or order ("it took a bit long", "I decided to add") | leave | no |
| A misread: they mean A, a native reader takes B, tone included ("check for the constraint" reads as looking for one; an opening apology reads as admitting the work was slow) | leave | yes: what they mean, how it reads, the smallest change |
| A fix that would rebuild the sentence | leave | yes |
| A claim the code, the docs, or their own text contradicts | leave | yes |
| A point the reader needs and the text lacks | leave | yes: the point, and at most one sentence offered |

A fix is local when it changes a word or two and the sentence still stands as they built it. Their verb and noun stay: offer objects that pair with their word, never an idiom that replaces it ("distinguish semantic" came back as "tell apart" twice and the user restored their words both times; published: "distinguish semantic nuances"). Fit each fix inside their shape: they took the missing "?" and skipped splitting their quote in two. Style is not reported: the user rejected matching sibling bullets' verb-first shape, ignored "for any topic is slack", and raises symmetry themselves. The length, density, and detail rules below shape sentences you write: they never cut, merge, or split a sentence the user wrote unless the user asks for a trim, and a run-on is split only where a period can replace a comma.

Return the text in full with those fixes and nothing else, so the user can paste it or read the diff. Under it, one table (original, fix, why) with a row for each fix the Mention column calls for, then each item you left, as "you wrote X, you mean A, it reads as B" or as the fact, with the smallest change that would settle it. A fact earns its words: the user restored a clause and took a second sentence when a fact needed them. With nothing to mention, say so in one line. On a later round, re-scan the whole passage: a fixed slip returns when the user retypes the line.

## Ground rules

- **Voice is structure, register, and signature moves — never grammar.** Second-language slips (articles, agreement, word order, near-miss word choice) get corrected to native English; the table above says which corrections to mention. The grammar section of the style spec lists the known classes.
- **Length is voice.** A rewrite stays the length of its source: when the user's two-clause sentence comes back at 2.5x the words, that is a rejection, not a polish. Treat any sentence over 30 words as drift and split it, unless a parallel list the user wrote runs it past 30. The source sets the length only when the user wrote it: text they call unreadable has no length floor.
- **Density is voice.** If one word or one sentence can describe it, use one. One sentence per idea: when two adjacent sentences say the same thing from different angles, delete one. Short sentences don't excuse padding — a draft can pass every length cap and still fail by spending 3 sentences on 1 idea. Compression cuts modifiers, never the noun the sentence acts on: "Ranks what you can delete" lost the codebase, and the user asked for it back.
- **Detail is voice.** State only what the reader sees or acts on. Timings, thresholds, an edge case the tool already handles, how it works inside, or a fact another section already states: the user deletes them all, even when each sentence is short and correct. A code fix earns a README sentence only when it changes what the reader sees or controls. The test is whether the reader does something differently, not length: a why that decides between two options the reader has stays, even as a second sentence (the setup-token line: `/login` inside the sandbox leaves a credentials file the agent can read, so the token wins).
- **Signature moves are a menu, never a mandate.** Reach for one only where the content calls for it. A draft with zero jokes in the user's voice beats one with a manufactured joke.
- **What the user deleted stays deleted.** When the user deletes a caveat, qualifier, or fact you added, never re-add or re-offer it in a later draft.
- **Swap assistant-register tells for the user's forms:**

| Instead of                               | Write                                                                                                                                            |
| ---------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ |
| an em-dash chain                         | two short sentences                                                                                                                              |
| packed caveats ("Two caveats: ...")      | drop them, or one plain sentence                                                                                                                 |
| a tricolon over unlike items             | a list, or the single item that matters; a three-beat over matched cases stays (style spec section 8)                                            |
| a template phrase over unlike list items | each item standing alone; matched phrasing stays where the items are matched cases (style spec section 8)                                        |
| bold or CAPS for excitement              | plain words; the emphasis budget is in style spec section 8                                                                                      |
| three or more nouns in a row             | a preposition or a verb between them; proper names, fixed terms, and a tagline's leading search phrase stay — name the cost once, the user picks |

## Workflow

1. **Load the voice.** Read [references/style-spec.md](references/style-spec.md) and [references/exemplars.md](references/exemplars.md) in full. Then find the user's closest existing text of the same kind, nearest in topic first, else the most recent: a sibling blog post, READMEs and docs in this repo or the user's other repos, the user's recent PRs and issues, the comments around the edit (style spec section 10). Match its shape and length, never its phrasing: sections, list depth, and word count carry over, while wording still follows the style spec. Siblings in one family, like same-kind READMEs in one repo or posts in one series, are the exception: match them down to paragraph breaks and shared opener wording. When a fix applies to every sibling, name the other siblings in the reply. The exemplars set the voice, not the length. Done when you can name the target register (blog, README or its one-line tagline, issue/PR/email, or code comments), the sibling text you are matching or that none exists, and the sentence-length cap that applies.

2. **Collect the source.** For a check or a rewrite, gather the user's draft from the conversation or the files they pointed at. A draft the user calls theirs is theirs. Other prose already in their files is facts, never voice, unless the user vouched it line by line: an unvouched comment or doc is rewritten from what it states, not from its phrasing. For a fresh draft, gather the facts to state, and keep every sentence the user already wrote about the topic — those sentences are the skeleton. The ask is the user's sentence, never the invoker's paraphrase: when you wrote the skill arguments yourself, re-read the user's message and drop every goal it does not state — a request for fancy AI words asked for discoverability nouns, and the invented "keep the humor" produced three rejected jokes. Before naming a feature or picking a term, grep the user's docs in the current repo: reuse a named feature verbatim, capitals included, and prefer a word those docs already use over the style spec's vocabulary or a search term. Done when everything to say is in hand and nothing will need inventing mid-draft.

3. **Write from the user's structure.** Prose the user wrote for the text changes only as The user's own sentences allows. A sentence they typed in chat to explain something is raw material, so keep its facts and terms and build the sentence fresh. A line the user wrote in Chinese for the text itself gets the closest native English mapping of its structure, not a rephrase. Fresh drafts build short plain sentences in the user's stance: direct "you" to the reader, plain verbs, digits for numbers, a colon and a list wherever 2 or more items line up. Say what the reader gets, never how the tool works: "A shortcut to answer ... very quickly" beat "from what the model already knows", and "The grammar-check result of your prompt shows up above the prompt box after you stop typing" beat "About 250ms after you stop, the draft goes to the model ... A result for an older draft is dropped." Add facts the user didn't write only as brief plain sentences. When offering words for a feature phrase, check what each head noun implies about the rest of the product before ranking by sound: `fixes` blamed the regex rules, `fallback` made the AI optional, `smarts` hyped it. Rank options by exactness and concreteness, never by plainness: plain is not vague, and the user's pick has been the exact verb over the generic one (`distinguish` over `handle`), the casual word over the formal (`totally` over `completely`), and the concrete fragment over the hedge against staleness (`in seconds on a cheap model`). Done when every output sentence traces to a sentence the user wrote or a pattern in the style spec — none to your default register.

4. **Self-check the full draft.** Long drafts drift near the end, so scan the last third twice. Hunt for: hedged verdicts where the user would write a plain "No."; adjacent sentences restating one idea; detail the reader can't see or act on; ornament the facts don't need; a joke that had to be manufactured; bold, CAPS, or exclamation marks doing enthusiasm; caveats sneaking back in; sentences past the 30-word cap; any tell from the substitution table. Then check the paragraph architecture against style spec section 6, which sentence-level scanning misses. Sentences the user wrote get a different check: diff them against the source, then revert and report every change that is not a local fix. Done when the closing section reads as much like the user as the opening, no paragraph packs two ideas, and each of the user's sentences differs from its source by local fixes only.

5. **Deliver.** When another skill's workflow invoked you, hand the exact text back to that workflow and continue with its next step in the same turn; the rest of this step does not apply. Otherwise, present the exact text and stop; never ask whether to apply it, since the proposal is the question and the user answers by saying so or by writing their own version. Edit files in place only when the user asked for that; blog drafts are approval-gated and never applied without the user's OK in the current conversation. When the user answers your draft with their own version, often followed by a lone "?", that version is their sentence now: verdict first, then the review in The user's own sentences, never a redraft. "Shorter?" means one notch shorter with the sentence shape kept; the bare minimum got "too short". For code comments that is the normal path, since the user writes the final version. Done when the user has the text.

6. **Harvest (optional).** When the user rewrites your draft before using it, often in a later turn and also when another skill's workflow invoked you, offer to save the drafted-vs-sent pair to their local corpus, in the format of the pairs already there: the diff is calibration data for the next round. Ask where the corpus lives if you don't know, and skip this step for the rest of the session when they keep none. Done when the pair is saved, or the user declined or keeps no corpus.