プロジェクト設計の開幕

曖昧なソフトウェアのアイデアを、対話で「プロジェクト定義」に変換する Skill。

• 入力: ユーザーの頭の中にあるアイデア。一言でも、長い説明でもよい
• 出力: docs/project-definition.md。後続の Skill が追加の聞き取りなしで読める、固定書式のプロジェクト定義
• 対象: これから始める新規プロジェクト。種類は問わない（Web サービス、CLI、ライブラリ、デスクトップアプリ、モバイルアプリ、バッチ処理など）
• 扱わないこと: 詳細な機能一覧、個々の画面仕様、API エンドポイント、DB テーブル、詳細な認証方式、コンポーネント設計、ディレクトリ構造の詳細、実装手順

この Skill の位置づけ

AI を使った開発を、3つの Skill の連鎖で進める。この Skill はその最初の一歩を担う。

曖昧なアイデア
  → project-design-opening（この Skill）  プロジェクトの境界を定義する
  → project-design-harness               開発を担う Agent とハーネス（権限・検証・状態管理）を作る
  → 詳細設計の Skill                      機能・要件・システム設計を詰める
  → 開発

Agent に開発を任せるには、モデルの賢さより先に「何を扱うシステムなのか」「どこに境界があるのか」「外の世界にどんな作用を及ぼすのか」が決まっている必要がある。権限も、検証の方法も、承認が要る操作も、そこから導かれるからだ。この Skill はその材料を揃える。

したがって終了条件は、全部を決めることではない。次の Skill が、プロジェクトの基本情報をユーザーに聞き直さずに動ける状態になること。具体的には、入力契約 A〜H の全項目が状態を持つこと（後述）。

5つの原則

1. 決めるのは境界まで

この Skill は要件定義ではない。詳細な機能や設計を決め始めると、後続の詳細設計と責務が重なり、対話も長くなる。決めるのは、後続が Agent とハーネスを設計し始められるところまで。「予約を受け付ける Web サービスで、DB があり、決済の外部サービスを使う」までがこの Skill の範囲で、「予約テーブルの列」や「予約画面の項目」は範囲外。

2. A〜H は質問票ではなく点検表

入力契約 A〜H を上から順に聞いてはいけない。ユーザーの説明から読み取れる項目は聞かずに埋め、足りない項目だけを聞く。「Web アプリを作りたい」と言った人に「Web が必要ですか」と聞き返すと、話を聞いていないと受け取られる。A〜H は、聞き漏らしがないかを最後に確かめるための点検表として使う。

3. ユーザーに Agent 設計を求めない

ユーザーは「どこで Agent を分けるか」を知らなくてよい。この Skill が集めるのはシステムの境界であり、Agent の境界ではない。Web・Backend・DB という構成だからといって、Agent が3つになるわけではない。Agent の分割は次の Skill が、責務・ツール・権限・リスク・検証方法から決める。この Skill の成果物に Agent の名前や分割案を書かない。

4. 技術は「構成」として決める

技術は、個別の部品ではなく組み合わせ（構成）として扱う。粒度はツールチェーンが決まるところまで。言語・ランタイム・パッケージマネージャ・主要フレームワーク・DB 種別・デプロイ先種別の6項目は必ず決める。次の Skill が、許可するコマンドを具体的な名前で書くためだ。それより細かい選択（テストランナー、linter、ORM、UI ライブラリ、REST か GraphQL か）は後続の詳細設計に任せる。

5. 推測は仮定として見せ、確認を取る

質問を減らすために、推測で埋められる項目は推測してよい。ただし推測を黙って確定させない。仮定として一覧で見せ、ユーザーに確認してもらってから書き出す。確認を取っていない推測が成果物に入ると、次の Skill がその上に権限や安全策を組み立ててしまう。

入力契約 A〜H

成果物は次の8区分を持つ。各区分の項目と「埋まったと言える基準」は references/input-contract.md にある。Step 2 に入る前に読む。

各項目は次のいずれかの状態を持つ。状態のキーは、成果物を何語で書いても変えない。後続の Skill がこの列を見て点検するためだ。

none は立派な答えである。「外部作用なし」「DB なし」が明記されていることで、次の Skill は安全策を省いてよいと判断できる。空欄とは意味が違うので、該当しない項目は必ず none と書く。

ワークフロー

Step 0: 前提の点検

始める前に、作業ディレクトリの状態を見る。見るのは3点。docs/project-definition.md があるか。ハーネスがあるか（docs/agent-architecture.md があり、そこに一覧された生成ファイルが実際に存在するか）。ソースコードがあるか（README や LICENSE、.gitignore、docs/ だけならコードなしと見なす）。

• 既にコードがあるとき: この Skill は新規プロジェクト専用である。既存プロジェクトには、リポジトリを走査して同じ書式の定義を作る project-design-reboot がある。それを案内して終了する。この Skill の中で、コードを読んで定義を推定し始めない。
• ハーネスが既にあるとき: この Skill は開幕専用で、更新モードを持たない。定義の変更（決済を足す、モバイルアプリも作る、など）は、そのプロジェクトの通常の設計作業として docs/project-definition.md を直接更新してもらう。C（技術）・D（リスク）・E（環境）が変わる場合は project-design-harness の再実行が必要になることも伝える。権限と安全策はこの3区分から導かれているためだ。
• やり直すとき: 既存の定義は置き換わる。先にそのことを伝えてから進む。

Step 1: アイデアを聞く

ユーザーが既にアイデアを説明していれば、聞き直さずにそれを材料にする。まだなら、開いた質問を1つだけする。「何を作りたいですか。誰が、何のために使うものですか」。

聞いた内容から、A〜H のうち読み取れる項目を埋めていく。この時点の理解を短く要約してユーザーに返し、ずれていないかを確かめる。要約は3〜5行。ここで長い文書を見せない。

