build-write-like-me

Files (7)

• SKILL.md
• agent-content-filtering.md · references/
• profile-template.md · references/
• source-gathering.md · references/
• analyze_style.py · scripts/
• extract_transcripts.py · scripts/
• fetch_github.py · scripts/

SKILL.md (first lines)

# 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

From ronaknnathani/relay, MIT.

More from ronaknnathani/relay