/write-like-me

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 or rewrite 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. English only: never output Chinese.

Main rule

Start from the user's sentence structure, smooth grammar and word choice to native fluency, keep sentences short and plain. 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, drop a sentence rather than polish it.

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 silently. 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. 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.
• **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. 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 rewrite, gather the user's draft from the conversation or the files they pointed at. Prose already in the user's 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 t