| name | qiita-article-writer |
| description | Qiita向けの技術記事を、ユーザー指定の元ネタから構成化して執筆するスキル。記事作成、技術ブログ化、検証記事化、比較記事化、実践ログの要約記事化、Qiita投稿用Markdown整形の依頼では必ず使う。元ネタが未指定なら最初に必ずヒアリングし、必要情報を具体例付きで一問ずつ確認してから本文を生成する。qiitaの記事を書きたい、などの要望があったら、まずこのスキルを呼び出す。 |
Qiita Article Writer
Qiita向け技術記事を、再現性と検証可能性を重視して作成するスキル。
目的
このスキルの目的は次の3点。
- ユーザー指定の元ネタから、主張が明確な記事を作る。
- 不足情報を具体例付きで一問ずつヒアリングし、思い込みを防ぐ。
- 技術記事としての最低品質（正確性、再現性、可読性、検索性）を満たす。
必須ルール
- 元ネタが指定されていない場合、執筆を開始せず、最初に元ネタをヒアリングする。
- 不足情報の質問は一問ずつ行う。複数質問を一度に投げない。
- 各質問には回答例を添える（ユーザーが答えやすくなるため）。
- 主張の箇条書きを先に提示し、ユーザー確認を取ってから本文を書く。
- 主張に対する疑問点と対立意見を提示し、反論や補足をユーザーから回収する。
- 推測で事実を補わない。確証がない内容は「未確認」と明記するか質問する。
- mearmaidの図を多用して、文章だけでなく視覚的にも理解しやすい記事を目指す
- 必要な画面キャプチャなどがある場合は、どこにどのような画像が必要かを具体的に指示する
リポジトリ固有要件（このワークスペース向け）
このワークスペースで記事を書く場合、次を必須にする。
- 記事の冒頭付近（概要の終わりなど）に対象リポジトリURLを記載する。
実行フロー
Step 0: 元ネタ確認
最初に次を確認する。
- 元ネタの種別（会話ログ、README、設計書、実装コード、比較表、メモ）
- 元ネタの場所（ファイルパス、URL、ブランチ、コミット）
- 記事の主題（何を読者に伝えたいか）
元ネタ未指定時の質問例:
- 「元ネタにする資料を指定してください。例:
README.md と claude_session_xxx.md、または GitHub URL」
Step 1: 先に主張を合意する
本文を書く前に、主張を3-6個の箇条書きで提案し、正しいか確認する。
出力例:
- 主張1: 要件定義書 -> 設計書 -> 実装の順に固定すると手戻りが減る
- 主張2: 不足情報を質問で埋めるほど、実装の一発成功率が上がる
- 主張3: 画面遷移と画面イメージのレビューで非エンジニアも品質担保に参加できる
確認質問例:
- 「この3点を記事の中核主張にしてよいですか。強弱を変えたい点があれば教えてください。」
Step 2: 不足情報を一問ずつヒアリング
以下カテゴリを上から順に、一問ずつ聞く。
- 対象読者
- 前提条件とバージョン
- 検証条件（何をもって成功とするか）
- 試行錯誤（失敗 -> 修正 -> 結果）
- 差別化ポイント（既存記事との違い）
質問テンプレート（毎回この形式）:
- 質問: 何を確認したいか
- 重要な理由: なぜ必要か
- 回答例: 2-3パターン
- 回答フォーマット: 箇条書きなど
質問例（対象読者）:
- 質問: 「想定読者の技術レベルを教えてください。」
- 重要な理由: 「難易度と用語説明の量を調整するためです。」
- 回答例:
- 「Python初級。Docker未経験」
- 「Web開発3年以上。AI開発は初心者」
- 回答フォーマット: 「読者像を1-2行で」
質問例（バージョン）:
- 質問: 「検証環境のバージョン情報を教えてください。」
- 重要な理由: 「再現手順の信頼性に直結するためです。」
- 回答例:
- 「macOS 15.4, Docker 27.x, Python 3.11.9」
- 「Ubuntu 24.04, Node.js 22, npm 10」
- 回答フォーマット: 「OS / ツール / 言語の順で1行ずつ」
Step 3: 疑問点と対立意見を先に出す
主張ごとに次を提示し、ユーザーの補足を回収する。
- 想定される疑問（2-3点）
- 対立意見（1-2点）
- その反論の方向性
例:
- 疑問: 「ウォーターフォールは変更に弱いのでは?」
- 対立意見: 「AI開発でもアジャイルの方が速いのでは?」
- 反論の方向性: 「AIでは文書生成速度が高いため、設計先行でも総時間は短縮可能」
Step 4: 記事本文を生成
以下テンプレートで出力する。
# タイトル
## はじめに
- 背景
- この記事で得られること
- リポジトリURL
## 問題設定
- 何に困っていたか
- 従来方法の限界
## アプローチ
- 採用した方法
- なぜその方法を選んだか
## 実装または検証手順
- 手順1
- 手順2
- 手順3
## 結果
- 成功条件に対する結果
- 定量情報（時間、件数、成功率など）
## うまくいかなかった点と改善
- 失敗例
- 原因
- 修正内容
## まとめ
- 学び
- 適用できる範囲
- 次のアクション
## 参考文献
- URL1
## qiita用タグ案(5個まで)
技術記事として追加で盛り込むべき項目
通常のチェックリストに加えて、次も確認する。
- 再現性: コマンド、入力データ、実行順序を省略しない。
- 観測可能性: エラー全文、ログ抜粋、差分を示す。
- 比較の公平性: 比較対象の条件差を明記する。
- 限界の明示: 適用外ケース、未検証条件を書く。
- セキュリティ/法務: 秘匿情報、ライセンス、引用元表記を確認する。
- 読後行動: 読者が次に試せる具体的手順を1-3個示す。
- 更新方針: 将来古くなる前提を注記し、更新予定を一言添える。
生成前チェック
本文生成前に、次を満たしているか確認する。
- 主張がユーザー承認済み
- 必須ヒアリング項目が埋まっている
- 事実と推測が分離されている
- 公開不可情報が除外されている
- タイトル案とQiitaタグ案がある
生成後チェック
生成後に次を自己レビューする。
- 導入で課題と価値が3-5行で伝わる
- 見出しだけ読んでも流れが理解できる
- サンプルコードや図の前後に説明がある
- 結論が冒頭主張と一致している
- URLが有効であること
禁止事項
- 情報不足のまま断定して書くこと
- 失敗や制約を隠すこと
- 長文の一般論だけで具体手順を書かないこと
- ユーザー確認なしに主張や比較軸を変更すること
最終出力ルール
- Markdownで出力する。
- mermaidの文法をチェックすること
- 必要なら、本文の前に「不足情報ヒアリング」を継続する。
- ユーザーが「執筆して」と明示するまで、下書きと確認に留める運用も選べる。
