Write-Like-Me Builder

This skill builds a personalized writing-voice skill for one person. The output is a SKILL.md that any agent can load to draft or edit prose in that person's voice. You produce it by gathering the person's real writing from sources they provide, analyzing it (both statistically and by reading it), and synthesizing a profile grounded in real examples.

The core principle: a voice profile is only as good as the real writing behind it. Don't invent traits. Every claim in the generated skill should trace to something the person actually wrote. Quote them verbatim wherever you can.

The workflow

1. Collect sources from the invoker (interactive prompt).
2. Set up the workspace (an output skill dir with a source/ subdir for raw data).
3. Gather raw data into source/: {{subagent:large_context}} for delegated source workers where available, and use bundled scripts.
4. Analyze the data: run stylometrics, filter out content the person didn't actually write, and extract verbatim voice samples per register.
5. Synthesize the personalized SKILL.md voice profile.
6. Self-consistency check and present.

Do these in order. Steps 3 and 4 are where delegated workers do the heavy lifting so the raw data never floods your context.

Step 1: Collect sources

Ask the invoker which sources they want to include using whatever user-question mechanism is available (multi-select if supported; otherwise ask a concise numbered question). Don't assume anything about their environment or what's installed — different users have different MCP servers and skills. Offer:

• GitHub — PR descriptions and review/issue comments they authored. Need their GitHub login and the org(s)/repo(s) to search. Usually the richest source of working voice.
• Google Docs — design docs, proposals, strategy docs, feedback. They provide doc links/IDs or a folder.
• Local filesystem — a blog repo, a docs directory, exported notes, an .mbox, a Slack export, anything on disk. They provide the path(s). Always offer this — it is the most portable source and sidesteps every tooling gap.
• Session transcripts — their own typed messages to coding agents. Great for the casual/chat register. Yes/no.
• Slack — yes/no.
• Email — yes/no.

If the invoker already named sources in their request, confirm and fill gaps rather than re-asking everything.

Discover capability before fetching (don't assume the environment)

Sources that need a tool to fetch (Google Docs, Slack, email, GitHub) are only usable if that capability exists in this environment. So for each source the invoker asked for, check first, then act, and degrade gracefully:

1. Check whether a tool or skill can fetch it.
   • Inspect the available MCP tools/capability list for relevant fetch/read/search capabilities (e.g. "google docs read", "slack messages search", "gmail email messages", "github").
   • Scan the available skills list for a relevant fetcher.
   • For GitHub, also confirm gh auth status works for the target host.
2. If a capability exists, use it (see Step 3 and references/source-gathering.md).
3. If not, skip that source, record it, and continue with everything else. Never let one missing source block the analysis. At the end, tell the invoker which sources were skipped and why (e.g. "Slack: no Slack fetch tool available in this environment"), and how to add it later (a local export almost always works, so point them back to the local-filesystem option).

Local-filesystem paths and bundled-script sources (transcripts) don't need this check — they only need a path or the local transcript dir.

See references/source-gathering.md for the exact how-to and gotchas per source.

Step 2: Set up the workspace

Decide where the generated skill goes (ask, or default to a directory named write-like-me/). Inside it, create a source/ subdir to hold all raw gathered data:

write-like-me/
├── SKILL.md            <- the generated voice profile (final output)
└── source/             <- raw data, kept for transparency and re-runs
    ├── github/
    ├── gdocs/
    ├── transcripts/
    └── notes/

Keeping the raw data lets the invoker audit what the profile was built from, and lets you re-run the analysis later without re-fetching.

Step 3: Gather raw data

For each chosen source, fetch the raw data into source/. For large fetches: {{subagent:large_context}} with one worker per source (or per batch) so raw data does not fill your context. Use the bundled scripts for the fiddly parts.

• GitHub — scripts/fetch_github.py handles authoring + commenting, descriptions + comments, with rate-limit backoff and agent-content tagging. Run it from the assigned source worker (or inline for a small fetch) and write JSON into source/github/. Read references/source-gathering.md first — GitHub's search API rate-limits aggressively and the script encodes the safe pattern.
• Google Docs — only if a Docs-reading tool/skill exists (capability check in Step 1; commonly a document-reading MCP tool). If it does: {{subagent:large_context}} for each batch of ~3-4 doc IDs; each worker reads via the available Docs reader (use the full_text field, ignore the verbose element map), assesses authorship, and returns distilled voice notes + verbatim quotes into source/gdocs/. If no Docs capability is available, skip and note it (or ask for an export/local copies).
• Local files — read the markdown/text directly; for large file sets, start delegated workers: {{subagent:large_context}} to summarize voice per file. Save to source/notes/. This path also handles any export the invoker drops on disk (mbox, Slack JSON, etc.).
• Session transcripts — scripts/extract_transcripts.py pulls the person's own typed messages and filters out noise (commands, tool results, pasted dumps, templated agent prompts). Output to source/transcripts/.
• Slack / email — only if the Step 1 check found a usable capability. Use whatever Slack/email MCP or skill is available to pull the person's own messages, or parse a local export they provided. If neither exists, skip and tell the invoker it couldn't be fetched, then continue with the rest.

Always save the raw data to disk before analyzing. That is the reference/source directory the invoker can inspect.

Step 4: Analyze

Two complementary passes. Do both.

a) Statistical (stylometrics). Run scripts/analyze_style.py over the gathered data. It computes, overall and per register: em-dash and semicolon frequency, lowercase-sentence-start rate, average sentence length, question rate, contraction rate, exclamation rate, top sentence openers, and filler-word counts. These numbers anchor the profile in fact (e.g. "essentially zero em-dashes", "~60% of review comments start lowercase", "average sentence dropped from 24 to 18 words over time").

