technical-blog-writing
技術ブログ記事を、コード例や開発者向け慣習に沿った構成で執筆し、読者の理解を深めるSkill。
📜 元の英語説明(参考)
Technical blog post writing with structure, code examples, and developer audience conventions. Covers post types, code formatting, explanation depth, and developer-specific engagement patterns. Use for: engineering blogs, dev tutorials, technical writing, developer content, documentation posts. Triggers: technical blog, dev blog, engineering blog, technical writing, developer tutorial, tech post, code tutorial, programming blog, developer content, technical article, engineering post, coding tutorial, technical content
🇯🇵 日本人クリエイター向け解説
技術ブログ記事を、コード例や開発者向け慣習に沿った構成で執筆し、読者の理解を深めるSkill。
※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。
下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o technical-blog-writing.zip https://jpskill.com/download/6212.zip && unzip -o technical-blog-writing.zip && rm technical-blog-writing.zip
$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/6212.zip -OutFile "$d\technical-blog-writing.zip"; Expand-Archive "$d\technical-blog-writing.zip" -DestinationPath $d -Force; ri "$d\technical-blog-writing.zip"
完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。
💾 手動でダウンロードしたい(コマンドが難しい人向け)
- 1. 下の青いボタンを押して
technical-blog-writing.zipをダウンロード - 2. ZIPファイルをダブルクリックで解凍 →
technical-blog-writingフォルダができる - 3. そのフォルダを
C:\Users\あなたの名前\.claude\skills\(Win)または~/.claude/skills/(Mac)へ移動 - 4. Claude Code を再起動
⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。
🎯 このSkillでできること
下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。
📦 インストール方法 (3ステップ)
- 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
- 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
- 3. 展開してできたフォルダを、ホームフォルダの
.claude/skills/に置く- · macOS / Linux:
~/.claude/skills/ - · Windows:
%USERPROFILE%\.claude\skills\
- · macOS / Linux:
Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。
詳しい使い方ガイドを見る →- 最終更新
- 2026-05-17
- 取得日時
- 2026-05-17
- 同梱ファイル
- 1
📖 Skill本文(日本語訳)
※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。
テクニカルブログの執筆
inference.sh CLI を介して、開発者向けのテクニカルブログ記事を執筆します。
クイックスタート
curl -fsSL https://cli.inference.sh | sh && infsh login
# トピックの深さを調査
infsh app run exa/search --input '{
"query": "building REST API Node.js best practices 2024 tutorial"
}'
# ヘッダー画像を生成
infsh app run infsh/html-to-image --input '{
"html": "<div style=\"width:1200px;height:630px;background:linear-gradient(135deg,#0f172a,#1e293b);display:flex;align-items:center;padding:60px;font-family:ui-monospace,monospace;color:white\"><div><p style=\"font-size:18px;color:#38bdf8;margin:0\">// engineering blog</p><h1 style=\"font-size:48px;margin:16px 0;font-weight:800;font-family:system-ui;line-height:1.2\">How We Reduced API Latency by 90% with Edge Caching</h1><p style=\"font-size:20px;opacity:0.6;font-family:system-ui\">A deep dive into our CDN architecture</p></div></div>"
}'
投稿の種類
1. チュートリアル / ハウツー
ステップバイステップの指示です。読者はそれに従って何かを構築できるはずです。
構成:
1. 何を構築するのか(スクリーンショット/デモ付き)
2. 前提条件
3. ステップ1: セットアップ
4. ステップ2: コア実装
5. ステップ3: ...
6. 完全なコード(GitHubリンク)
7. 次のステップ / 拡張
| ルール | 理由 |
|---|---|
| 最初に最終結果を示す | 読者は続ける価値があるかを知る |
| 前提条件を明示的にリストする | 間違った読者の時間を無駄にしない |
| すべてのコードブロックは実行可能であるべき | コピー&ペースト&実行がテスト |
| 「方法」だけでなく「理由」も説明する | 推論を説明するチュートリアルは共有される |
| エラー処理を含める | 実際のコードにはエラーがある |
| 完全なコードリポジトリへのリンク | チュートリアル後の参照 |
2. ディープダイブ / 解説
概念、テクノロジー、またはアーキテクチャの決定を深く説明します。
構成:
1. [概念]とは何か、なぜ気にする必要があるのか?
2. どのように機能するか(簡略化されたメンタルモデル)
3. どのように機能するか(詳細なメカニズム)
4. 実世界の例
5. トレードオフと使用すべきでない場合
6. さらに読む
3. ポストモーテム / インシデントレポート
何がうまくいかなかったのか、その理由、そして何が修正されたのかを説明します。
構成:
1. 概要(何が起こったか、影響、期間)
2. イベントのタイムライン
3. 根本原因分析
4. 実装された修正
5. 再発防止のために行っていること
6. 学んだ教訓
4. ベンチマーク / 比較
ツール、アプローチ、またはアーキテクチャのデータ駆動型比較です。
構成:
1. 何を比較したか、その理由
2. 方法論(結果が再現可能であるように)
3. チャート/表付きの結果
4. 分析(数字が何を意味するか)
5. 推奨事項(注意点付き)
6. 生データ / 再現手順
5. アーキテクチャ / システム設計
システムがどのように構築され、なぜ決定がなされたのかを説明します。
構成:
1. 解決する必要があった問題
2. 制約と要件
3. 検討されたオプション
4. 選択されたアーキテクチャ(図付き)
5. 受け入れたトレードオフ
6. 結果と教訓
開発者向け執筆ルール
口調とトーン
| するべきこと | するべきでないこと |
|---|---|
| 直接的に:「コネクションプーリングを使用してください」 | 「コネクションプーリングの使用を検討してもよいかもしれません...」 |
| トレードオフを認める:「これは複雑さを増します」 | 自分のソリューションが完璧であるかのように振る舞う |
| チームの決定には「私たち」を使用する | 「私が単独でアーキテクチャを設計しました...」 |
| 具体的な数値:「p99を800msから90msに削減しました」 | 「パフォーマンスを大幅に改善しました」 |
| 情報源とベンチマークを引用する | 根拠のない主張をする |
| 代替案を認める | 自分の方法が唯一の方法であるかのように振る舞う |
開発者が嫌うこと
❌ 「今日のペースの速いテクノロジーの世界では...」(埋め草)
❌ 「ご存知のように...」(もし皆が知っているなら、なぜ書いているのですか?)
❌ 「単にXを行うだけです」(チュートリアルを読んでいるなら、何も単純ではありません)
❌ 「簡単に...」(読者の経験を軽視している)
❌ 「明らかに...」(もし明らかであるなら、書かないでください)
❌ テクニカルコンテンツにおけるマーケティング用語
❌ 3段落のコンテキストの下に本題を埋めること
コード例
| ルール | 理由 |
|---|---|
| すべてのコードブロックは実行可能でなければならない | 壊れた例は信頼を損なう |
| 完全で動作する例を示す | コンテキストのないスニペットは役に立たない |
| フェンス付きブロックに言語識別子を含める | 構文ハイライト |
| コードの後に出力/結果を示す | 読者は理解を確認できる |
| 現実的な変数名を使用する | fooではなくcalculateTotalRevenue |
| 例にエラー処理を含める | 実際のコードはエラーを処理する |
| 依存関係のバージョンを固定する | 「React」ではなく「React 18.2で動作します」 |
良いコードブロックの形式:
```python
# このコードが行うこと(1行)
def calculate_retry_delay(attempt: int, base_delay: float = 1.0) -> float:
"""ジッター付き指数バックオフ。"""
delay = base_delay * (2 ** attempt)
jitter = random.uniform(0, delay * 0.1)
return delay + jitter
# 使用例
delay = calculate_retry_delay(attempt=3) # 約8.0-8.8秒
### 説明の深さ
| 読者のシグナル | 深さ |
|----------------|-------|
| 「Xの入門」 | すべてを説明し、事前の知識を仮定しない |
| 「Xの高度なパターン」 | 基本をスキップし、ニュアンスを深く掘り下げる |
| 「X vs Y」 | 両方への精通を仮定し、違いに焦点を当てる |
| 「Xを構築した方法」 | 技術的な読者向け、基礎はスキップ可能 |
**想定される読者レベルを明示的に**冒頭で述べてください。
「この記事は、Dockerと基本的なKubernetesの概念に精通していることを前提としています。 コンテナが初めての方は、[私たちの入門記事]から始めてください。」
## ブログ記事の構成
### 理想的な構成
```markdown
# タイトル(主要キーワードを含み、結果を述べる)
[ヒーロー画像または図]
**TL;DR:** [主要な要点を含む2〜3文の要約]
## 問題 / なぜこれが重要なのか
[読者がなぜ気にするべきかを設定する — 具体的で、一般的ではない]
## 解決策 / 私たちがどのように行ったか
[コアコンテンツ — コード、アーキテクチャ、説明]
### ステップ1: [最初の事柄]
[説明 + コード + 出力]
### ステップ2: [2番目の事柄]
[説明 + コード + 出力]
## 結果
[数値、ベンチマーク、結果 — 具体的に]
## トレードオフと制限
[欠点について正直に — 信頼を築く]
## 結論
[主要な要点 + 何を 📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開
Technical Blog Writing
Write developer-focused technical blog posts via inference.sh CLI.
Quick Start
curl -fsSL https://cli.inference.sh | sh && infsh login
# Research topic depth
infsh app run exa/search --input '{
"query": "building REST API Node.js best practices 2024 tutorial"
}'
# Generate header image
infsh app run infsh/html-to-image --input '{
"html": "<div style=\"width:1200px;height:630px;background:linear-gradient(135deg,#0f172a,#1e293b);display:flex;align-items:center;padding:60px;font-family:ui-monospace,monospace;color:white\"><div><p style=\"font-size:18px;color:#38bdf8;margin:0\">// engineering blog</p><h1 style=\"font-size:48px;margin:16px 0;font-weight:800;font-family:system-ui;line-height:1.2\">How We Reduced API Latency by 90% with Edge Caching</h1><p style=\"font-size:20px;opacity:0.6;font-family:system-ui\">A deep dive into our CDN architecture</p></div></div>"
}'
Post Types
1. Tutorial / How-To
Step-by-step instruction. The reader should be able to follow along and build something.
Structure:
1. What we're building (with screenshot/demo)
2. Prerequisites
3. Step 1: Setup
4. Step 2: Core implementation
5. Step 3: ...
6. Complete code (GitHub link)
7. Next steps / extensions
| Rule | Why |
|---|---|
| Show the end result first | Reader knows if it's worth continuing |
| List prerequisites explicitly | Don't waste time of wrong audience |
| Every code block should be runnable | Copy-paste-run is the test |
| Explain the "why" not just the "how" | Tutorials that explain reasoning get shared |
| Include error handling | Real code has errors |
| Link to complete code repo | Reference after tutorial |
2. Deep Dive / Explainer
Explains a concept, technology, or architecture decision in depth.
Structure:
1. What is [concept] and why should you care?
2. How it works (simplified mental model)
3. How it works (detailed mechanics)
4. Real-world example
5. Trade-offs and when NOT to use it
6. Further reading
3. Postmortem / Incident Report
Describes what went wrong, why, and what was fixed.
Structure:
1. Summary (what happened, impact, duration)
2. Timeline of events
3. Root cause analysis
4. Fix implemented
5. What we're doing to prevent recurrence
6. Lessons learned
4. Benchmark / Comparison
Data-driven comparison of tools, approaches, or architectures.
Structure:
1. What we compared and why
2. Methodology (so results are reproducible)
3. Results with charts/tables
4. Analysis (what the numbers mean)
5. Recommendation (with caveats)
6. Raw data / reproducibility instructions
5. Architecture / System Design
Explains how a system is built and why decisions were made.
Structure:
1. Problem we needed to solve
2. Constraints and requirements
3. Options considered
4. Architecture chosen (with diagram)
5. Trade-offs we accepted
6. Results and lessons
Writing Rules for Developers
Voice and Tone
| Do | Don't |
|---|---|
| Be direct: "Use connection pooling" | "You might want to consider using..." |
| Admit trade-offs: "This adds complexity" | Pretend your solution is perfect |
| Use "we" for team decisions | "I single-handedly architected..." |
| Specific numbers: "reduced p99 from 800ms to 90ms" | "significantly improved performance" |
| Cite sources and benchmarks | Make unsourced claims |
| Acknowledge alternatives | Pretend yours is the only way |
What Developers Hate
❌ "In today's fast-paced world of technology..." (filler)
❌ "As we all know..." (if we all know, why are you writing it?)
❌ "Simply do X" (nothing is simple if you're reading a tutorial)
❌ "It's easy to..." (dismissive of reader's experience)
❌ "Obviously..." (if it's obvious, don't write it)
❌ Marketing language in technical content
❌ Burying the lede under 3 paragraphs of context
Code Examples
| Rule | Why |
|---|---|
| Every code block must be runnable | Broken examples destroy trust |
| Show complete, working examples | Snippets without context are useless |
| Include language identifier in fenced blocks | Syntax highlighting |
| Show output/result after code | Reader verifies understanding |
| Use realistic variable names | calculateTotalRevenue not foo |
| Include error handling in examples | Real code handles errors |
| Pin dependency versions | "Works with React 18.2" not "React" |
Good code block format:
```python
# What this code does (one line)
def calculate_retry_delay(attempt: int, base_delay: float = 1.0) -> float:
"""Exponential backoff with jitter."""
delay = base_delay * (2 ** attempt)
jitter = random.uniform(0, delay * 0.1)
return delay + jitter
# Usage
delay = calculate_retry_delay(attempt=3) # ~8.0-8.8 seconds
### Explanation Depth
| Audience Signal | Depth |
|----------------|-------|
| "Getting started with X" | Explain everything, assume no prior knowledge |
| "Advanced X patterns" | Skip basics, go deep on nuances |
| "X vs Y" | Assume familiarity with both, focus on differences |
| "How we built X" | Technical audience, can skip fundamentals |
**State your assumed audience level explicitly** at the start:
"This post assumes familiarity with Docker and basic Kubernetes concepts. If you're new to containers, start with [our intro post]."
## Blog Post Structure
### The Ideal Structure
```markdown
# Title (contains primary keyword, states outcome)
[Hero image or diagram]
**TL;DR:** [2-3 sentence summary with key takeaway]
## The Problem / Why This Matters
[Set up why the reader should care — specific, not generic]
## The Solution / How We Did It
[Core content — code, architecture, explanation]
### Step 1: [First thing]
[Explanation + code + output]
### Step 2: [Second thing]
[Explanation + code + output]
## Results
[Numbers, benchmarks, outcomes — be specific]
## Trade-offs and Limitations
[Honest about downsides — builds trust]
## Conclusion
[Key takeaway + what to do next]
## Further Reading
[3-5 relevant links]
Word Count by Type
| Type | Word Count | Why |
|---|---|---|
| Quick tip | 500-800 | One concept, one example |
| Tutorial | 1,500-3,000 | Step-by-step needs detail |
| Deep dive | 2,000-4,000 | Thorough exploration |
| Architecture post | 2,000-3,500 | Diagrams carry some load |
| Benchmark | 1,500-2,500 | Data and charts do heavy lifting |
Diagrams and Visuals
When to Use Diagrams
| Scenario | Diagram Type |
|---|---|
| Request flow | Sequence diagram |
| System architecture | Box-and-arrow diagram |
| Decision logic | Flowchart |
| Data model | ER diagram |
| Performance comparison | Bar/line chart |
| Before/after | Side-by-side |
# Generate architecture diagram
infsh app run infsh/html-to-image --input '{
"html": "<div style=\"width:1200px;height:600px;background:#0f172a;display:flex;align-items:center;justify-content:center;padding:40px;font-family:system-ui;color:white\"><div style=\"display:flex;gap:40px;align-items:center\"><div style=\"background:#1e293b;border:2px solid #334155;border-radius:8px;padding:24px;text-align:center;width:160px\"><p style=\"font-size:14px;color:#94a3b8;margin:0\">Client</p><p style=\"font-size:18px;font-weight:bold;margin:8px 0 0\">React App</p></div><div style=\"color:#64748b;font-size:32px\">→</div><div style=\"background:#1e293b;border:2px solid #3b82f6;border-radius:8px;padding:24px;text-align:center;width:160px\"><p style=\"font-size:14px;color:#94a3b8;margin:0\">Edge</p><p style=\"font-size:18px;font-weight:bold;margin:8px 0 0\">CDN Cache</p></div><div style=\"color:#64748b;font-size:32px\">→</div><div style=\"background:#1e293b;border:2px solid #334155;border-radius:8px;padding:24px;text-align:center;width:160px\"><p style=\"font-size:14px;color:#94a3b8;margin:0\">API</p><p style=\"font-size:18px;font-weight:bold;margin:8px 0 0\">Node.js</p></div><div style=\"color:#64748b;font-size:32px\">→</div><div style=\"background:#1e293b;border:2px solid #334155;border-radius:8px;padding:24px;text-align:center;width:160px\"><p style=\"font-size:14px;color:#94a3b8;margin:0\">Database</p><p style=\"font-size:18px;font-weight:bold;margin:8px 0 0\">PostgreSQL</p></div></div></div>"
}'
# Generate benchmark chart
infsh app run infsh/python-executor --input '{
"code": "import matplotlib.pyplot as plt\nimport matplotlib\nmatplotlib.use(\"Agg\")\n\nfig, ax = plt.subplots(figsize=(12, 6))\nfig.patch.set_facecolor(\"#0f172a\")\nax.set_facecolor(\"#0f172a\")\n\ntools = [\"Express\", \"Fastify\", \"Hono\", \"Elysia\"]\nrps = [15000, 45000, 62000, 78000]\ncolors = [\"#64748b\", \"#64748b\", \"#3b82f6\", \"#64748b\"]\n\nax.barh(tools, rps, color=colors, height=0.5)\nfor i, v in enumerate(rps):\n ax.text(v + 1000, i, f\"{v:,} req/s\", va=\"center\", color=\"white\", fontsize=14)\n\nax.set_xlabel(\"Requests per second\", color=\"white\", fontsize=14)\nax.set_title(\"HTTP Framework Benchmark (Hello World)\", color=\"white\", fontsize=18, fontweight=\"bold\")\nax.tick_params(colors=\"white\", labelsize=12)\nax.spines[\"top\"].set_visible(False)\nax.spines[\"right\"].set_visible(False)\nax.spines[\"bottom\"].set_color(\"#334155\")\nax.spines[\"left\"].set_color(\"#334155\")\nplt.tight_layout()\nplt.savefig(\"benchmark.png\", dpi=150, facecolor=\"#0f172a\")\nprint(\"Saved\")"
}'
Distribution
Where Developers Read
| Platform | Format | How to Post |
|---|---|---|
| Your blog | Full article | Primary — own your content |
| Dev.to | Cross-post (canonical URL back to yours) | Markdown import |
| Hashnode | Cross-post (canonical URL) | Markdown import |
| Hacker News | Link submission | Show HN for projects, tell HN for stories |
| Reddit (r/programming, r/webdev, etc.) | Link or discussion | Follow subreddit rules |
| Twitter/X | Thread summary + link | See twitter-thread-creation skill |
| Adapted version + link | See linkedin-content skill |
# Cross-post thread to X
infsh app run x/post-create --input '{
"text": "New blog post: How We Reduced API Latency by 90%\n\nThe short version:\n→ Moved computation to edge\n→ Aggressive cache-control headers\n→ Eliminated N+1 queries\n\np99 went from 800ms to 90ms.\n\nFull deep dive with code: [link]"
}'
Common Mistakes
| Mistake | Problem | Fix |
|---|---|---|
| No TL;DR | Busy devs leave before getting the point | 2-3 sentence summary at the top |
| Broken code examples | Destroys all credibility | Test every code block before publishing |
| No version pinning | Code breaks in 6 months | "Works with Node 20, React 18.2" |
| "Simply do X" | Dismissive, condescending | Remove "simply", "just", "easily" |
| No diagrams for architecture | Walls of text describing systems | One diagram > 500 words of description |
| Marketing tone | Developers instantly disengage | Direct, technical, honest |
| No trade-offs section | Reads as biased marketing | Always discuss downsides |
| Giant introduction before content | Readers bounce | Get to the point in 2-3 paragraphs |
| Unpinned dependencies | Tutorial breaks for future readers | Pin versions, note date written |
| No "Further Reading" | Dead end, no context | 3-5 links to deepen understanding |
Related Skills
npx skills add inferencesh/skills@seo-content-brief
npx skills add inferencesh/skills@content-repurposing
npx skills add inferencesh/skills@og-image-design
Browse all apps: infsh app list