humanize-pro

Files (4)

• SKILL.md
• ai-tells.md · references/
• channels.md · references/
• voice-profile-template.md · references/

SKILL.md (first lines)

# Humanize Pro

Two jobs, in this order: remove the statistical residue of a language model, then make the text fit the channel it ships in. Most humanizer skills only do the first, which produces clean prose that still lands wrong because a LinkedIn post is not a memo and a Slack reply is not an essay.

A third job sits underneath both: sound like *this* writer, not like a generically de-slopped one. That is what the voice profile is for.

## When to trigger

Use this skill when:

- The user asks to humanize, unslop, de-slop, de-AI, clean up, or tighten text, or to make it sound human or natural.
- The user says something reads like AI or like ChatGPT.
- The user asks whether text matches their voice, style guide, or voice profile, or wants a profile built or updated.
- You are drafting or rewriting outbound human communication, even if nobody said "humanize": LinkedIn posts and comments, X posts and replies, cold or warm email, internal email, exec memo, Slack, blog, landing page, help content, press or public statements.
- Prose is going inside a deliverable: a document, deck, artifact, or generated file. The rules apply to the payload, not only the chat reply.

Do not trigger for:

- Code, commit messages, PR descriptions, or changelogs.
- Legal or regulated text.
- SEO structural elements (title tags, meta descriptions, keywords), unless the user explicitly asks to humanize those.

## Modes

Pick one. If unclear, ask in a single line.

- **Rewrite** (default): user pastes text, you return the fixed version.
- **Draft**: user gives raw notes or a brief, you write it clean the first time.
- **Audit**: user wants the tells named, not fixed. Return a numbered list of what would flag, with the line quoted and a one-line fix each. No rewrite.
- **Profile**: user wants their voice profile built or updated from samples and past corrections. See "Voice profile" below.

## Precedence

Requirements outrank style. In order:

1. The no-fabrication rule.
2. Named external requirements: legal and regulated language, brand guidelines, SEO structure (title tags, meta descriptions, keyword placement, internal links).
3. The user's **standing constraints** (see below).
4. The user's voice profile or writing sample.
5. Every style rule in this skill.

When a rule collides with something above it, keep the higher item and flag the conflict in one line after the text. Never resolve it silently.

## Standing constraints

A standing constraint is a rule the user has stated once and expects to hold forever, in every output, without being restated. Typical examples: a banned punctuation mark, a banned word, a forbidden greeting, a required sign-off, a length ceiling.

Three things make constraints different from style preferences:

- **They are absolute, not weighted.** A single violation is a failure even if the rest is excellent.
- **They apply to every surface.** Chat prose, generated documents, artifacts, file contents, headings, image captions, table cells, code comments in user-facing snippets. A constraint violated inside a deliverable is the most common failure mode, because the model applies the rule to its reply and forgets the payload.
- **They survive tool boundaries.** Text written to a file, passed to another skill, or produced inside an artifact is still the user's text.

Record standing constraints at the top of the voice profile. Before delivering anything, run the constraint list as a literal scan of the output, including every file you wrote this turn. Do not rely on having intended to comply.

## Voice profile

The voice profile is a versioned file describing how one specific person writes. It is not part of this skill; it belongs to the user. Look for it in this order:

1. A path the user names.
2. A personal brand or voice skill already loaded in the session.
3. `references/voice-profile.md` inside a private fork of this skill.
4. Persistent memory, if the surface has it.

If none exists and the user wants one, offer to build it. Do not build it silently.

### Format

```
# Voice profile: <name>
Version <n>, updated <date>

## Standing constraints        (absolute, never violated)
## Register                    (who they sound like, to whom)
## Sentence and paragraph shape
## Vocabulary: use / avoid
## Structural habits           (openers, closers, lists vs prose)
## Channel deltas              (how the voice shifts by surface)
## Open questions              (unresolved, needs more evidence)
## Changelog                   (what changed, what triggered it)
```

Every line carries a confidence marker:

- **stated**: the user said it directly. Treat as binding.
- **observed**: inferred from three or more independent samples of their own writing. Strong default, overridable.
- **provisional**: inferred from one or two samples, or from a single edit. Apply, but flag when it drives a visible choice.

Never promote a provisional line to stated. Only the user promotes.

### Building one

Sources, in descending value: text the user wrote themselves; text the user edited and shipped; text the user approved unchanged; text the user rejected, with the reason. Chat messages count, and are often the most honest sample, because nobody performs in a chat message.

Aim for one page. A voice profile that runs long stops being read.

## Capture corrections

The profile is worth having only if it stays current, and the raw material arrives constantly: every edit the user makes to your draft is a labeled training example.

When the user returns an edited version, rejects a draft, or says a line is wrong:

1. **Diff intent, not tokens.** Ask what class of change it is: a constraint violation, a register mismatch, a structural habit, a vocabulary preference, or a one-off factual fix. One-off fixes do not belong in the profile.
2. **Write the rule in their words where possible.** "Cut the setup sentence, start on the claim" beats "reduce preamble."
3. **Check for contradiction.** If the new correction contradicts an existing line, do not overwrite. Surface both and ask which holds. Contradictions are usually context-dependent rules that need a channel delta, not a replacement.
4. **Log it.** Add a changelog entry with the date and the triggering example. The changelog is what lets the user audit whether the profile is drifting.
5. **Update in the same turn.** A correction noted but not written is lost.

Two failure modes to watch. **Over-fitting**: one heavy edit becomes a permanent rule and the voice narrows. Require three instances before a provisional line becomes observed. **Sycophantic drift**: the profile fills with rules that make outputs more agreeable rather than more accurate. If a proposed line would suppress disagreement, a caveat, or an unwelcome finding, it is not a voice rule. Leave it out.

## Workflow

### 1. Establish channel and audience

Before writing anything, fix these three:

- **Channel**: LinkedIn post, LinkedIn comment or reply, X post, X reply, cold email, internal email, exec memo, Slack, blog, landing page, product docs, press or analyst, board. A comment is its own channel, not a short post: it answers a person.
- **Direction**: internal or external. This governs candor, hedging, jargon tolerance, and how much context you restate.
- **Relationship**: cold, warm, peer, report, manager, exec, customer, public.

From msdanyg/humanize-pro, MIT.