agentleFS
Nisus74Nisus74/humanise/skill/SKILL.md

humanise

Skill1 starsChanged 5 months agoMITView on GitHub

Write, rewrite, edit and review human-facing prose in a specific person's voice. Use for emails, posts, reports, proposals, PRDs, board papers, documentation, applications, messages and any text the user will send, publish, present or sign off. Also use when the user asks for Australian English, natural writing, less corporate language, fewer AI tells, stronger voice, or prose that sounds like them. Do not apply the prose sweep to code, config, fixed legal text, quoted material or private scratch notes unless the user asks.

1 other project uses a version of this.

Adopted by

Most recently taken up by

  • Other versions1 project uses a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 1

    1. edenbuilds/agentloop★ 0same name

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • In this repository3 other files it gives its agents.

The file

Show its rules and text

We split this skill into the rules it gives an agent

25 rules. About 0 are common, 19 are distinctive, and 6 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈19

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 6

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use this order when instructions compete:

    line 20
  2. Distinctive:

    Never change a claim to make the prose smoother.

    line 30
  3. Very specific:

    Read the matching file in commands/ when a mode is named.

    line 47
  4. Distinctive:

    Read this material immediately before drafting:

    line 70
  5. Distinctive:

    Use verification references only when needed:

    line 82
  6. Distinctive:

    Use the least invasive mode that satisfies the request:

    line 96
  7. Very specific:

    Default to light edit for proofreading, voice rewrite for “humanise” or “make this sound like me”, and editorial reconstruction for “make …

    line 103
  8. Distinctive:

    Before writing, record internally:

    line 108
  9. Distinctive:

    If the source has no discernible point, do not polish it into cleaner nonsense.

    line 117
  10. Distinctive:

    Thin: only cross-channel traits, a provisional profile or generic defaults.

    line 141
  11. Distinctive:

    Keep these passes conceptually separate:

    line 148
  12. Distinctive:

    Mechanical last: Run the checker on substantial prose:

    line 172
  13. Very specific:

    Use agents/adversarial-reviewer.md for long-form or high-stakes work when a separate reviewer is available.

    line 183
  14. Distinctive:

    When useful, ask what they would change.

    line 192
  15. Distinctive:

    If no filled profile exists, do not turn the first use into a questionnaire.

    line 196
  16. Distinctive:

    Ask for one short piece they wrote and like.

    line 199
  17. Distinctive:

    Ask which is closest and what they would change.

    line 201
  18. Distinctive:

    Check section joins, argument progression, repeated conclusions and voice drift.

    line 217
  19. Distinctive:

    Run fidelity and mechanical checks on sections, then on the assembled document.

    line 218
  20. Distinctive:

    Use a separate adversarial review when available.

    line 219
  21. Distinctive:

    When the user changes a draft, treat the final text and the delta as stronger evidence than the draft they rejected.

    line 226
  22. Very specific:

    Do not generalise a correction across channels until the evidence supports it.

    line 235
  23. Very specific:

    Read config.yml; default to Australian English only when no preference exists.

    line 240
  24. Distinctive:

    Avoid em dashes when the user's absolute rules ban them.

    line 244
  25. Very specific:

    When changing this skill, read references/memory-loop.md, evals/self-harness-loop.md and CHANGELOG.md.

    line 249

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

humanise

Produce writing a particular person would recognise as theirs. Preserve what they mean, model the reader, draft from direct evidence of the user's voice, then remove generic model habits. Clean prose is the floor. Voice fidelity is the goal.

Operating principles

Use this order when instructions compete:

  1. The user's current request.
  2. Meaning, factual fidelity and required wording.
  3. Direct samples from the same channel and relationship.
  4. Confirmed cross-channel voice evidence.
  5. The user's soul and absolute rules.
  6. Channel, register and dialect defaults.
  7. Generic anti-AI guidance.

Never change a claim to make the prose smoother. Never invent a fact, opinion, anecdote, number, name or degree of certainty to make writing seem more human. Never manufacture quirks to satisfy a style quota.

Modes

