Intent Planner — Testing skill for Claude Code

intent-planner

 

README: [日本語](README.md) | [English](README.en.md)

[デモ動画](https://youtu.be/S8bx6JOgPuI) · [10分ウォークスルー](docs/walkthrough.md) · [詳しいガイド](https://github.com/ijust/intent-planner/blob/main/docs/guide.md)

AIに作業を頼んだとき、個々の変更は悪くないのに、全体が少しずつ思っていた方向から外れることがあります。intent-plannerは、作業の前に「何を実現したいか」「何を壊してはいけないか」を整理し、仕様作成や実装へ渡すための軽量な計画レイヤーです。

企画書、調査、文書づくりにも使えます。Claude Code、Codex、Gemini CLIに対応し、整理した内容はcc-sdd、OpenSpec、Spec Kitへ渡すか、そのまま小さな実装単位として使えます。

特に、設計のずれや手戻りが大きな損失になる**高リスクな案件**に向いています。短い試作やvibe codingで十分な変更には**過剰**になり得るため、作業単位から直接進む`direct`経路を使うか、intent-plannerを省略してください。

どんなときに使うか

やりたいこと	使い方
企画書・調査メモ・手順書をまとめる	質問に答えながら意図を整理し、読める文書へ変換する
AIに開発を頼む	仕様を書く前に、目的・判断基準・実装単位を揃える
既存コードの意図を復元する	コードから候補を抽出し、推測であることを明示して確認する
実装後のずれを直す	実装で分かったことを記録し、承認した内容だけ計画へ戻す

専門的な分類名や案件種別を先に選ぶ必要はありません。目的、作りたい成果物、手元の資料、次に行いたい判断のどれか一つを伝えれば始められます。

コードを書かない場合

企画書、記事の構成、調査結果、業務手順なども、同じように意図を整理できます。AIが目的・読み手・必要な判断を確認し、最後に`intent-to-spec`で1本の読める文書へまとめます。根拠が確定していない部分は推測として区別されます。

AIに実装を頼む場合

仕様を書く前に、解決したい問題と実装中の判断基準を揃えます。その後は次のいずれかへ進めます。

• cc-sdd、OpenSpec、Spec Kit向けの下書きを作る
• 十分に小さく明確な作業単位なら、direct経路で実装へ進む

intent-plannerは下書きと判断基準までを担います。下流ツールの仕様作成や実装を自動的に開始せず、その状態も管理しません。先に完成した作業単位（骨格）が確立した約束事は、依存宣言をたどって後続の下書きへ自動で運ばれます。

何を作るか考える場合

実装方法が決まっていなくても使えます。誰のどんな問題を解くか、成功を何で判断するか、今回決めないことは何かを先に整理します。画面設計やサービス設計などの専門的な観点は、案件に合うときだけ候補として提示され、採用するかは利用者が決めます。

たとえば「サブスクリプションの解約問い合わせを減らしたい」という相談なら、同じ要望を複数の観点から見ます。

観点	出てくる問い・助言の例
PdM（製品を決める観点）	問い合わせの原因には根拠があるか。誰のどの状況を改善するか。成功を問い合わせ件数、完了率、再契約率のどれで見るか。解約ボタン追加以外の選択肢はあるか。
サービスデザイナー（利用体験を設計する観点）	解約を考え始めてから完了後までに、どの接点・待ち・引き継ぎがあるか。画面の裏でどの担当者や処理が支えるか。失敗、離脱、再開をどう扱うか。
画面を設計する観点	重要情報をどの順で見せるか。通常時だけでなく、読込中・失敗・権限不足・完了をどう伝えるか。次に取れる行動が明確か。
技術の定石	二重操作でも処理が重複しないか。認可と監査記録をどう守るか。外部決済の失敗や再試行、データ移行、回帰テストをどう扱うか。

必要な観点・検討項目・仮の答