Skill 詳細
technical-blog-writing
Technical writing limited primarily to developer blog posts.
使用前に確認
自動レビューは関連性のみを確認し、安全性や推奨を保証しません。使用前に出典の説明を読んでください。
SKILL.md
これはレビュー時に保存された抜粋です。完全で最新の内容は外部ソースを確認してください。
---
name: technical-blog-writing
description: "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"
allowed-tools: Bash(belt *)
---
> **Install the belt CLI skill:** `npx skills add belt-sh/cli`
# Technical Blog Writing
Write developer-focused technical blog posts via [inference.sh](https://inference.sh) CLI.
## Quick Start
> Requires inference.sh CLI (`belt`). [Install instructions](https://raw.githubusercontent.com/inference-sh/skills/refs/heads/main/cli-install.md)
```bash
belt login
# Research topic depth
belt app run exa/search --input '{
"query": "building REST API Node.js best practices 2024 tutorial"
}'
# Generate header image
belt 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-haGitHub で全文を読む (外部ページ)