# Project Design Opening

> 曖昧なソフトウェアのアイデアを対話で整理し、後続の Agent / Harness 設計に必要な「プロジェクトの基本的な境界」を docs/project-definition.md に定義する。何を作るのか、システム境界、技術（言語・ランタイム・パッケージマネージャ・主要フレームワーク・DB 種別・デプロイ先種別）、リスク（外部作用・不可逆な操作・機微情報）、環境、リポジトリ構成、運用前提までを決める。対象の種類は問わない（Web サービス、CLI、ライブラリ、デスクトップアプリ、モバイルアプリ、バッチ処理など）。「こういうサービスを作りたい」「アイデアを形にしたい」「新しいプロジェクトを始めたい」「何から決めればいいか分からない」「プロジェクト定義を作って」と言われたとき、新規プロジェクトの最初の一歩として使う。コードを書き始める前、技術選定や詳細設計に入る前の段階では必ずこの Skill を使う。詳細な機能一覧・画面仕様・API・DB スキーマ・実装手順は扱わない。既にコードがある既存プロジェクトには project-design-reboot を使う。

- Skill: `polites-co-jp/project-design-opening` (Agent Skill, multi-file: 7 files)
- Install (CLI): `npx skillmds@latest add polites-co-jp/project-design-opening`
- Raw SKILL.md: https://api.skillmd.com/api/skills/polites-co-jp/project-design-opening/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: polites-co-jp (https://skillmd.com/u/polites-co-jp)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/polites-co-jp/project-design-opening

---


# プロジェクト設計の開幕

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

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

## この Skill の位置づけ

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

```text
曖昧なアイデア
  → 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](references/input-contract.md) にある。Step 2 に入る前に読む。

| 区分 | 内容 |
|---|---|
| A 目的とスコープ | 目的／やること／やらないこと／制約 |
| B システム境界 | 利用者との接点／処理／データの保存先／外部とのやりとり／利用者の識別（認証）／配布・実行場所、および相互の関係 |
| C 技術 | 言語／ランタイム／パッケージマネージャ／主要フレームワーク／DB 種別／デプロイ先種別 |
| D リスク | 外部作用／不可逆・機微な操作／秘密情報・個人情報 |
| E 環境 | 開発環境（OS・コンテナ利用）／実行環境の段階（local・staging・本番）／リポジトリのホスティング／CI の有無 |
| F リポジトリ構成 | 単一か分離か／最上位の配置／新規か既存コードありか |
| G 運用前提 | ソロかチームか／試作か本番品質か |
| H 未決・持ち越し | 未決事項／後続の詳細設計への持ち越しメモ |

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

| 状態 | 意味 |
|---|---|
| `decided` | ユーザーが述べた、または選んだ |
| `assumed` | この Skill が推測し、ユーザーが確認した |
| `none` | 該当するものがない（例: DB を持たない） |
| `deferred` | ここでは決めず、後続に持ち越す |

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

## ワークフロー

### Step 0: 前提の点検

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

| 定義 | ハーネス | コード | 振る舞い |
|---|---|---|---|
| なし | — | なし | そのまま Step 1 へ |
| なし | — | あり | この Skill の対象ではない。`project-design-reboot` を案内して終了する |
| あり | あり | — | 何も変更せず、通常の設計作業へ案内して終了する |
| あり | なし | — | 既存の定義を置き換えることを伝え、Step 1 から最初からやり直す |

- **既にコードがあるとき**: この 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](references/input-contract.md) と照らし、まだ状態を持たない項目を洗い出す。聞く順は A → B → D → （Step 3 の技術）→ E・F・G を基本にする。目的と境界が見えないと、リスクも技術も決められないからだ。

聞き方の決まり。

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

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

**区分 D（リスク）** は、アイデアを語る場面では話題に上りにくいが、次の Skill にとって最も重要な材料である。外部にメッセージを送る、課金する、公開する、データを消す、といった操作に承認や禁止のゲートを置くためだ。ユーザーは「外部作用」という言葉では考えていないので、区分 B で挙がった外部とのやりとりとデータの保存先を一つずつ取り上げ、具体的に聞く。聞き方と例は [references/risk.md](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](references/tech-selection.md) にある。

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

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

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

### Step 5: 書き出す

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

- 書式は [assets/project-definition.template.md](assets/project-definition.template.md) に従う。記入例は [assets/example.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]` を付ける。何も無ければ「なし」と書く

## 避けるパターン

| パターン | 避ける理由 |
|---|---|
| A〜H を上から順に全部聞く | 既に話したことを聞き直され、ユーザーは話を聞いてもらえていないと感じる。質問数も倍になる |
| 機能の話を掘り下げる | 後続の詳細設計と責務が重なり、この Skill が終わらなくなる。要点だけ区分 H に残す |
| 技術を1項目ずつ聞く | 6回の質問になり、組み合わせとしての整合も崩れる。構成で提示する |
| 冒頭で技術選択モードを聞く | 何を決めるのか分からない段階では選べない。目的と境界が見えてから聞く |
| 推測を確認せずに書き出す | 次の Skill が、誤った前提の上に権限と安全策を作る |
| 該当しない項目を空欄にする | 「無い」のか「聞き忘れた」のか区別できず、後続の点検で止まる。`none` と書く |
| Agent の分割案を成果物に書く | システムの境界と Agent の境界は別物。分割は次の Skill が別の観点から決める |
| 既存コードから定義を推定する | それは `project-design-reboot` の仕事。走査の手順も、検出できなかったリスクの確かめ方も、そちらにある。この Skill は新規プロジェクト専用 |