やったこと
Claude Code から Qiita 記事を生成・投稿するスラッシュコマンド /qiita-draft を
設計しました。前回作った Qiita MCP サーバーを「どう呼ぶか」の部分にあたります。
今回はコードを書く前に、まず要件を固めて、それからコマンドの仕様を詰めて、
最後に Claude に中身（スキル定義）を出力してもらう、という順で進めました。
その設計プロセスの記録です。
背景・きっかけ
MCP サーバー単体だと「create_qiita_item にタイトルと本文を渡す」だけで、
記事を作るたびに毎回 Claude へ細かく指示する必要がありました。
これを /qiita-draft 一発で「素材集め → 記事生成 → 確認 → 投稿」まで
流せるようにしたい、というのが出発点です。
決めた要件
いきなり書き始めず、先に要件を表で確定させました。
| 項目 | 決定 |
|---|---|
| 入力ソース | 両対応：(A) git コミット (B) 現在の会話スレッドを整理 |
| 投稿フロー | プレビュー提示 → 承認 → private 下書き投稿 |
| タグ | 自動推定 → 確認・調整 |
| 文体 | 開発日記風 |
| 連携 | Qiita MCP の create_qiita_item 等のみ（GitHub MCP 不要、git はローカル） |
| 公開 | 常に private |
特に「常に private」「投稿前に必ず承認」は、事故防止のための安全側の判断です。
勝手に公開記事が増えないように、コマンド側で固定してしまいました。
コマンド設計
要件が固まったので、呼び出しインターフェースを決めました。
-
/qiita-draft [N]… モードA。直近 N コミットを記事化（既定 5） -
/qiita-draft --topic ["補足"]… モードB。会話スレッドを整理して記事化 -
/qiita-draft --tags a,b,c… タグを明示指定（省略時は自動推定して確認）
入力ソースを「コミット」と「会話スレッド」の 2 モードに分けたのがポイントです。
コミットが溜まっている時はモードA、調べ物や試行錯誤を記事にしたい時はモードB、
と使い分けられます。GitHub MCP は使わず git はローカルで叩くだけにして、
依存を減らしました。
ハマったところ・気づき
-
「下書き」をどう表現するか … Qiita API には下書きが無いので、スキル側でも
「private（限定共有）で作成し、公開は Web から手動」と運用を明文化しました。
コマンドの責務を「公開直前まで」に限定した形です。 -
タグは全自動にしない … 変更ファイルの拡張子などから推定はするものの、
最後は必ずユーザーに提示して確認する手順にしました。Qiita はタグ 1〜5 個必須で、
ズレたタグが付くと直すのが地味に面倒なためです。 -
手順をスキルとして明文化する効果 … プレビュー→承認→重複チェック→投稿、と
ステップを定義しておくと、Claude が毎回同じ安全な流れで動いてくれます。
まとめ
「要件 → コマンド仕様 → 実装（スキル定義の出力）」の順で進めたことで、
迷わず形にできました。次は実際に /qiita-draft を回して、生成される記事の質や
タグ推定の精度を見ながら、テンプレートを調整していきます。
これで初心者でも開発記録を整理・投稿が一括で出来るようになりました！
補足
今まではどうしても「開発がある程度終わるまで進めてから、一度作業した内容について整理して投稿する」という流れでした。
やったことを自分の中で飲み込むという意味では自分で記事を書くことに意味はあると思いますが、作業効率・スピード感という意味ではMCP＋skillsが圧倒的！