agentleFS
piousppiousp/llm-skills/skills/human-like-writing/SKILL.md

human-like-writing

Skill2 starsChanged 7 days agoMITView on GitHub

Write or rewrite any text so it reads as naturally human, in any genre: code comments, PR reviews, summaries, text edits, emails, and academic prose. Use before drafting or revising any piece of writing. Do NOT use to detect or judge AI-written text; this skill produces writing, it does not run a review pipeline.

The file

Show its rules and text

We split this skill into the rules it gives an agent

13 rules. About 0 are common, 11 are distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈11

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Working language: If the working language is Spanish, read references/es.md for a Spanish-language reference version of this skill, then …

    line 17
  2. Distinctive:

    [NEVER]: use an em dash to add emphasis or to connect ideas.

    line 33
  3. Distinctive:

    If the transition does no work, cut it or merge the sentence into the previous one.

    line 40
  4. Distinctive:

    [NEVER]: add a template section such as "Challenges and Future Directions" or "Key Takeaways" unless the task asks for it by name.

    line 42
  5. Very specific:

    [NEVER]: use words from references/banned-list-en.md.

    line 49
  6. Distinctive:

    [ALWAYS]: prefer active voice. "The test fails at line 12" weighs more than "it is observed that the test fails at line 12".

    line 56
  7. Distinctive:

    Start some sentences with the verb, some with the subject, some with a subordinate clause.

    line 61
  8. Distinctive:

    [DO]: add sensory or lived detail when the genre allows: what the build log showed, how the argument sounds read aloud, which test failed …

    line 74
  9. Distinctive:

    Voice-lock: Write a one-line voice description, for example "direct, specific, mildly opinionated, no hype".

    line 88
  10. Distinctive:

    Outline: Only if the text will run past a paragraph.

    line 90
  11. Distinctive:

    Draft: Write freely against the outline, with the banned list and the voice description open.

    line 92
  12. Distinctive:

    Critique-only: Read the draft and list what breaks the rules: where the rhythm is flat, where the stance hides, which banned word slipped …

    line 94
  13. Distinctive:

    Do sentence lengths vary, or does every sentence run the same shape?

    line 111

≈ “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

Human-Like Writing

Goal: text that reads as written by a person, not generated by a model. The rules apply to every kind of writing: code comments, PR reviews, summaries, edits, emails, academic prose. Nothing here is domain-specific.

Working language. If the working language is Spanish, read references/es.md for a Spanish-language reference version of this skill, then apply the same rules with the Spanish banned list and voice files (references/banned-list-es.md, references/voice-es.md).

Before writing

  • [MUST] read references/banned-list-en.md and keep it open while drafting.
  • [MUST] read references/voice-en.md to lock the voice and gather few-shot samples.
  • [DO] set the voice and collect 3 to 5 real samples of the author's writing before drafting anything longer than one sentence.

Hard rules

Absolute. Breaking one means a rewrite.

  • [NEVER] use an em dash to add emphasis or to connect ideas. Use a period, a comma, or a semicolon. The em dash is the single strongest marker of generated prose.
  • [NEVER] close with a formula phrase. The last sentence of the text is the last concrete point, not a summary of the text. The banned closers are listed in references/banned-list-en.md.
  • [NEVER] open a sentence with a filler transition that adds no logic. If the transition does no work, cut it or merge the sentence into the previous one.
  • [NEVER] add a template section such as "Challenges and Future Directions" or "Key Takeaways" unless the task asks for it by name.
  • [NEVER] bold headers inside lists, or any systematic formatting. One bold word for emphasis at most, and rarely. A plain list already carries its own structure.
  • [NEVER] stack hedges. "It seems this might possibly be somewhat risky" reads as evasion. One hedge per claim, or none.
  • [NEVER] use words from references/banned-list-en.md. If a banned word is the exact right term, rewrite the sentence around it.

Soft rules

Habits with judgment, not a checklist.

  • [ALWAYS] prefer active voice. "The test fails at line 12" weighs more than "it is observed that the test fails at line 12". The passive serves when the agent of the action is unknown or unimportant.
  • [ALWAYS] vary sentence length and rhythm. Follow a long sentence with a short one. Or 2 short sentences, or 2 long ones. Vary the variation. Start some sentences with the verb, some with the subject, some with a subordinate clause. Generated prose has low burstiness (uniform rhythm) and low perplexity (too-predictable word choice); detectors combine both signals with vocabulary markers, so synonym-swapping does not fool them.
  • [ALWAYS] take a stance. Say what is wrong, what is good, what should change. A neutral summary reads as machine-made. A clear opinion, even a mild one, reads as human. "The paper reports a 12% gain, but the control group was small" is a stance; "The paper reports a 12% gain" is not.
  • [ALWAYS] be concrete. Name the file, the line, the number, the date, the person. "The merge takes 40 seconds" carries weight; "the merge is slow" does not. "The effect held in 14 of 16 trials" beats "the results were significant".
  • [DO] add sensory or lived detail when the genre allows: what the build log showed, how the argument sounds read aloud, which test failed first. Academic prose takes detail as data. Emails and reviews take it as voice.
  • [DO] cut filler. Every sentence should do work. Read the draft aloud and trim what stalls the breath.

Workflow

Adapt the steps to the size of the task. Never force the full sequence on a single comment.

Long or delicate text (a PR review, a summary, an academic paragraph):

  1. Voice-lock. Write a one-line voice description, for example "direct, specific, mildly opinionated, no hype". Keep it in view.
  2. Outline. Only if the text will run past a paragraph. Three to five bullet points in order. No prose yet.
  3. Draft. Write freely against the outline, with the banned list and the voice description open.
  4. Critique-only. Read the draft and list what breaks the rules: where the rhythm is flat, where the stance hides, which banned word slipped in. Diagnose only. Do not rewrite yet.
  5. Rewrite edit-first. Fix the draft sentence by sentence, starting from the critique. Preserve meaning and detail. Never add new arguments to pad the text.

Short text (a code comment, one reply, a subject line): skip the steps. Apply the hard and soft rules directly, in one pass.

Self-check before delivery

A quick mental pass. Answer these questions, fix what fails, then ship.

  • Any em dash in the text?
  • Any word from the banned list?
  • Does it end with a formula closer or a meta-comment?
  • Do sentence lengths vary, or does every sentence run the same shape?
  • Is the stance visible, or could a neutral reader not tell what the author thinks?
  • Is every claim concrete, with a name, a number, or an example behind it?
  • Would the author recognize their own voice in this text?

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.