The host may invoke the skill explicitly or select it from the request. Interpret these optional mode words after the skill name:

  • init: run progressive voice setup.
  • guide: draft new material.
  • rewrite: edit existing material.
  • check: inspect a draft for mechanical and structural tells.
  • fingerprint: rebuild the voice model after new samples.
  • learn: capture the difference between a proposed draft and the user's final version.
  • improve: run the engine improvement workflow.

Read the matching file in commands/ when a mode is named. If none is named, infer guide, rewrite or check from the request.

Boundaries

Apply the skill to prose the user will send, publish, present or approve. Hold off on:

  • source code, configuration, identifiers and commands;
  • quoted material and supplied testimonials;
  • data tables and machine-readable formats;
  • fixed legal, regulatory or contractual wording;
  • the user's raw notes when they want those preserved as source material;
  • conventional commit subjects.

Edit only the prose around exempt material. Preserve quoted spans exactly. Ask only when a wrong assumption would materially change the result.

Load the smallest useful drafting card

Resolve the private profile first. Use an explicit configured path when supplied. In a Claude Code marketplace plugin, use ${CLAUDE_PLUGIN_DATA}/profile so updates do not erase it. Otherwise use the profile/ beside this skill.

Read this material immediately before drafting:

  1. profile/soul.md and profile/absolute-rules.md, when present.
  2. The confidence summary and relevant channel section in profile/voice-fingerprint.md.
  3. Up to three real profile/sample-*.md files nearest to the channel, relationship and purpose.
  4. The relevant section of references/channel-playbooks.md.
  5. references/meaning-and-voice.md for the meaning contract, reader model and evidence rules.

For a long document, prefer a long-form sample over several short messages. Chat samples do not prove how the user writes a board paper. When no direct sample exists, state that internally, use confirmed cross-channel principles and draft conservatively.

Use verification references only when needed:

  • references/mechanical-sweep.md for the final sweep.
  • references/structural-tells.md when structure feels templated.
  • references/ai-slop-dictionary.md when vocabulary is generic or corporate.
  • references/tone-register.md when the reader's state or formality is uncertain.
  • references/cultural-calibration.md for a non-default audience or dialect.
  • references/technical-writing.md for technical prose.
  • references/worked-examples.md when a rewrite keeps the source's AI-shaped structure.

Core workflow

1. Choose the strength of intervention

Use the least invasive mode that satisfies the request:

  • Light edit: preserve structure and diction; fix friction, errors and obvious tells.
  • Voice rewrite: preserve the argument and facts; rebuild sentences and flow in the user's voice.
  • Editorial reconstruction: challenge the point, evidence and structure before rewriting. Use only when requested or when the source cannot become useful through editing alone.

Default to light edit for proofreading, voice rewrite for “humanise” or “make this sound like me”, and editorial reconstruction for “make this compelling”, “fix the argument” or an equivalent ask.

2. Build the meaning contract

Before writing, record internally:

  • the one point the piece must communicate;
  • facts, names, numbers, quotations and required wording;
  • certainty, caveats and boundaries;
  • the intended action or reader response;
  • the emotional posture;
  • anything that must not be added, removed or reframed.

If the source has no discernible point, do not polish it into cleaner nonsense. For an inexpensive internal message, make the narrowest reasonable inference. For an external or consequential piece, ask for the missing point or evidence.

3. Model the reader

Identify the channel, but do not stop there. Infer:

  • relationship and power;
  • shared context;
  • trust already earned;
  • the reader's likely state and objection;
  • stakes and reversibility;
  • the action the reader should take.

Let this model decide warmth, bluntness, context and formality. A regulator and a trusted investor may both receive an email, but they should not receive the same email voice.

4. Assess voice evidence

Classify the available evidence for this task:

  • Strong: several direct samples from the same channel and relationship.
  • Moderate: one direct sample or several nearby-channel samples.
  • Thin: only cross-channel traits, a provisional profile or generic defaults.

Weight raw human writing above polished or AI-assisted samples. Use negative examples and recorded user edits to define the boundary of the voice. Do not promote a one-off phrase into a signature move.

5. Draft in four passes

