| name | blog-writing |
| description | ブログ執筆の業務フロースキル。調査→タイトル設計→構成→執筆→保存までを実行する。
以下のようなリクエストで必ず使用すること：
- 「〜についてブログを書いて」
- 「〜を調査してブログ記事にまとめて」
- 「〜について技術ブログを作成して」
- 「〜の解説記事を書いて」
- 「〜について深掘りしてMarkdownにして」
- 「〜についてまとめ記事を書いて」
「ブログ」「解説記事」「まとめ記事」「技術記事」などの言葉が含まれる依頼では必ずこのスキルを使うこと。
文体・トーン・品質判断は blog-writer エージェントの職種定義に従うこと。
出力はMarkdownファイル（.md）として保存し、ユーザーに提供する。
|
ブログ執筆 業務フロースキル
このスキルはブログ執筆の 実行手順を定義 する。
文体・トーン・品質の判断基準は blog-writer エージェントの職種定義を参照すること。
Step 1: テーマ分析と調査設計
-
テーマの主役を定義する
- 「一言で言うと何か」を確認する。言えない場合は調査の最初のタスクにする
- 「日常の何に例えられるか」を考える
-
読者像と動機を具体的に想定する
- 職種・経験年数・直面している問題を想像する
- 「この記事を読み終えた読者がどんな状態になってほしいか」をゴールとして設定する
-
標準セクションの選定
- 活用事例・ハマりポイント・取り込み方の3つは原則必須
-
調査設計
- 調べるべき論点を列挙する
- Step 2の4段階調査のどの観点が使えるかを確認する
Step 2: 4段階調査プロセス
WebSearch・WebFetch・公式ドキュメントを組み合わせて実施する。
調査なしに執筆を始めないこと。
① 境界条件のテスト（「もし〜なら」を試す）
- 極小化: 最低スペック・最小構成でも動作するか？
- オフライン化: 外部API・クラウドなしでローカルだけで完結するか？
- 干渉: 他プロセスと同時稼働したとき競合が起きるか？
② 比較と歴史的背景（「なぜこれか」を問う）
- 代替技術との比較：メモリ消費・レイテンシ・自由度・運用コスト等の軸で
- 系譜を辿る：思想的ルーツ・先行技術・失敗した前身
③ 一次情報への越境
- 公式ドキュメントの「Caveats」「Known Issues」「Advanced Configuration」まで読む
- OSSならエラーの核心箇所のソースを直接確認する
- 仕様書・RFC・プロポーザルで設計判断の理由を確認する
④ 応用の自動化・仕組み化
- スクリプト化できるか？
- 別環境（iPad・ラズパイ・CI/CD等）でも再現できるか？
調査の原則:
- 最低 5件以上 の異なるソースから情報収集する
- 数値・バージョン・固有名詞は原典を確認する
- 古い情報・非推奨情報は除外または注釈する
ソース優先順位:
- 公式ドキュメント・仕様書・RFC
- 査読済み論文・arXiv
- GitHubリポジトリ・コミットログ・リリースノート
- 著名エンジニア・開発者の技術ブログ・発表資料
- 大手技術メディア（Zenn・Qiita・The Morning Paper 等）
Step 3: タイトルの設計
ルール1：ベネフィット＋具体的な制約・環境
- NG: 「iPad Safariを最強にする」
- OK: 「iPad SafariにAIボタンを実装して、YouTube視聴を爆速化する」
ルール2：コストや効率を「数字」で示す
- NG: 「API代を節約する方法」
- OK: 「月額$20の課金を回避し、ローカル環境だけでAIエージェントを構築する手順」
ルール3：既存の「当たり前」に疑問を投げかける
- 例: 「なぜ今のIoTはクラウドに頼りすぎるのか？ ローカルプロトコルで見直すスマート家電の寿命」
ルール4：結論を「動詞」で始める（解決型）
- NG: 「GASのeval対策」
- OK: 「Google Apps Scriptの安全性を確保する：evalを使わない動的実行の実装パターン」
タイトル候補を2〜3案生成し、最も刺さるものを採用する。
Step 4: 記事構成の設計
# [タイトル]
> リード文：具体的なゴールを一文で宣言する。
> NG:「業務効率が上がります」
> OK:「FAQ対応の一次回答を自動化し、担当者の返信待ち時間を4時間→15分にする方法がわかります」
## [テーマの主役の紹介]（必須・冒頭に配置）
→ 一言定義＋日常の例え＋できることの一覧
## 動機
→ 読者の「あるある」な悩みから入る
## 仮説
→ 「もしかして〇〇でいけるのでは？」という問いを立てる
## 検証
→ 一次情報・コード・SVG図・比較テーブルを交えて論証する
## 結果
→ 数値・挙動・限界値。「動いた」だけでなく「どこまで動くか」まで
## 考察
→ 独自の知見。「本来の仕様とは違うが、こう使えば効率的だ」
## [Step 4.5の標準セクション群から選んで配置]
## まとめ
→ 締めは「これを読んだあなたは〇〇ができる」という宣言で終わる
## 参考文献
Step 4.5: 標準セクション群
活用事例・ハマりポイント・取り込み方の3つは原則必須。
各セクションは必ず散文（本文）で始め、箇条書きだけで構成しない。
📌 注目ポイント
核心を3〜5点に絞って提示する。「なぜそれが重要か」まで掘り下げる。
💡 活用事例
実際にどこで・どう使われているかを物語として語る。
事例は「その人がどんな問題を抱えていたか→どう解決されたか」のストーリー構造で書く。
実企業・OSSの事例を1件以上含め、数値（削減率・処理時間等）で効果を示す。
✅ 要点まとめ
記事を読み終えた読者が「何を覚えて帰るか」を3〜7点で再圧縮する。
本文のコピペではなく、エッセンスを別の言い方で表現する。
🚀 取り込み方（導入ステップ）
「明日から使うには何をすればいいか」を段階的に示す。
- 今日（5分でできること）: インストール・チュートリアル実行等の最小アクション
- 今週: 小さなプロジェクトで実際に試す
- 今月: 本番・業務フローへの組み込みと評価
各ステップに具体的なコマンドかリンクを添える。
🔥 ハマりポイント（落とし穴と回避策）
「〜と思いがちだが、実は〜」という構造で書く。
症状 → 原因 → 対処法 の三点セット形式を基本とする。
🔄 代替技術との比較
比較軸をHTMLテーブルで示し、「◯◯の方が向いているケース」も正直に書く。
📅 今後の展望
標準化・バージョンアップの動向を一次情報から引用し、「今採用する価値があるか」に答える。
Step 5: 記事執筆
文体・トーン・執筆原則は blog-writer エージェントの職種定義に従うこと。
（NG/OK文体の例、5つの執筆原則、品質判断基準はエージェント側で定義済み）
専門用語の補足ルール
専門用語が初めて登場した箇所には必ず補足を入れる。
# パターンA：括弧で一言＋例え（最も多く使う）
JITコンパイル（実行しながら必要な部分だけ機械語に翻訳する技術——通訳の即興スタイルに近い）が高速化の鍵だ。
# パターンB：文中で自然に説明する
WebAssemblyはバイナリ形式、つまり機械が直接処理できる0と1の塊として配布される。
# パターンC：脚注（長い説明が必要な場合）
WASI[^1]の登場でブラウザ外での活用が加速した。
[^1]: **WASI（WebAssembly System Interface）**: WasmがOS上でシステムリソースを扱うための標準インタフェース。
図表のルール
HTMLテーブル（Markdownパイプ記法は禁止）:
<table>
<thead>
<tr><th>技術</th><th>起動速度</th><th>向いているケース</th></tr>
</thead>
<tbody>
<tr><td>Docker</td><td>数百ms〜秒</td><td>汎用サーバーサイド</td></tr>
<tr><td>Wasm</td><td>マイクロ秒</td><td>エッジ・サーバーレス</td></tr>
</tbody>
</table>
SVG図（フロー・構造・関係図）:
<svg viewBox="0 0 640 180" xmlns="http://www.w3.org/2000/svg"
style="max-width:100%;font-family:sans-serif;">
</svg>
SVGの注意事項：
viewBox を設定し style="max-width:100%" でレスポンシブにする- 色はパステル系の背景＋明確な枠線色で統一する
- 日本語テキストは
font-family:sans-serif を指定する
Markdown フォーマット規則
ファイル先頭のFront Matter（必須）:
---
layout: default
title: [タイトル] - Rui Software
date: [作成日 yyyy-mm-dd]
---
その他のルール:
- 見出しは
##（h2）から始める（# はタイトルのみ）
- コードブロックには言語指定を付ける（
```python 等）
- 強調は
**太字** を控えめに使う（多用しない）
- セクション見出しに絵文字アイコン（📌💡✅🚀🔥🔄📅）を付けて視認性を上げる
執筆品質チェックリスト（書き終えたら全項目確認）
Step 5.5: ファクトチェック（保存前に必ず実施）
記事を保存する前に必ず実施する。ファクトチェックなしの保存は禁止。
ファクトチェックの原則は blog-writer エージェントの職種定義を参照すること。
実施手順
-
記事中の以下をリストアップする：
- すべての数値（処理時間・削減率・バージョン番号・コスト等）
- すべての固有名詞（ライブラリ名・API名・企業名・サービス名）
- 「〇〇は△△する」形式の断言
-
各項目を一次情報（公式ドキュメント・GitHubリリースノート等）で確認する
-
確認できなかった情報を以下のいずれかで処理する：
- 調査して確認する
- 「〜とされている」「〜と報告されている」に書き換える
- 情報源を明示した注釈を付ける
- 記述を削除する
-
チェック完了後、Step 6 へ進む
Step 6: ファイル保存・提供
- ファイル名はテーマを英語スネークケースで命名する（例:
transformer_architecture.md）
logs/ フォルダに保存する- 記事の概要（文字数・含まれるセクション）を一言で添える
注意事項
- 存在しないライブラリ・APIの仕様・数値を作らない（ハルシネーション禁止）
- 意見・推測には「〜と考えられる」「〜とされている」等の表現を用いて事実と区別する
- テーマが広すぎる場合はユーザーに確認してスコープを絞る
- コード例を含む場合は動作確認済みのものを優先する（不明な場合は注釈する）
- 図を「あとで入れよう」と先送りにしない
