Pherkad

Pherkad

Run a structured review of whether written output matches one specific person's voice profile.

Pherkad runs a structured diagnostic against text to surface generic phrasing, voice drift, and tone misalignment. It produces an actionable report with cited evidence, never a bare score.

Three parts do the work:

• The tell catalog (this skill plus references/ai_tells.md): documented AI-writing tells and the scoring protocol. Generic, shared by every user.
• The voice profile (Voice_Profile.md in the user's working folder): what this one writer actually sounds like. Personal, built once, refined over time. Never part of this repository.
• The mechanical linter (tools/voicelint.py): the configurable, regex-based subset of the catalog. It finds literal patterns and a small number of heuristic context checks. The model must review technical uses, quotations, and other cases that need judgment.
• The structural checker (tools/structlint.py): the half of the catalog that has no string to match. It reads sentence and header shape, so it catches the clipped balanced parallel, a run of three or more short sentences, and a header that strikes a pose rather than naming its subject. Everything it reports is a warning, because these are judgment calls that over-fire by design. Run it alongside the linter, never instead of it.

Modes

Pherkad runs in two directions against the same profile and the same tell catalog.

• Validation (Steps 0 through 6 below): check an existing draft and report, with cited evidence and a verdict.
• Authoring (references/authoring.md): draft or rewrite prose in the writer's voice in the first place, then self-validate before returning it. Use this whenever the user asks for a draft or rewrite in their voice, or wants text they will send as themselves.

Both begin by loading Voice_Profile.md. Without it, build the profile first.

When to use

• Before finalizing a paper, blog post, application letter, or any prose that should sound like its author
• When the user asks "does this sound like me?"
• When reviewing AI-assisted drafts for voice authenticity
• As a final advisory review before publication

Step 0: Check for a voice profile

Look for Voice_Profile.md in the user's working folder.

• Missing: run the profile-builder interview in references/profile_builder.md before validating anything. Validating without a profile produces a generic AI-tell scan at best; say so plainly if the user wants a scan anyway, and label the output as profile-less.
• Present: load it. Its markers drive Dimensions 1 through 4, 6, and 7 below. references/example_profile.md shows the expected shape (the persona in it is fictional).
• Companion files: if voice-rules.md or voice-authoring.md sit in the same folder, load them too. A profile may be split across the three: Voice_Profile.md holds the personal markers, voice-rules.md the bans, voice-authoring.md the drafting guidance. Together they are the profile.

Step 1: Extract a voice fingerprint

Read the submitted text. Before scoring anything, identify:

1. Three sentences that sound most like the writer. Quote them.
2. Three sentences that sound least like the writer. Quote them, each with a reason.

This forces pattern recognition before judgment.

Step 2: Run the seven-dimension diagnostic

Score each dimension 1 to 5. Dimensions 1-4, 6, and 7 are judged against the markers in Voice_Profile.md; Dimension 5 is judged against references/ai_tells.md.

Every score MUST cite a specific passage from the text as evidence. No dimension may be scored without a quote.

What the 1 to 5 means (the same anchors for every dimension, so a score is reproducible and not a feeling):

• 5: the profile's markers for this dimension are clearly present; the text matches the writer here.
• 4: mostly matches; one marker is weak or missing.
• 3: mixed; some of the writer's markers, some generic or off. The dimension neither confirms nor denies the voice.
• 2: mostly generic or off-profile; a marker appears only faintly.
• 1: none of the writer's markers for this dimension; reads as anyone, or as a different writer.

For Dimension 5 the scale inverts to the tell catalog: 5 means clean of tells, 1 means dense with them. Cite the quote that fixes the score at that anchor, not one step above or below.

Step 3: Flag generic or flattened sentences (individual hits)

If a Python runtime is available, first run the mechanical layer for exact line-numbered hits:

python3 tools/voicelint.py --json --strict <draft>
python3 tools/structlint.py --json <draft>

Then walk the full catalog in references/ai_tells.md (categories 5a through 5i) and flag each sentence with a supported tell, including the structural families the linter cannot see. List each flagged sentence with the specific tell identified. Deduplicate against the linter's findings; count each construction once.

Apply the catalog's caveats: technical-literal uses, direct quotes, single isolated constructions, informal-register exceptions, and the validator-internals exception (never flag a pattern inside a line that quotes, names, or defines it). Where the profile overrides a default (for example, a writer who uses em dashes on purpose), the profile wins.

Positive register. Absence of tells is necessary, not sufficient. Also read whether the draft carries the writer's own distinctive markers, from the profile and the "Positive register" section of references/ai_tells.md. A draft clean of every tell but showing none of the writer's markers has flattened toward a generic default; treat that as a REVISE-level signal even when no single hit fires.

Step 4: Compute the density signal

Apply the density verdict only to a draft of at least 150 words with at least 3 flagged constructions. A rate per 100 words is meaningless on a short passage: one hit in 40 words reads as 2.5 and would force a REVISE that a single stray phrase should never force (see Calibration notes). Below either floor, report the individual findings and skip the density warning.

1. Count total flagged constructions across the document.
2. Count total words.
3. Density = (flagged constructions / words) * 100.
4. For a draft of 150 or more words with 3 or more findings, density above 2.0 per 100 words raises a DENSITY WARNING. Otherwise there is no density warning.

Clustering weighs separately: two or more antithesis constructions (5c) or two or more triplet noun piles (5f) inside one paragraph raises a CLUSTER WARNING for that paragraph.

Step 5: Produce the verdict

The verdict follows from the dimension scores (Step 2) and the signals (Steps 3 and 4), not from a general impression. "Voice dimensions" below means 1 to 4, 6, and 7; Dimension 5 is the tell read.

• PASS: every voice dimension scores 4 or 5, Dimension 5 is 4 or 5, and there is no density warning and no cluster warning. Minor surface edits only.
• REVISE: the core voice is present but a section drifts. Any one of: a voice dimension at 3; exactly one voice dimension at 2 or below (whether from a missing-markers flattening or one off-profile score); a density warning; a cluster warning; or three or more individual hits.
• REWRITE: the voice has flattened or drifted across the piece. Two or more voice dimensions at 2 or below, or a density warning together with two or more cluster warnings.

When the signals point at different verdicts, take the more serious one and say which signal drove it.

Step 6: Deliver targeted rewrites

For every flagged sentence, provide a rewrite that preserves the meaning, matches the profile's markers, and names the specific correction. Do NOT rewrite the whole piece; fix only the misaligned sentences.

A voice rewrite must not change content: never add or drop facts, names, numbers, dates, or sources, and preserve the original's emphasis (urgency, authority, caveats). Keep terms of art; do not paraphrase them away.

Output format

VOICE VALIDATION REPORT
=======================

PROFILE: [Voice_Profile.md loaded / MISSING - profile-less scan]

FINGERPRINT
  Most like the writer:
    1. "[sentence]"
    2. "[sentence]"
    3. "[sentence]"

  Least like the writer:
    1. "[sentence]": [reason]
    2. "[sentence]": [reason]
    3. "[sentence]": [reason]

DIAGNOSTIC SCORES
  [table from Step 2, with evidence quotes]

GENERIC OR FLATTENED PATTERN FLAGS (individual hits)
  [list from Step 3, grouped by category 5a-5i]

POSITIVE REGISTER
  [which of the writer's own markers are present or absent, with quotes]

DENSITY SIGNAL
  Total flagged constructions: [N]
  Total words: [M]
  Density: [N/M*100] per 100 words
  Threshold: 2.0 per 100 words
  DENSITY WARNING: [YES / NO]

CLUSTER WARNINGS
  [paragraphs where 2+ antithesis or 2+ triplet constructions co-occur]

VERDICT: [PASS / REVISE / REWRITE]

TARGETED REWRITES
  [from Step 6, only when verdict is REVISE or REWRITE]

Calibration notes

Pherkad is not a generic AI detector and never polices someone else's text. It validates against one voice, its own user's. A passage can be entirely human-written and still fail because it does not sound like this writer; an assisted passage can pass because it does.

A single antithesis construction or one banned phrase does not force a REVISE. The validator weighs density and clustering, not lone hits. Writers use contrast; models overuse it.

Genre calibration. Distinctiveness lives in the frame, the transitions, and the close; a precise legal or technical core is correct when it is plain and must not be flagged for failing to be vivid. A finished piece is often deliberately uneven, a distinctive frame around an exact middle, and that unevenness is the design, not a defect. Read the frame and the transitions for the writer's positive register; hold the technical core to accuracy and the tell catalog, not to the archetype.

The profile is the user's data. It lives in their folder, is never committed to this repository, and updates only when they ask or when they correct a flag ("that one is actually me"). Corrections append to the profile, so a later run can apply the recorded correction instead of repeating the flag.