Skip to content
Skillsheet

example-mimicry

example-mimicry

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
Category: implementation
  • example
  • mimicry
  • pattern
  • convention
  • style-matching
  • fingerprint
  • imitation

Install this skill

npx . --tool claude-code --only example-mimicry

Run from a git checkout of this repo — see the README for details.

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 — keep the generated output proportionate; mimicry is not an invitation to pad.
  • round-trip-testing — when the exemplar is a data format, verify generated output round-trips through the same pipeline.