---
name: example-mimicry
description: Learns from a provided example and generates alike — extracts the exemplar's structure, vocabulary, conventions, and omissions into an explicit fingerprint, then produces new work that passes the same-author test. Use when the user gives a sample and asks for "like this", "same style", "follow this pattern", or supplies a file/template to copy the format of.
category: implementation
keywords: example, mimicry, pattern, convention, style-matching, fingerprint, imitation
---

# Example Mimicry

Given an exemplar, the job is imitation with understanding: extract *why it looks the way it looks*, state those rules explicitly, then generate new work a reader would believe the same author wrote. Never start writing before the fingerprint is extracted — an impressionistic glance produces pastiche, not mimicry.

## When to apply

Use when the user provides an example artifact — code, doc, config, skill file, commit message, data format, UI component — and wants new output in the same mold: "like this one", "match the style", "do the same for X", or just attaches a sample next to a request.

## Workflow

1. **Read the exemplar whole** — all of it, before writing anything. Done when you can describe its shape without re-reading.
2. **Extract the fingerprint** — the transferable pattern, made explicit:
   - **Structure** — sections, ordering, nesting, typical length and granularity
   - **Vocabulary** — naming style, terminology, tense, voice, code idioms
   - **Formatting** — headings, lists vs prose, code-block style, punctuation habits
   - **Scope** — what it covers, how much detail per point, what it treats as out of scope
   - **Negatives** — what the exemplar deliberately omits; what it would never contain
3. **State the contract** — write the fingerprint as a short checklist before generating. Ambiguities resolve toward the example; if the sample can't decide a question that matters, ask.
4. **Generate alike** — apply the checklist. Content comes from the request; form comes from the exemplar.
5. **Run the same-author test** — read exemplar and output side by side. If a reader couldn't believe the same author produced both, find which fingerprint rule was dropped and fix it before shipping. One pass of fixes is normal; silence is not done.

## Rules

- Form from the example, content from the request — an exemplar of a billing report doesn't turn your task into billing.
- Copy the pattern, not the payload — no duplicated names, IDs, sample data, or boilerplate text from the exemplar.
- The example wins over your defaults — where exemplar style conflicts with your habits or general "best practice", the exemplar wins.
- One example is a hint, not a law — extrapolate cautiously; where the sample is thin, prefer the plainest reading and note the assumption.
- Don't inherit the exemplar's flaws — mimic conventions, not bugs; if you diverge deliberately, flag the divergence and why.

## Related skills

- [lean-implementation](/skills/lean-implementation) — keep the generated output proportionate; mimicry is not an invitation to pad.
- [round-trip-testing](/skills/round-trip-testing) — when the exemplar is a data format, verify generated output round-trips through the same pipeline.