jpskill.com
✍️ ライティング コミュニティ

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本体の挙動とは独立した参考情報です。

⚡ おすすめ: コマンド1行でインストール(60秒)

下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。

🍎 Mac / 🐧 Linux
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
🪟 Windows (PowerShell)
$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. 1. 下の青いボタンを押して technical-blog-writing.zip をダウンロード
  2. 2. ZIPファイルをダブルクリックで解凍 → technical-blog-writing フォルダができる
  3. 3. そのフォルダを C:\Users\あなたの名前\.claude\skills\(Win)または ~/.claude/skills/(Mac)へ移動
  4. 4. Claude Code を再起動

⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。

🎯 このSkillでできること

下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。

📦 インストール方法 (3ステップ)

  1. 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
  2. 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
  3. 3. 展開してできたフォルダを、ホームフォルダの .claude/skills/ に置く
    • · macOS / Linux: ~/.claude/skills/
    • · Windows: %USERPROFILE%\.claude\skills\

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
LinkedIn 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