agentsclimarketplace

Blog writing

Skill su-ekachai/skills/skills/writing/blog-writing

My personal catalog of Agent Skills for AI agents.

Install
npx -y skills add su-ekachai/skills --skill blog-writing

Assembled 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 — the technical-writing skill 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

  1. Never fabricate personal experience, opinions, or anecdotes. The owner supplies the story; a gap becomes a question to the owner, never an invention.
  2. Em dashes: hard max ~1 per 1,000 words, headings included. Use commas, periods, colons, or parentheses instead.
  3. Bold: at most one bolded phrase per section, usually none. Lead with the key words instead.
  4. 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.
  5. State points positively — no "it's not X, it's Y" framing.
  6. Concrete beats vague: numbers, names, versions, and examples over adjectives.
  7. Check every deliverable against references/blog-patterns.md before delivery.

Voice fingerprint

Derived from the exemplar post "Automating My Daily HoYoLAB Check-In" (2026-07-01). Quoted fragments are cited examples.

  1. Open with the itch, not the topic: a specific first-person annoyance ("The daily tax").
  2. One precise metaphor per post reframes the mundane: "a small recurring tax on your attention". Never stack metaphors.
  3. After a buildup, the short turn: "I wanted a third option: never think about it again."
  4. Concrete over general: exact return codes, versions, paths, dates, and local color (Bangkok in sample data).
  5. Explain mechanisms, not virtues: "most chat apps show only the first line in a collapsed preview, so a bad run announces itself."
  6. Credit generously and specifically: "got the hard parts right and left me a pleasant codebase to build on."
  7. Italics stress the load-bearing word (every, only); body bold almost never appears.
  8. Headings short and concrete ("What I added").
  9. 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."
  10. Rhythm: short paragraphs; one-clause punches between longer explainers.
  11. The writer is "I", the reader is "you"; "we" only for genuinely joint action.
  12. Asides carry information ("HoYoLAB is friendly here" introduces a fact), never filler.

Modes

ModeActivationOutput
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

  1. Collect the owner's material: the experience, opinions, outcomes, code, and links. Ask for whatever is missing (rule 1).
  2. Structure per the fingerprint: the itch → what existed → what changed → resonant close. Adapt when the material demands another shape.
  3. Write applying the rules and references/blog-patterns.md.
  4. Deliver post Markdown with the blog's frontmatter conventions (title, description, date, [extra] lang/toc, [taxonomies] tags).

Humanize procedure

  1. Read the full draft.
  2. Preserve every fact, idea, and the owner's structure unless asked otherwise. Add no factual claim absent from the input.
  3. Rewrite to clear references/blog-patterns.md and match the fingerprint.
  4. Deliver the rewrite plus a one-paragraph summary of what changed.

Review procedure

  1. Read the post completely.
  2. Check the rules, the fingerprint, and every pattern in references/blog-patterns.md. Record hits with line references and quoted evidence.
  3. Emit the report: one row per hit, with columns Pattern, Evidence (line), and Fix. End with a verdict line: CLEAN or <N> hits across <M> patterns.
  4. Fix only on request; re-check the changed hunks once after fixing.

Precedence

  • When the avoid-ai-writing skill is installed, run it as a final pass; its edits must not flatten the voice fingerprint — the fingerprint wins.
  • The blog repository's CLAUDE.md carries a digest of the hard rules; this skill is canonical when they disagree.
  • technical-writing and this skill never govern the same artifact.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.