sakasegawa-blog-writer

Category: Content & Multimedia | Uploader: nyosegawa | Downloads: 0 | Version: v1.0（Latest）
技術ブログ記事を逆瀬川スタイルで執筆する。トピックや書きたい内容を与えられたときにWeb調査を行い、技術的に正確かつ読みやすい記事を生成する。Use when user asks to write a blog post, article, tech blog, Zenn article, or says "記事を書いて", "ブログ書いて", "技術記事", "解説記事", "まとめ記事" etc.
Changelog: Source: GitHub https://github.com/nyosegawa/skills
Directory Structure

Current level: private_skills/sakasegawa-blog-writer/
📁 references/
- 📄 article-template.md 3.0 KB
- 📄 research-methodology.md 3.5 KB
- 📄 style-guide.md 7.9 KB
📄 SKILL.md 9.0 KB
SKILL.md

---
name: sakasegawa-blog-writer
description: 技術ブログ記事を逆瀬川スタイルで執筆する。トピックや書きたい内容を与えられたときにWeb調査を行い、技術的に正確かつ読みやすい記事を生成する。Use when user asks to write a blog post, article, tech blog, Zenn article, or says "記事を書いて", "ブログ書いて", "技術記事", "解説記事", "まとめ記事" etc.
---

# sakasegawa-blog-writer