Keep these passes conceptually separate:

  1. Content: state the actual claim, evidence, caveat and ask.
  2. Rhetoric: arrange them for this reader and situation.
  3. Voice: match the user's decisions, emphasis, certainty, cadence and characteristic wording.
  4. Surface: fix dialect and remove generic vocabulary or templated structures.

Draft from exemplars, not by installing a checklist of “human” moves. Do not add a parenthetical, fragment, opinion or unusual rhythm merely because the profile records one. A characteristic move belongs only where the content calls for it.

For external work with no user wording, ask once for a rough paragraph, bullet rant, voice-note transcript or previous example when that input would materially improve the result. Do not block a quick request if a conservative draft would still help.

6. Verify in the right order

Fidelity first. Compare the draft with the meaning contract. Confirm every fact, degree of certainty, caveat and ask survived. Remove unsupported specificity.

Voice second. Compare against a named direct sample where one exists. Check the user's choices: what they lead with, where they take a position, how they handle the reader and where they stop. Surface similarity without those decisions is imitation, not voice.

Mechanical last. Run the checker on substantial prose:

python3 evals/assertions/writing_checks.py <draft-file> <dialect> [medium]

Fix hard failures. Treat numeric and stylistic signals as prompts for review, never quotas. A natural piece may contain no visible dialect marker, few contractions, a factual list of three items or a useful balanced sentence. Preserve it when rewriting would make it worse.

On consequential external work, use agents/fact-brief-checker.md when claims have a supplied source. Use agents/adversarial-reviewer.md for long-form or high-stakes work when a separate reviewer is available. Do not spawn reviewers for routine messages.

7. Present the writing, not the machinery

Lead with the finished draft. Add a short note only for material decisions, unsupported claims, missing evidence or deliberate departures from the brief. Do not make users read checker output, voice distances or internal reasoning unless they ask.

When useful, ask what they would change. A complete draft may be final without another feedback round.

Progressive onboarding

If no filled profile exists, do not turn the first use into a questionnaire.

  1. Produce one useful generic rewrite so the user sees the value.
  2. Ask for one short piece they wrote and like.
  3. Rewrite the same text in up to three materially different directions: close, direct and conversational.
  4. Ask which is closest and what they would change.
  5. Save a provisional decision profile with confidence labels.
  6. Invite more samples only for the channel the user is actively working in.

One sample is enough to start. Five to ten samples across several channels create a useful profile. Direct before-and-after edit pairs are the strongest learning evidence. Follow commands/init.md for the full flow and scripts/corpus-questionnaire.md when the user wants deeper setup.

Long-form documents

For work over roughly 1,500 words:

  1. Name the document-level point and the point of every section.
  2. Pull the nearest long-form exemplar and record evidence confidence.
  3. Draft section by section against one shared meaning contract and reader model.
  4. Track repeated rhetorical shapes across the whole document rather than resetting per section.
  5. Check section joins, argument progression, repeated conclusions and voice drift.
  6. Run fidelity and mechanical checks on sections, then on the assembled document.
  7. Use a separate adversarial review when available.

Cut or merge a section that has no job. Do not make long-form prose sound human by making every paragraph irregular; coherence matters more than visible burstiness.

Learning from use

When the user changes a draft, treat the final text and the delta as stronger evidence than the draft they rejected. With permission, capture:

  • proposed text and final text;
  • channel, relationship and purpose;
  • the changed decision, not only the changed words;
  • the user's reason, when supplied;
  • whether the pattern is provisional, repeated or confirmed.

Do not generalise a correction across channels until the evidence supports it. Follow commands/learn.md and references/memory-loop.md for durable capture.

Dialect and punctuation

Read config.yml; default to Australian English only when no preference exists. Apply spelling and punctuation consistently without forcing conspicuous dialect words into the draft. Respect fixed terminology, brand names and quoted text.

Avoid em dashes when the user's absolute rules ban them. Otherwise follow the confirmed profile and medium rather than treating one punctuation mark as universal proof of AI authorship.

Engine maintenance

When changing this skill, read references/memory-loop.md, evals/self-harness-loop.md and CHANGELOG.md. Keep held-out material reserved. Prefer the smallest evidence-backed change and keep personal voice evidence in the private profile.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.