qiita-article-writer

name	qiita-article-writer
description	Qiita向けの技術記事を、ユーザー指定の元ネタから構成化して執筆するスキル。記事作成、技術ブログ化、検証記事化、比較記事化、実践ログの要約記事化、Qiita投稿用Markdown整形の依頼では必ず使う。元ネタが未指定なら最初に必ずヒアリングし、必要情報を具体例付きで一問ずつ確認してから本文を生成する。qiitaの記事を書きたい、などの要望があったら、まずこのスキルを呼び出す。

Qiita Article Writer

Qiita向け技術記事を、再現性と検証可能性を重視して作成するスキル。

目的

このスキルの目的は次の3点。

1. ユーザー指定の元ネタから、主張が明確な記事を作る。
2. 不足情報を具体例付きで一問ずつヒアリングし、思い込みを防ぐ。
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: 不足情報を一問ずつヒアリング

以下カテゴリを上から順に、一問ずつ聞く。

1. 対象読者
2. 前提条件とバージョン
3. 検証条件（何をもって成功とするか）
4. 試行錯誤（失敗 -> 修正 -> 結果）
5. 差別化ポイント（既存記事との違い）

質問テンプレート（毎回この形式）:

• 質問: 何を確認したいか
• 重要な理由: なぜ必要か
• 回答例: 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の文法をチェックすること
• 必要なら、本文の前に「不足情報ヒアリング」を継続する。
• ユーザーが「執筆して」と明示するまで、下書きと確認に留める運用も選べる。