voice-profile skill
Extract a written voice profile from your own prior papers, then use it to keep new drafts sounding like you. Reads a corpus one document at a time via subagents, produces a reusable profile on disk (lexicon, sentence rhythm, how you open and close, hedging habits, deliberate quirks), and audits a draft against it. Use when the user says "make this sound like me", "match my voice", "profile my writing", "why does this draft not sound like my papers", or before drafting prose that will carry their name. The positive counterpart to /humanize, which only detects AI tells.
Is the voice-profile skill safe?
Clean: nothing in its files matched our rules. We read 1 file in the folder on 2026-09-28.
No findings.
Install the voice-profile skill
A skill is a folder. Copy it into your agent's skills folder and the agent loads it when the task matches its description.
git clone --depth 1 https://github.com/pedrohcgs/claude-code-my-workflow.git /tmp/claude-code-my-workflow mkdir -p ~/.claude/skills cp -r /tmp/claude-code-my-workflow/.claude/skills/voice-profile ~/.claude/skills/voice-profile
In the Claude apps, zip the folder and upload it from the Skills settings. The folder on GitHub
The instructions your agent would load
SKILL.md as published, without the frontmatter. Read it on GitHub
Voice profile — write toward something, not just away from tells
/humanize is the negative direction: it finds AI tells and says what to remove. That leaves a draft that is merely less bad.
This is the positive direction: a written description of how you actually write, extracted from your own published work, so a draft can be measured against a target instead of a taboo list.
What this does not do. A voice profile makes prose sound like your prose. It does not
make model-generated text stop reading as model-generated to a neural detector — nothing an
LLM applies to its own output does. See writing-with-ai.md.
Use this to write well in your own register; write the load-bearing sentences yourself.
Building the profile
1. Assemble the corpus, and count it
Three to twelve of your own pieces where you were the primary writer. Published papers are best — they survived editing. Mix genres if you write in several (paper, referee report, grant, teaching notes); the profile should note where your register changes.
find <corpus-dir> -maxdepth 1 \( -name '*.pdf' -o -name '*.tex' \) | wc -l(find, not a glob — in zsh an unmatched glob aborts the whole command, which reports 0 and defeats the count this step exists for.)
Count before starting. A corpus of eleven is a different task from four, and discovering that halfway through is how a session gets reset.
2. One subagent per document — never load the corpus into one context
Per pdf-processing.md: spawn one subagent per document in a fresh context. Each reads only its own file, writes a ~300-word note to notes/voice/.md against the fixed schema below, and returns only the filename.
The main session then reads only the notes. Loading a whole corpus at once has repeatedly forced a session reset after partial work was already lost.
Per-document note schema — the same six headings every time, so the synthesis can compare:
## Lexicon words and phrases used repeatedly; words conspicuously avoided
## Rhythm typical sentence length; variance; where long sentences appear
## Openings how sections and paragraphs begin; how the paper opens
## Transitions the actual connectives used, verbatim, with rough frequency
## Hedging how uncertainty is expressed; how strong claims are made
## Quirks anything distinctive — punctuation habits, first person, humour, footnotes3. Synthesize, and mark what is stable
Read only the notes. A trait belongs in the profile if it appears across most of the corpus, not because one paper did it once. Record frequencies where you can: "'note that' appears in 7 of 9 papers; 'delve' appears in none."
Write to voice-profile.md at the repo root (allowlisted in the repo-hygiene gate). Include:
how results are framed.
- Signature vocabulary and the avoid list — words the author demonstrably does not use.
- Sentence rhythm, with a number: median length, and where the long ones land.
- Structural habits — how an introduction is built, where the contribution paragraph sits,
than a model's default.
- Hedging register — the author's actual calibration language, which is usually narrower
stops /humanize from flagging a habit as an AI tell.
- Deliberate quirks, labelled as deliberate. "Uses em-dashes frequently and on purpose"
- Where the register shifts by genre.
4. Wire it in
/humanize reads voice-profile.md when present and respects documented preferences — a quirk you have declared deliberate is no longer a finding. Point drafting work at the profile before it writes, not after.
Auditing a draft
Pass --audit followed by a filename to compare an existing draft against the profile instead of building one:
/voice-profile --audit main.texReport, per section: distance from the profile, with concrete evidence — vocabulary outside your range, hedging denser than your baseline, transitions you do not use, sentence rhythm that has flattened. Every finding cites the profile line it violates, so it is a deduction rather than taste.
Read-only. Auto-rewriting prose degrades it and introduces new tells, and it cannot change what a detector sees. The report says where and why; the author edits.
Anti-patterns
do. Voices change; re-profile after a few new papers.
- Profiling coauthored work you did not draft. You will extract someone else's voice.
- Treating the profile as a rulebook. It describes what you have done, not what you must
yours — the corpus must be work you wrote.
- Building it from AI-assisted drafts. The profile will encode the model's register as
an AI-use statement, make one (/submission-disclosures).
- Using it to pass a detector. It is a writing aid, not a laundering step. If a venue wants
Cross-references
- writing-with-ai.md — readability vs provenance, and the human-readable standard
- /humanize — the negative direction; reads this profile when it exists
- /proofread — grammar and consistency, a separate lens
- pdf-processing.md — the one-subagent-per-document pattern
More skills from pedrohcgs/claude-code-my-workflow
- Aadjudicate-reviewTurn an incoming set of findings — from an AI reviewer, a referee report, a code review, a linter, or a second model — into verified fixes, without letting a confident misread damage correct work. Every finding is a CANDIDATE until checked against the actual source. Use whenever you receive review comments, audit findings, or a critique you did not write yourself, especially when the reviewer is a model or when the volume is too large to check by feel.
- Aaudit-reproducibilityEnforce the replication-protocol.md rule by cross-checking numeric claims in a manuscript against the actual R / Stata / Python outputs. Report PASS/FAIL per claim against tolerance thresholds. Use before submission and before releasing a replication package.
- Ablast-radiusBefore and after changing anything shared — a function's return value, a signature, a schema, a label set, a config default, a constant, a file format — find every consumer and actually run them. Catches the change that looks purely additive but silently breaks a contract in a file you never opened. Use when editing shared code, adding a field/column/return element, renaming, changing units or defaults, or touching a pipeline that produces reported numbers.
- Acapture-environmentSnapshot the computational environment for a replication package — detects the analysis stack (R / Stata / Python) and emits the right lockfiles (renv.lock + sessionInfo.txt, requirements.txt / environment.yml / uv.lock, Stata version + ado package list), records seeds and RNG kind, optionally writes a pinning Dockerfile, and produces a paste-ready "Computational requirements" block. Use when user says "capture the environment", "snapshot my dependencies", "pin the versions", "make a renv.lock / requirements.txt", "make this byte-reproducible", or before releasing a replication package to openICPSR / the AEA Data Editor.
- AchallengeStress-test a finding against the choices you did not make. Enumerates the discrete forks a competent analyst could have taken (measure definition, sample filter, control set, clustering level, weighting, functional form), runs the specification grid, and reports the distribution rather than a point estimate — then attacks the identifying assumption with named, computable sensitivity statistics. Use when the user says "is this robust", "challenge this result", "specification curve", "multiverse", "how sensitive is this", "what if I'd used a different measure", "stress-test my estimate", or before a result becomes a headline claim. NOT a reviewer of prose or code — it challenges the CLAIM.
- AcheckpointSave a structured state snapshot before stopping or handing off. Captures the active plan, recent decisions, file pointers (with line numbers), open questions, and the next 1–3 actions into a checkpoint file under `quality_reports/checkpoints/`. Optionally proposes `[LEARN]` entries to add to MEMORY.md. Use when user says "checkpoint", "save state", "snapshot before I stop", "where am I", "wrap up the session for handoff", or before a long break / model switch / collaborator handoff. Companion to (NOT replacement for) the narrative session-log workflow.
- Acoauthor-briefGenerate a co-author / collaborator handoff brief for a multi-author, multi-machine project — summarizing what changed since the last brief (git delta), the current state of each artifact (manuscript, analysis, slides), open questions, how to reproduce locally, and any restricted-data access steps. Use when user says "coauthor brief", "handoff brief", "bring my coauthor up to speed", "what changed since last week", "onboard a collaborator", "write a handoff for [name]", or before sending a co-author the repo. NOT a commit or a checkpoint — it is the cross-machine, cross-person summary `meta-governance.md` only partially covers.
- AcommitCommit the current work — runs the quality, consistency and passport gates, branches off main if needed, stages specific files, and writes a commit whose subject states what is now true. Pushes and opens a pull request only with --pr or when the user asks; never merges — a merge happens only when the user explicitly says to merge. Use ONLY on explicit commit intent — user says "commit", "let's commit this", "open a PR", or prefixes with `/commit`. Do NOT auto-invoke on vague end-of-task phrases ("we're done", "wrap up") — those require explicit confirmation first. Never force-pushes or skips hooks.
- Acompile-latexCompile a Beamer LaTeX slide deck with XeLaTeX (3 passes + bibtex). Use when user says "compile", "build the slides", "rebuild the PDF", "run latex", "render the tex", or asks why a `.tex` file isn't producing a PDF. Operates on `Slides/*.tex`.
- Acompress-sessionDistill the current conversation into a structured note (decisions made, open questions, file pointers with line numbers, next 1–3 actions) and save to `quality_reports/session_logs/` before auto-compression. Differs from `/checkpoint` (explicit stop-point snapshot) and from auto-compaction (which truncates rather than distills). Use when context is approaching auto-compact threshold, when a long pipeline has accumulated many decisions, or when the user says "compress", "distil this session", "before we hit auto-compact", "structured handoff before context resets".
- Acontext-statusShow current context status and session health. Use to check how much context has been used, whether auto-compact is approaching, and what state will be preserved.
- Acreate-lectureCreate a new Beamer lecture `.tex` from source papers and materials, with notation consistency checks and the project's preamble wired in. Use when user says "create a lecture on X", "new lecture from these papers", "start a deck on topic Y", "scaffold a new Beamer file", "build me a lecture from these PDFs". Scaffolds the full deck — NOT for compiling existing `.tex` (use `/compile-latex`).