Blog writing
My personal catalog of Agent Skills for AI agents.
npx -y skills add su-ekachai/skills --skill blog-writingAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Write, humanize, or review personal blog posts so they read as human-written in the owner's voice — first-person, concrete, sentence-case headings, italics over bold, no AI-slop patterns. Use when the user asks to "write a blog post", "draft a post about", "humanize this draft", "make this sound human", "review this post", or works on prose in the blog repository (eakkz-blog content). Supports Draft mode (co-write from the owner's material), Humanize mode (rewrite an AI-polished draft), and Review mode (pattern-hit audit report). Never fabricates personal experience.
The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
5.5 KB, as published. Nobody here has run it
Blog Writing — Draft, Humanize & Review
The skill writes and edits the owner's personal blog prose (the eakkz-blog
Zola site). Posts publish in English for general readers. The voice belongs
to the owner; the skill's job is keeping that voice intact through drafting
and AI-assisted polish.
Scope
- Governed: published blog prose — posts and content pages (about, resume).
- Excluded: the blog repository's commits,
README,CLAUDE.md, and configuration — thetechnical-writingskill governs those. Code blocks, quoted text, and cited examples inside posts are exempt from the pattern rules. - Conversational replies about blog topics keep their natural register.
Non-negotiable rules
- Never fabricate personal experience, opinions, or anecdotes. The owner supplies the story; a gap becomes a question to the owner, never an invention.
- Em dashes: hard max ~1 per 1,000 words, headings included. Use commas, periods, colons, or parentheses instead.
- Bold: at most one bolded phrase per section, usually none. Lead with the key words instead.
- Headings: sentence case ("## The daily tax"). Title case only for the post title; in a draft without frontmatter, the leading heading counts as the post title.
- State points positively — no "it's not X, it's Y" framing.
- Concrete beats vague: numbers, names, versions, and examples over adjectives.
- Check every deliverable against
references/blog-patterns.mdbefore delivery.
Voice fingerprint
Derived from the exemplar post "Automating My Daily HoYoLAB Check-In" (2026-07-01). Quoted fragments are cited examples.
- Open with the itch, not the topic: a specific first-person annoyance ("The daily tax").
- One precise metaphor per post reframes the mundane: "a small recurring tax on your attention". Never stack metaphors.
- After a buildup, the short turn: "I wanted a third option: never think about it again."
- Concrete over general: exact return codes, versions, paths, dates, and local color (Bangkok in sample data).
- Explain mechanisms, not virtues: "most chat apps show only the first line in a collapsed preview, so a bad run announces itself."
- Credit generously and specifically: "got the hard parts right and left me a pleasant codebase to build on."
- Italics stress the load-bearing word (every, only); body bold almost never appears.
- Headings short and concrete ("What I added").
- End on one resonant line tied to the theme, never a recap: "The best automation is the kind you forget is even there, right up until the one morning it tells you something went wrong."
- Rhythm: short paragraphs; one-clause punches between longer explainers.
- The writer is "I", the reader is "you"; "we" only for genuinely joint action.
- Asides carry information ("HoYoLAB is friendly here" introduces a fact), never filler.
Modes
| Mode | Activation | Output |
|---|---|---|
| Draft | "write a post", "draft a post about" | New post Markdown in the owner's voice |
| Humanize | "humanize", "make this sound human", "de-slop this draft" | Rewritten draft plus a change summary |
| Review | "review this post", "check this draft" | Pattern-hit report; fixes on request |
Draft procedure
- Collect the owner's material: the experience, opinions, outcomes, code, and links. Ask for whatever is missing (rule 1).
- Structure per the fingerprint: the itch → what existed → what changed → resonant close. Adapt when the material demands another shape.
- Write applying the rules and
references/blog-patterns.md. - Deliver post Markdown with the blog's frontmatter conventions (
title,description,date,[extra]lang/toc,[taxonomies]tags).
Humanize procedure
- Read the full draft.
- Preserve every fact, idea, and the owner's structure unless asked otherwise. Add no factual claim absent from the input.
- Rewrite to clear
references/blog-patterns.mdand match the fingerprint. - Deliver the rewrite plus a one-paragraph summary of what changed.
Review procedure
- Read the post completely.
- Check the rules, the fingerprint, and every pattern in
references/blog-patterns.md. Record hits with line references and quoted evidence. - Emit the report: one row per hit, with columns Pattern, Evidence (line),
and Fix. End with a verdict line:
CLEANor<N> hits across <M> patterns. - Fix only on request; re-check the changed hunks once after fixing.
Precedence
- When the
avoid-ai-writingskill is installed, run it as a final pass; its edits must not flatten the voice fingerprint — the fingerprint wins. - The blog repository's
CLAUDE.mdcarries a digest of the hard rules; this skill is canonical when they disagree. technical-writingand this skill never govern the same artifact.