Stats
Actions
Tags
From write
Use when writing a technical blog post about something built, fixed, or learned. Triggers on: "기술 블로그 써줘", "개발 블로그", "technical blog", "글 쓰고 싶은데 어떻게 시작해?", "이 경험 블로그로 쓰고 싶어", "engineering post", "회고 글", "튜토리얼 써줘", "개발 경험 공유". Best for: incident post-mortems, feature deep dives, lessons from production, tutorials. Not for: marketing copy, non-technical writing, or documentation (use doc-coauthoring).
How this skill is triggered — by the user, by Claude, or both
Slash command
/write:technical-blog-writerThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Most technical posts never get read past the third paragraph. The cause is almost always structural, not technical: the post opens with context that the reader did not ask for, buries the interesting part, and ends without a reason to care.
Most technical posts never get read past the third paragraph. The cause is almost always structural, not technical: the post opens with context that the reader did not ask for, buries the interesting part, and ends without a reason to care.
Developer readers are impatient and skeptical. They arrive with a problem or a curiosity. If the first two paragraphs do not signal "this post is relevant to your situation," they leave. Good technical writing earns attention continuously — it does not assume it.
Before writing anything, identify the one thing the post is really about:
If all three answers are clear, there is a post. If the answer to #3 is "nothing specific," the post needs a sharper angle.
Ask the user these questions if the topic is still vague. Do not start drafting until there is a concrete answer to all three.
Every technical post follows this arc. The details change, but the arc does not.
Opens with the situation, the problem, or the surprising discovery — not with "In this post, I will explain..."
Good hooks:
Bad hooks:
Describe the situation with enough specificity that a reader facing something similar recognizes themselves. Include:
This section builds credibility. Readers trust writers who demonstrate they actually encountered the problem rather than synthesized it.
Walk through the solution in the order you discovered it, not in the order of a clean explainer. The journey matters because it shows reasoning, not just conclusions.
Include:
Concrete outcomes. Numbers where possible. What changed for users, for the team, or for the codebase.
Avoid vague claims:
One paragraph on the lesson, written for the reader — not a recap of what you did, but the transferable insight.
End with one clear next step for the reader:
Write the full post in the user's voice. Principles:
Conversational but precise. Use first person. Write short sentences when explaining concepts. Reserve long sentences for narrative. Avoid the passive voice unless necessary.
Show personality. A voice makes a post memorable. Dry technical writing is harder to finish. This does not mean jokes — it means a writer who sounds like a person rather than documentation.
Avoid jargon walls. When you introduce a technical term, define it in one clause the first time it appears. After that, use it freely.
Code examples must be runnable or obviously so. Pseudocode that cannot be adapted into real code is not a code example — it is a diagram without a diagram.
Headings should be scannable. A developer reading for the third time should be able to jump directly to the section they need using headings alone. Use specific headings, not generic ones:
Work through this checklist before the post is finished:
For posts intended for search traffic, the H1 and H2 headings should contain the specific terms a developer would actually search. This is not keyword stuffing — it is using the language your reader uses.
Put the core keywords near the front of the heading. Search engines and skimmers both read left-to-right.
| Topic type | Target length |
|---|---|
| Quick tip or single concept | 400–700 words |
| Full problem/solution narrative | 1,000–1,800 words |
| Deep dive or tutorial | 2,000–3,500 words |
| Series part (multi-part) | 1,000–1,500 words per part |
Longer is not deeper. Every paragraph should earn its place by adding information the reader does not already have.
Opening with motivation, not hook. "I've been interested in distributed systems for a while" is not a hook. The reader's interest in you is proportional to what you have just given them — which at the opening is zero. Start with the situation.
Explaining the solution without the problem. Readers need to feel the problem before the solution is interesting. Spend real time on what broke and why it was hard before explaining the fix.
Skipping the tradeoffs. A post that presents only the happy path reads like documentation, not experience. Tradeoffs are where the real insight lives.
Code blocks that are too long. A 150-line code block in a blog post is unreadable. Show the key 10–20 lines with a comment pointing to the full version elsewhere.
No call to action. Readers who finish a post and have nowhere to go produce no engagement and no memory. End with something actionable.
npx claudepluginhub newkayak12/claude-skills --plugin writeWrite technical blog posts that document decisions, share learnings, and build external reputation. Use for knowledge sharing, hiring, and credibility building.
Walks through the full pipeline of writing technical articles: idea sharpening, hook/title generation, structure drafting, body writing, and editing for developer audiences.