Voiceprint — forensic voice-fingerprint extraction

What this skill does and why it's different

Most people give AI a "brand voice" by describing themselves in adjectives — "warm, professional, direct, avoid jargon." People are terrible at describing their own patterns, so the AI gets almost nothing operational and writes in generic-influencer-voice.

This skill does the opposite. It reverse-engineers a voice from real writing samples — finding the mechanical patterns that show up regardless of topic — and produces rules a machine can actually verify. Not "sound warm." Instead: "end on a short declarative line; never use an exclamation point."

The output is not this author's voice, or any preset voice. It is the user's own voice, derived from their own evidence, with their own pass/fail test.

The one hard rule

Never let the user self-describe their voice. Demand evidence.

If the user says "I'm witty and authoritative," do not write that down as a rule. Ask for writing samples and find out what witty-and-authoritative looks like in their actual sentences — or discover it isn't there at all. Self-description is exactly the failure mode this skill exists to replace.

Process

Step 1 — Collect evidence, then VERIFY you actually have it

Ask the user for 4–6 real writing samples, and insist they span different registers — because a voice's true fingerprint is what stays constant across contexts. Ask for a spread like:

• something professional / work (a post, an email, an article)
• something personal or emotional (a letter, a journal entry, a heartfelt message)
• something argumentative or persuasive (a rant, a pitch, a strong opinion)
• something casual / off-the-cuff (a text, a quick comment)

If they can only supply one genre, tell them plainly that the fingerprint will be weaker, and proceed with a caveat — one genre can't separate what's structural from what's situational.

Accept pasted text, files, or links, all mixed together freely. Never proceed on description alone — self-description ("I'm witty and direct") is not evidence and must never become a rule; only patterns found IN the actual text count.

Before moving to Step 2, copy this checklist into your response and check off each item as you complete it:

Evidence intake:
- [ ] Listed every file, folder, and message the user pointed me to
- [ ] Read the FULL TEXT of every sample file directly provided (not a preview)
- [ ] Opened every file path mentioned INSIDE those files — a path is a pointer
      to more evidence, not evidence itself, even if it's sitting inside a
      "notes" or "guidelines" file rather than a dedicated "samples" file
- [ ] Fetched and read every URL/link mentioned INSIDE those files, including
      ones living in a separate links-only file
- [ ] Reported the full inventory back to the user BEFORE starting analysis

The exact failure this checklist exists to prevent: a user's samples folder can mix direct writing (read this) with pointers to more writing — file paths, URLs — buried inside a "guidelines" or "notes" file rather than a file explicitly labeled "samples." It is easy to read the guidelines text, apply it, and silently skip the paths/links sitting right next to it, producing a fingerprint built on far fewer samples than the user actually provided — with no visible sign anything was skipped. This has happened in real use. Treat every file path and every URL you encounter anywhere in the provided material as a mandatory read, regardless of what kind of file it was found inside.

State the inventory back to the user before writing a word of analysis: "I found and read: [list files]. I followed and read: [list paths/links]. Total: N sources across M registers." Let them correct you here — it's cheaper to catch a missed source now than three exchanges later.

Step 2 — Analyze against the 12 dimensions

Read references/dimensions.md. For each of the 12 dimensions, look across ALL the samples and determine what the person actually, mechanically does — regardless of topic. Cite the evidence. Example of good analysis:

Dimension 1 (Ending posture): Across all four samples they end on a short declarative line, never a summary. The blog post ends "That's the whole game." The text ends "So no." Consistent. → Rule: end on a short line that stands alone.

Bad analysis (do not do this): "They seem confident and punchy." That's a vibe, not a derived rule, and it isn't checkable.

Step 3 — Produce the fingerprint

Write to a single file named exactly voice-fingerprint.md. If one already exists for this person (check before writing), UPDATE it in place — never create a second file under a different name for the same person. One person, one canonical file.

Using references/output-template.md, write the user a voice-fingerprint.md containing:

• their derived rules, one per dimension where a clear pattern exists (skip dimensions where the evidence is genuinely mixed — say so rather than inventing a rule)
• a "never sounds like them" list, built from what's absent in their real writing plus anything they explicitly reject
• their own pass/fail test — 3 checkable questions derived from their strongest dimensions (see the template). This is not a generic test; it's built from their signature moves.

Step 4 — Validate

Show them the fingerprint and ask: "Does this feel like you, or like a performance of you?" If anything reads as over-fit or invented, revise it against the samples — not against their self-description. Only keep rules the evidence supports.

Step 5 — Ongoing use

Once a fingerprint exists, this skill also handles:

• "is this on-voice?" → run their pass/fail test against a draft, report which checks pass/fail, and suggest the minimal fix.
• "write this in my voice" → generate against the fingerprint rules, then self-check with their pass/fail test before returning it.

Guardrails

• MUST read every file path and URL found anywhere in the provided material, including ones nested inside a "notes"/"guidelines" file rather than a dedicated samples file. Do not analyze until the Step 1 evidence-intake checklist is fully checked off and reported back to the user. This is not optional and has been skipped in real use — that is exactly why it's a checklist, not a sentence.
• One person, one voice-fingerprint.md. Update the existing file; never spawn a second one for the same person.
• The 12 dimensions are the questions. The answers are always the user's, never presets. Never import example rules from examples/ as defaults — they belong to a synthetic persona and exist only to show the format.
• If evidence for a dimension is thin or contradictory, say so. A shorter honest fingerprint beats a long invented one.
• Keep the fingerprint file the user's own property — it contains their voice and possibly personal writing. Don't transmit it anywhere; just save it locally.