richfrem/humanize
plugins/voice-writer/skills/humanize/SKILL.md
This skill should be used when the user wants to "humanize this", "make this sound less AI", "rewrite this naturally", "remove AI patterns", "make this more conversational", "this sounds robotic", "edit for voice or tone", or pastes text that reads like LLM output (parallel structure in threes, em dashes, semicolons, hedging phrases, hollow affirmations). Also trigger for "make this sound like me", "clean up this draft", or "rewrite this for LinkedIn/email/Slack". Use this skill even for a single sentence if the user's intent is to make writing feel more human. Do NOT use for pure grammar correction or style guide work unrelated to humanizing AI patterns.
$ install --global
skillsauthnpx skillsauth add richfrem/agent-plugins-skills humanizeInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Apr 28, 2026, 8:51 AM133.7s6 files scanned
SKILL.md
- name:
- humanize
- plugin:
- voice-writer
- description:
- >
- allowed-tools:
- Read
Humanize
Transform stiff, AI-flavored, or over-polished writing into something that sounds like it came from an actual person -- with a distinct voice, natural rhythm, and the small imperfections that signal authenticity.
Input Context
The user provides text to humanize. They may also provide:
- Voice context: "write like a senior engineer", "this is for my LinkedIn"
- Channel: email, social post, blog, Slack, internal memo
- Tone direction: "warmer", "more direct", "less formal"
If none of these are provided, infer them from the text. Ask only if the target voice is genuinely ambiguous and would change the output significantly.
If the user has placed writing samples in
references/voice-profile/my-voice.md, read that file before rewriting.
It contains their preferred sentence patterns, register, and vocabulary. Apply
those patterns instead of projecting a generic voice.
Phase 1: Diagnose
Before rewriting, read the text as a human editor would. Identify internally:
- AI fingerprints -- which structural patterns are present?
- What's actually being said -- strip the structure, find the real content
- Who should be saying it -- what kind of person, in what context?
- What's missing -- real writing usually has a point of view, a concrete detail, or a light edge that has been smoothed away
Do this quickly and internally. Do not narrate this to the user unless asked.
For a full catalog of AI patterns and their fixes, read:
references/patterns.md
Phase 2: Rewrite
Apply these principles in order:
Voice first, fixes second. Do not just remove bad patterns. Replace them with something that has character. A human does not just avoid em dashes -- they use shorter sentences, or fragments, or a question.
One idea per sentence, usually. Most AI text over-compounds. Break it up. Short sentences are not unsophisticated -- they are confident.
Concrete over abstract. Replace vague abstractions with specifics wherever possible. "Improved performance" becomes "cut load time in half." "Valuable insights" -- name one. If there is no specific to reach for, cut the claim.
Preserve the actual content. Never add claims, details, or assertions not present in the source. Never invent examples. If something needs elaboration, flag it for the user -- do not fabricate it.
Register calibration. Match the register to the channel. Read
references/channel-rules.md for channel-specific constraints (LinkedIn,
email, blog, Slack). Character limits in that file are hard limits.
Natural emphasis. Real writers use bold and italics sparingly and only for genuine emphasis. If the text over-emphasizes, strip it.
Phase 3: Quality Check
Run these mentally before returning output:
- Read-aloud test -- Does it sound like a person is actually saying this? Any phrases you would never hear in speech?
- Fingerprint scan -- Any surviving em dashes doing decoration work? Any
triads? Any hollow pivots (see
references/patterns.md)? - Content fidelity -- Did anything get added that was not in the source? Did any meaning get lost?
- Voice consistency -- Is the register consistent from start to finish?
- Channel fit -- Would this work in the specified channel? Does it meet any character or length limits?
If any of these fail, fix before returning.
Output Format
Default: Return the rewritten text only -- no preamble, no explanation, no "Here is the humanized version:". Just the text.
Add a note only when:
- A claim was removed because it had no source support: (Removed: "X" -- no supporting detail in source. Add if you have one.)
- A length limit may have been violated -- note the count
- An ambiguity in the original was resolved one way -- note the interpretation
When the user asks for explanation: Walk through 2-3 of the most significant changes and why. Keep it brief. Focus on what changed in voice and rhythm, not just what was deleted.
Edge Cases
"Make it sound like me" -- Read references/voice-profile/my-voice.md
first. Extract voice patterns: sentence length, how they open paragraphs,
whether they use fragments, their preferred register, recurring vocabulary.
Apply those patterns. If no profile exists, ask the user for 1-2 examples
of their writing before rewriting.
Minimal AI contamination -- If the text is mostly fine but has a few patterns, do targeted surgery rather than a full rewrite. Preserve what is working.
Heavy AI contamination -- If nearly every sentence has a pattern, do a full rewrite. Do not try to patch it. Rewrite from the core message outward.
Soulless but technically correct -- The fix is not removing patterns. It is adding a point of view, a specific detail, or a human beat. Make a small creative choice and flag it if needed.
Formal writing (legal, regulatory, academic) -- Some register is intentional. Do not over-humanize. Focus only on removing AI patterns that would not appear in competent human writing of that type.
Reference Files
Read these when needed (Progressive Disclosure -- do not load all at once):
references/patterns.md-- Full AI pattern catalog with bad to good rewritesreferences/channel-rules.md-- Channel-specific rules and hard limitsreferences/voice-profile/README.md-- How users set up their voice profilereferences/voice-profile/my-voice.md-- User's personal voice samples (if populated)
Related Skills
richfrem/vector-db-ingest
tools
VerifiedTrustedCommunity
Ingests repository files into the ChromaDB vector store. Builds or updates the vector index from a manifest or directory scan using ingest.py. Use when new files need to be indexed or the vector store is out of date. <example> user: "Index these new plugin files into the vector database" assistant: "I'll use vector-db-ingest to add them to the vector store." </example> <example> user: "The vector store is missing recent files -- update it" assistant: "I'll use vector-db-ingest to re-index the changes." </example>
3SKILL.mdUpdated Jun 2, 2026
richfrem/vector-db-cleanup
data-ai
VerifiedTrustedCommunity
Removes stale and orphaned chunks from the ChromaDB vector store for files that have been deleted or renamed. Use after files are removed or moved to keep the vector index in sync with the filesystem. <example> user: "Clean up the vector store after I deleted some files" assistant: "I'll use vector-db-cleanup to remove orphaned chunks." </example> <example> user: "The vector database has chunks for files that no longer exist" assistant: "I'll run vector-db-cleanup to prune them." </example>
3SKILL.mdUpdated Jun 2, 2026
richfrem/vector-db-audit
testing
VerifiedTrustedCommunity
Audit Vector DB coverage -- compares the live filesystem manifest against the ChromaDB index to identify coverage gaps.
3SKILL.mdUpdated Jun 2, 2026
richfrem/rlm-search
development
VerifiedTrustedCommunity
3-Phase Knowledge Search strategy for the RLM Factory ecosystem. Auto-invoked when tasks involve finding code, documentation, or architecture context in the repository. Enforces the optimal search order: RLM Summary Scan (O(1)) -> Vector DB Semantic Search -> Grep/Exact Match. Never skip phases.
3SKILL.mdUpdated Jun 2, 2026