b) Filter out what they didn't actually write. This is critical. Modern PRs and docs are often agent-assisted, and including AI-generated text poisons the profile. Exclude:

• comments/PR replies made on their behalf by a coding agent,
• PR descriptions for agent-written code,
• AI-edited passages.

references/agent-content-filtering.md has the heuristics (attribution markers, the "fixed in <sha> + polished mechanism" auto-reply pattern, em-dash-as-AI- tell, templated PR bodies). The scripts tag suspected agent content; you decide the cutoffs and can eyeball borderline cases.

c) Read for voice. Numbers don't capture voice. For large cleaned corpora: {{subagent:large_context}} to read; otherwise read inline. Pull out, per register: 4-6 verbatim sentences that best capture the voice, structural patterns, tone, and signature phrases. The verbatim quotes are the single most valuable thing in the final profile.

Group by register (chat vs. code review vs. design doc vs. feedback vs. blog vs. email). The same person writes very differently by surface, and the generated skill must capture that. Also look for evolution over time if the data spans years; if the voice shifted, target the current voice.

Evaluate these dimensions separately for each register:

• Authorial perspective: when the person uses personal "I", collective "we", direct "you", or an impersonal construction. Don't turn collective "we" into a default without evidence from that register.
• Editorial framing: whether they use or avoid announcing significance, narrating the writing or structure, fragment-style payoffs, manufactured intensity, and copywriter cadence.
• Self-promotion and bragging: whether they let facts and outcomes carry the claim or use self-promotional superlatives and status language.
• Claim scope: whether technical recommendations are contextual to stated constraints or presented as universal rules.

Every supported finding needs register-specific evidence: at least two quotations, or a quotation and a counterexample that shows the boundary. Absence isn't evidence that the person prohibits a pattern. If the corpus is mixed, mark the conclusion uncertain. If evidence is insufficient, omit the conclusion. Never assign collective "we", anti-hype guidance, or company-specific assumptions universally.

Step 5: Synthesize the SKILL.md

Write the personalized voice profile following the structure and guidance in references/profile-template.md. In short, the generated skill should contain:

• frontmatter (name + a pushy, specific description),
• voice in one paragraph,
• non-negotiable mechanics (the rules that, if broken, shatter the illusion),
• a register map (how their tone shifts by surface),
• the moves that make it sound like them,
• register playbooks with verbatim examples,
• signature phrases,
• anti-patterns ("what is NOT their voice"),
• an editing mode and a pre-send checklist.

Write it as an actionable guide to an agent that will write as the person, not as an academic description. Genericize away the person's company/system/internal names unless the invoker wants them kept (a voice profile should travel).

Route each supported finding to the section where an agent can act on it:

• Put perspective differences in the register map and the matching register playbooks.
• Put positive editorial habits in voice rules or characteristic moves, backed by a concrete example.
• Put prohibited tendencies in anti-pattern guidance with a real counterexample and a direct alternative.
• Put rules that apply at send time in the pre-send checklist.

Don't add a section or rule just because it appears in this builder. Omit unsupported traits. Preserve material uncertainty when the evidence is mixed, and don't turn one company's context or one register's habits into universal guidance.

Step 6: Self-consistency check and present

The generated skill must obey its own rules. If you concluded the person never uses em-dashes or semicolons, the skill itself must not use them (a no-em-dash guide riddled with em-dashes is self-defeating). Grep the output for its own mechanical rules and fix violations:

grep -c '—' write-like-me/SKILL.md   # expect ~0 if they avoid em-dashes
grep -c ';'  write-like-me/SKILL.md

Then tell the invoker: where the skill is, what sources fed it, what you excluded (and why), and any gaps (e.g. "Slack wasn't usable, here's how to add it later"). Offer to draft a sample in one register so they can sanity-check the voice.

Bundled resources

• scripts/fetch_github.py — robust GitHub fetcher (authored + commented PRs; descriptions + comments; rate-limit backoff; agent-content tagging).
• scripts/analyze_style.py — stylometrics over gathered data, overall and per register, with agent-content filtering.
• scripts/extract_transcripts.py — pull a person's own messages from local coding-agent transcripts.
• references/source-gathering.md — per-source how-to and gotchas.
• references/agent-content-filtering.md — heuristics to exclude content the person didn't write.
• references/profile-template.md — the structure of the generated profile and detailed synthesis guidance.

Notes on doing this well

• Subjective skill, no rigid evals. You can't unit-test a voice. The quality bar is "would the person recognize this as how they write?" Verbatim examples and accurate mechanics matter more than any score.
• Delegate reading, synthesize yourself. Reading 20 docs or 500 comments in your own context is wasteful and lossy. For large corpora, start reader workers: {{subagent:large_context}} and have them return distilled analyses; you keep the conclusions, not the dumps.
• Be honest about gaps. If a source was unusable or thin, say so in the handoff rather than papering over it with invented traits.