name: individual-article description: "ダイジェストとは別の深掘り個別記事を作成する。dev-knowledge / case-study向け。"

個別記事作成スキル（dev-knowledge / case-study）

このスキルは、ダイジェストとは別の深掘り記事を作成する手順を定義する。

概要

項目	内容
対象	dev-knowledge / case-study カテゴリの記事
目的	深さ・独自価値の提供
目標文字数	8,000〜20,000字
目標読了時間	10〜20分
所要時間	5〜9時間

3つの記事型

どの型で書くかを最初に決定する。

1. キュレーション型（★推奨）

既存の良質なリソースを評価・比較し、読者に最適な学習パスを案内

特徴:

一次ソースへの敬意を払いつつ、独自の評価軸で整理
「どれを読むべきか」「どの順番で学ぶべきか」を提示
原文リンク + 日本語での要点解説 + 独自の実践視点

例: 「プロンプトエンジニアリング完全ガイド — 公式ドキュメントから実践者の知見まで」

2. 事例分析型

実際の成功/失敗事例を深掘り分析し、再現可能な教訓を抽出

特徴:

具体的な数字（売上、ユーザー数、開発期間）
時系列での軌跡
「なぜうまくいったか/いかなかったか」の分析
読者が活かせる原則の明確化

例: 「Pieter Levelsの事例 — 従業員ゼロ・AIだけで年収3億円」

3. 実践ガイド型

特定のスキル・ツールを「使えるようになる」ための具体的手順

特徴:

実際に動くコード・設定例
ビフォー/アフターの比較
よくある失敗とその回避法
段階的な難易度設定

例: 「MCP実践ガイド — ゼロから動くサーバーまで」

5 Phaseワークフロー

Phase 1: テーマ選定（30分）

チェックリスト:

ターゲット読者（AIソロ開発者）にとって価値があるか
既存記事との差別化ポイントがあるか
一次ソースが十分に存在するか
自分（または参照可能な実践者）に実体験があるか

テーマ発見ソース:

Hacker News（AI/dev関連で100+ポイント）
X/Twitter（@levelsio, @karpathy, @simonw等）
GitHub Trending
ProductHunt
読者からの質問・リクエスト

出力: テーマ決定 + 記事型選択

Phase 2: 一次ソースリサーチ（1〜2時間）

ソース記録テンプレートと収集対象の詳細は → references/template-source-list.md

出力: ソースリスト（最低3つの一次ソース）

Phase 3: 既存リソース評価（1時間）

評価軸:

軸	説明
正確性	情報が正確か、最新か
深さ	表面的 vs 本質的
実用性	読んだ後に行動できるか
独自性	他で読めない視点があるか
日本語対応	日本語で読めるか、日本向け解説があるか

出力:

どのリソースを推奨するか
各リソースの強み/弱み
読む順番の提案

Phase 4: 独自価値の設計（30分）

問い:

「この記事でしか得られない価値は何か？」

独自価値の出し方:

日本向けローカライズ — 海外記事の日本市場への適用
比較・評価 — 複数のリソースを横断的に評価
実践検証 — 実際に試した結果を共有
構造化 — 散らばった情報を体系的に整理
学習パス提示 — 「次に何をすべきか」を明示

出力: 記事構成案（見出しレベル）

Phase 5: 執筆・公開（2〜4時間）

必須要素:

冒頭で「この記事で得られること」を明示
一次ソースへのリンク（敬意を払う）
具体的な数字・データ
表形式での比較（読みやすさ）
実際のコード例・設定例（該当する場合）
「次のアクション」を明示
関連プロダクトへのリンク（relatedProducts）

品質チェック:

8,000字以上
読了時間10分以上
「どこでも読める内容」になっていないか
実証・データがあるか
読者が行動に移せるか
編集部コメント（エンジニア・デザイナー・マネージャー・デスク）を追加したか
comment-name に人名が入っていないか（絵文字のみ: 🔧/🎨/📊/📋）

サムネイル画像生成（公開前必須）:

スキル: ~/.agents/skills/thumbnail-generator/SKILL.md

暗い回路基板・汎用IT画像は禁止。記事内容に合った画像を使う。

記事タイプ	推奨ソース
抽象概念・フレームワーク	Pollinations.ai
製品レビュー・ツール紹介	Pollinations.ai or 公式画像
人物インタビュー・事例	Unsplash（人物系）

サムネイル生成スクリプト → scripts/generate-thumbnail.sh

記事内画像エンリッチメント:

スキル: ~/.agents/skills/article-image-enricher/SKILL.md

画像エンリッチメントスクリプト → scripts/enrich-images.sh

編集部コメントの追加（必須）:

編集部コメントの役割・CSSクラス・仕様 → references/editorial-comments.md

公開:

公開スクリプト → scripts/publish.sh

実行前に article-quality-check と publish-gate（Step 0で画像エンリッチメント確認含む）を実施すること。

曜日別テーマ（平日編集枠 12:30）

曜日	カテゴリ	記事型の推奨
月	dev-knowledge	キュレーション型 or 実践ガイド型
火	case-study	事例分析型
水	product	プロダクト辞書更新（ニュースとして出す場合あり）
木	dev-knowledge	キュレーション型 or 実践ガイド型
金	case-study	事例分析型

参照ドキュメント

ドキュメント	用途
`docs/WORKFLOW-ARCHITECTURE.md`	全体アーキテクチャ
`docs/CHECKLIST.md`	品質基準
`~/.openclaw/skills/publish-gate/SKILL.md`	公開手順
`~/.openclaw/skills/article-quality-check/SKILL.md`	品質チェック
`references/template-source-list.md`	ソース記録テンプレート
`references/editorial-comments.md`	編集部コメント仕様
`references/table-guidelines.md`	テーブル作成ガイドライン
`scripts/generate-thumbnail.sh`	サムネイル生成
`scripts/enrich-images.sh`	記事内画像エンリッチメント
`scripts/publish.sh`	公開コマンド

よくある落とし穴

編集部コメントの comment-name に人名を入れる: 絵文字のみ（🔧/🎨/📊/📋）が正しい。人名を入れてはいけない
サムネイルに暗い回路基板・汎用IT画像を使う: 記事内容に合った画像を使うこと。Pollinations.ai で記事テーマに即した画像を生成するのが推奨
8,000字未満で公開してしまう: 品質基準として8,000字以上・読了10分以上が必須。「どこでも読める内容」になっていないかチェック
一次ソースへのリンク不足: キュレーション型・事例分析型いずれも最低3つの一次ソースが必要。敬意を払い、原文リンクを必ず含めること
記事型を決めずに書き始める: キュレーション型・事例分析型・実践ガイド型のどれで書くかを最初に決定しないと、構成がブレて完成度が下がる

更新: 2026-02-15（テーブルガイドライン追加）