アイデアを語る人は、境界より先に機能を語る。「こんな画面があって、こういう通知が来て…」という話が出たら、遮らずに聞き、次のように扱う。

• 要点を区分 H に deferred として書き留める。追加の質問で掘り下げない
• 「詳細は次の段階で扱うので、今はメモとして残します」と一言伝える。話したことが消えないと分かれば、ユーザーは安心して先へ進める
• ただし、話の中に入力契約に効く情報があれば、該当の区分に反映する。「クレジットカードで払えるようにしたい」は機能の話だが、区分 D の外部作用（課金）であり、区分 B の外部とのやりとり（決済サービス）でもある

Step 2: 足りない項目だけを聞く

references/input-contract.md と照らし、まだ状態を持たない項目を洗い出す。聞く順は A → B → D → （Step 3 の技術）→ E・F・G を基本にする。目的と境界が見えないと、リスクも技術も決められないからだ。

聞き方の決まり。

• 選択式の質問ツールが使える環境ではそれを使い、無ければ平文で聞く
• 一度に聞くのは1つの話題。関連する小さな項目（ソロかチームか、試作か本番か）はまとめてよい
• 選択肢を出すときは、選んだ結果どうなるかを添える。推奨があれば先頭に置き、推奨であることを示す
• 「分からない」「任せる」という答えは正当な答えとして扱う。理由を添えて推測するか（→ Step 4 で確認）、ここで決める必要がなければ deferred にする
• ユーザーが知っているはずのないことを聞かない。「外部作用はありますか」ではなく、具体的に聞く（後述の区分 D）

区分 B（システム境界） は、種類を問わない問いで捉える。利用者はどこから触るのか。処理はどこで動くのか。データはどこに残るのか。外部の何とやりとりするのか。利用者を識別するのか。どこに配って、どこで動かすのか。該当しないものは none。種類別の典型例と、境界の図の描き方は references/boundaries.md にある。

区分 D（リスク） は、アイデアを語る場面では話題に上りにくいが、次の Skill にとって最も重要な材料である。外部にメッセージを送る、課金する、公開する、データを消す、といった操作に承認や禁止のゲートを置くためだ。ユーザーは「外部作用」という言葉では考えていないので、区分 B で挙がった外部とのやりとりとデータの保存先を一つずつ取り上げ、具体的に聞く。聞き方と例は references/risk.md にある。粒度は「何があるか」まで。承認の流れや権限の設計には踏み込まない。

Step 3: 技術を構成単位で決める

目的とシステム境界が見えてから、技術の話に入る。冒頭では聞かない。何を決めることになるのか分からない段階で選ばせても、ユーザーは答えようがない。

1. ユーザーが既に指定している技術は、そのまま decided として採用する。以降の候補は、それと矛盾しないものに絞る
2. 6項目がすべて指定済みなら、このステップは終わり
3. 残りがあれば、技術選択モードを1回だけ聞く
   • Mode 1（候補から選ぶ）: 要件に合う構成を 2〜3 案、理由つきで提示する。1つ選んでもらい、変えたい項目だけ調整する
   • Mode 2（任せる）: 「よく使う構成があれば教えてください」を1回聞く。あればそれに寄せる。無ければ、その要件に対して一般的によく使われる構成を選ぶ。決めた構成を理由とともに示し、異議がある項目だけ直す
4. 該当しない項目は none（DB を持たない CLI の DB 種別など）

どちらのモードでも、6項目をばらばらに6回聞かない。構成として1〜2回の質問で決める。構成の選び方、提示の書き方、整合性の確かめ方は references/tech-selection.md にある。

Step 4: 仮定をまとめて確認する

ここまでに推測で埋めた項目を、一覧にして見せる。項目、推測した内容、そう推測した理由を1行ずつ。ユーザーに、違うものだけ直してもらう。

確認が取れた推測は assumed になる。確認が取れていない推測を assumed と書いてはいけない。ユーザーが判断できない項目は、deferred にして区分 H に回す。

Step 5: 書き出す

全項目が状態を持ったら、docs/project-definition.md を書く。docs/ が無ければ作る。

• 書式は assets/project-definition.template.md に従う。記入例は assets/example.md
• 本文はユーザーが会話している言語で書く。区分の記号（A〜H）、状態のキー、フロントマターのキーは言語によらず固定
• フロントマターの status は complete。updated は書き出した日付
• ユーザーが途中で切り上げたいと言ったら、status: draft で書き出し、状態の付いていない項目を区分 H に列挙する。次の Skill は draft の定義では動かない

書き出したら、定義の全体をユーザーに見せる必要はない。ファイルの場所と、決まったことの要点（何を作るか、構成、リスクの有無）を短く伝える。

Step 6: 次の段階を案内する

次は project-design-harness で、この定義を入力に Agent とハーネスを作る段階であることを伝える（Claude Code 向け）。この Skill の中で Agent の設計を始めない。

出力フォーマットの決まり

• 1ファイルの Markdown。同じ内容の YAML や JSON を別に出さない。二重に持つと片方だけ直されてずれる
• 先頭の YAML フロントマターに schema: project-definition/1、status、updated を持つ
• 見出しは ## A. 〜 ## H. の固定順。区分を省略しない
• A〜G は「項目／内容／状態」の3列の表。1行に1項目。内容が複数ある項目（外部サービスが2つある、など）は行を分ける
• 区分 B には表に加えて、境界同士の関係を示すテキストの図を置く
• ツールチェーンが複数ある場合（モバイルアプリと Backend で言語が違う、など）は、区分 C の表を構成要素ごとに分ける
• 区分 H は箇条書き。各行の先頭に [deferred] を付ける。何も無ければ「なし」と書く

避けるパターン