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.
In this repository12 other files it gives its agents.
- code-review-checklistSkill
- evaluating-agent-skillsSkill
- pablo-code-philosophySkill
- pablo-code-planningSkill
- pablo-code-reviewSkill
- pablo-code-simplifySkill
- pablo-goal-discoverySkill
- pablo-tddSkill
- pablo-test-reviewSkill
- qa-adversarySkill
- refactor-identificationSkill
- writing-agent-skillsSkill
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
- Very specific: line 17
Working language: If the working language is Spanish, read references/es.md for a Spanish-language reference version of this skill, then …
- Distinctive: line 33
[NEVER]: use an em dash to add emphasis or to connect ideas.
- Distinctive: line 40
If the transition does no work, cut it or merge the sentence into the previous one.
- Distinctive: line 42
[NEVER]: add a template section such as "Challenges and Future Directions" or "Key Takeaways" unless the task asks for it by name.
- Very specific: line 49
[NEVER]: use words from references/banned-list-en.md.
- Distinctive: line 56
[ALWAYS]: prefer active voice. "The test fails at line 12" weighs more than "it is observed that the test fails at line 12".
- Distinctive: line 61
Start some sentences with the verb, some with the subject, some with a subordinate clause.
- Distinctive: line 74
[DO]: add sensory or lived detail when the genre allows: what the build log showed, how the argument sounds read aloud, which test failed …
- Distinctive: line 88
Voice-lock: Write a one-line voice description, for example "direct, specific, mildly opinionated, no hype".
- Distinctive: line 90
Outline: Only if the text will run past a paragraph.
- Distinctive: line 92
Draft: Write freely against the outline, with the banned list and the voice description open.
- Distinctive: line 94
Critique-only: Read the draft and list what breaks the rules: where the rhythm is flat, where the stance hides, which banned word slipped …
- Distinctive: line 111
Do sentence lengths vary, or does every sentence run the same shape?
≈ “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.
Files
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.mdand keep it open while drafting. - [MUST] read
references/voice-en.mdto 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):
- Voice-lock. Write a one-line voice description, for example "direct, specific, mildly opinionated, no hype". Keep it in view.
- Outline. Only if the text will run past a paragraph. Three to five bullet points in order. No prose yet.
- Draft. Write freely against the outline, with the banned list and the voice description open.
- 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.
- 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?
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
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.