逆瀬川 ([@gyakuse](https://x.com/gyakuse)) の文体・構成・思考プロセスを再現して技術ブログ記事を書くスキル。

## 出力先

記事は以下のリポジトリに Markdown ファイルとして出力する。

- リポジトリ: `~/src/github.com/nyosegawa/nyosegawa.github.io`
- 出力先: `posts/{slug}.md`（slug はトピックに基づく英語ケバブケース）
- フロントマター形式（Lume Simple Blog テーマ）:

```yaml
---
title: "記事タイトル"
description: "記事の説明（1-2文）"
date: YYYY-MM-DD
tags: [タグ1, タグ2]
author: 逆瀬川ちゃん
---
```

- 「この記事はCoding Agentを使って執筆されています。」はCSSで自動挿入されるため、記事本文には書かない
- 記事冒頭の挨拶の後、適切な位置に `<!--more-->` を入れる（トップページの抜粋範囲を制御するため）

## Instructions

### Step 1: トピックの理解と調査計画

ユーザーからトピックや書きたい内容群を受け取ったら、まず以下を行う。

1. トピックの中核となる「問い」を特定する
   - 例: Context Engineeringの記事なら「なぜContext Engineeringが大事なのか」
2. 読者が最終的に得るべき理解を定義する
3. 調査すべき領域をリストアップする
   - 公式ドキュメント、論文、実装コード、価格表など
4. Web検索で最新の情報を収集する
   - 特に価格表、APIドキュメント、GitHubの実装は最新を確認すること
   - 論文はarXivのリンクを収集すること

### Step 2: 記事構成の設計

以下の構成パターンに従って章立てを設計する。

```
1. 導入 (挨拶 + トピック提示 + この記事でやること宣言)
2. 概念の導入 (定義 → でもふわっとしてるから実例で見よう、という流れ)
3. 具体的な構造・仕組みの解説 (図や表を使って)
4. そこから導かれる制約や課題 (前章の知識が伏線になる)
5. 実践的な対処法・実装例 (実コードやOSSの例を引用)
6. まとめ (短く、2-3行のbullet)
7. Appendix (深い技術的背景。本編から参照される)
8. References (リンク集)
```

重要: 章単位の接続を強く意識する。前の章で提示した情報が次の章の議論の前提になるように設計する。読者が「なるほど、だからこうなるのか」と思える流れにする。

### Step 3: 執筆

`references/style-guide.md` を必ず読んでから執筆すること。文体ルールはすべてそこに記載されている。

執筆時の思考プロセス:

1. 各章の冒頭で、前章とのつながりを示す一文を入れる
   - 「さて、このCacheの安さを見ることでContext Engineeringで避けたいことが見えてきます」のように
2. 技術的な概念は「なぜそうなっているか」から説明する
   - 仕組み→制約→解決策の順
3. 数値やデータは表で見せる。表は説得力の源泉
4. 難しい概念は噛み砕くが、正確性は絶対に犠牲にしない
   - 論文の内容を説明するとき、simplifyしすぎない
5. コード例はOSSの実装を引用するのが望ましい。架空のコードより実在のコードのほうが価値がある

### Step 4: レビューと調整

書き上がったら以下をチェックする。

1. 章の接続: 各章の終わりが次の章の導入になっているか
2. 伏線回収: 序盤で触れた概念が後半で活きているか
3. 文体の一貫性: `references/style-guide.md` のルールに従っているか
4. 技術的正確性: 数値、用語、リンクが正しいか
5. 読みやすさ: 音読して気持ちよく読めるリズムか

### Step 5: 公開

記事が完成したら、以下の手順で公開する。**公開前に必ずユーザーの確認を得ること。**

1. 完成した記事の全文をユーザーに提示する
2. ユーザーに以下を確認してもらう:
   - 記事の内容に問題がないか
   - タイトル・タグ・description が適切か
   - 公開してよいか
3. ユーザーから承認を得たら、ブログリポジトリで以下を実行する:

```bash
cd ~/src/github.com/nyosegawa/nyosegawa.github.io
# OGPカード画像を生成（新規記事分のみ自動生成される）
python3 scripts/gen-og-images.py
# 記事とOG画像をまとめてコミット
git add posts/{slug}.md og/{slug}.png
git commit -m "Add post: {記事タイトル}"
git push origin main
```

4. push が完了したら、公開 URL を伝える:
   - `https://nyosegawa.github.io/posts/{slug}/`

**重要: ユーザーの明示的な承認なしに git push しないこと。**

## 調査の方針

何を調査し掘り下げるかの判断基準:

- 価格やコスト: 必ず最新の公式価格表を取得する。コスト比較は読者にとって最も実用的な情報
- 実装詳細: GitHubのOSS実装を確認する。「こういうツールはこうなっている」と具体的に示す
- 論文: 関連する論文はarXivから探す。ただし全部は紹介しない。記事の文脈に合うものだけを選ぶ
- ベンチマーク・数値: 可能な限り定量的なデータを入れる。計算例を自分で作るのもよい

調査しないもの:
- ふわっとした定義の羅列(定義はサラッと触れてすぐ実例に行く)
- 網羅的なツール比較(記事の主張に関係するものだけ)

## Troubleshooting

### 章のつながりが弱い場合
原因: 各章を独立して書いている
解決: 前の章の最後の話題を次の章の冒頭で拾う。「さて」「ここで」「このように」等の接続を使う

### 技術的に浅くなる場合
原因: わかりやすさを優先しすぎている
解決: Appendixに深い内容を逃がす。本編では「Appendixを参照」と書いて、本編自体はちょうどいい深さを保つ

## 画像生成 (image-generation スキル連携)

記事中のアーキテクチャ図や概念図は `image-generation` スキルを使って生成する。ASCII artやコードブロックの図は使わず、画像で図示する。

### いつ画像を入れるか

- アーキテクチャ図（モデル構造、パイプライン全体像など）
- 比較図（手法A vs B の違い）
- 概念的なフロー図（データの流れ、処理の順序）
- 複数方式の並列比較（カスケード vs E2E など）

### 生成のベストプラクティス

- **4K生成→縮小**: `--image-size 4K --aspect-ratio 16:9 --downscale 1200` で生成すると日本語テキストが破綻しにくい
- **英語ラベル + 日本語出力例**: 技術用語のラベルは英語、出力例や要点説明だけ日本語にするとスマート
- **ASCII artは画像に置き換え**: 記事中にASCII artやコードブロックで図を書かない。image-generationスキルで画像化する

### 画像の保存場所

```
~/src/github.com/nyosegawa/nyosegawa.github.io/img/{slug}/{image-name}.png
```

### Markdown での参照

```markdown
![alt text](/img/{slug}/{image-name}.png)
```

### 手順

1. 記事の執筆中または執筆後に、図示すべき箇所を特定する
2. `image-generation` スキルの手順に従い、自然言語プロンプトで画像を生成する
3. 生成した画像を `img/{slug}/` に保存する
4. 記事内の該当箇所に `![...]` で画像を挿入する

## 数式の記述

ブログ（Lume）はKaTeXプラグインを導入済み。数式はLaTeX記法で記述できる。

### 書き方

- **ディスプレイ数式**: ` ```math ` コードブロックを使う（Markdownパーサーとの干渉を避けるため）
- **インライン数式**: 本文中では太字やインラインコードで代用する（`$...$` は他記事のドル記号と衝突するため未有効化）

### 例

````markdown
CTC lossは以下のように定式化されます。

```math
P(\mathbf{y}|\mathbf{x}) = \sum_{\boldsymbol{\pi}} \prod_{t=1}^{T} P(\pi_t | \mathbf{x})
```

ここで **π** はアライメントパスです。
````

### 注意

- Lume の KaTeX プラグインはビルド時にレンダリングするため、クライアントサイドJSは不要
- `$...$` デリミタは有効化していない（他記事のドル記号 `$200/月` 等と衝突するため）
- `_` を含む数式は `$$...$$` だとMarkdownパーサーにイタリックと解釈されるので ` ```math ` コードブロックを使う
- 複雑な数式はAppendixに逃がし、本編では概念的な説明にとどめる
Comments 0
Latest | Hot
Please login before commenting.
No comments yet. Be the first one!
sakasegawa-blog-writer

Directory Structure

SKILL.md

Report

Notice
