spec-generator

仕様書生成スキル

曖昧なプロダクトのアイデアを、スケッチ、スクリーンショット、メモ、その他のドキュメントを参考にしながら、開発チームが実行に移せる、明確で構成の整ったプロダクト仕様書に仕上げます。

これは常にプロダクト仕様書を作成します。対象は、顧客向けプロダクト、社内ツール、スタッフ向けシステムなどです。これらはいずれもプロダクトです。機能仕様書、API 仕様書、インテグレーション仕様書は作成しないでください。

目指すべき仕上がり

優れた仕様書は、次の条件を満たします。

• 簡潔でありながら完全で、冗長な記述や抜けがない
• 企業用語ではなく、平易な言葉を使っている
• 必要に応じて明確な提案を行い（例：妥当なデフォルトの技術スタックや動作を提案する）、チームが決める必要のある点は明示している
• 暗黙の前提を洗い出し、明確にしている
• 細部まで検討した、経験豊富なシニア PM やテックリードが書いたような内容になっている

---

プロセス

ステップ 1：入力を収集して理解する

ユーザーから提供された情報をすべて確認します。

• 説明文 — 1 文だけでも着手できます
• アップロードされたファイル — メモ、既存のドキュメント、データモデル、ワイヤーフレーム、スクリーンショット、モックアップなど、すべて確認します
• 画像 — 注意深く確認し、暗黙の機能、フロー、制約を読み取ります

下書きを作成する前に、ユーザーから提供された情報をすべて確認し、仕様書に大きく影響する情報の不足がないか特定します。技術スタックが提示されていない場合は、必ず希望を確認してください。技術スタックは、プロジェクトの方向性や機能に影響する可能性があります。提供された情報から妥当に推測できないことがほかにもあれば、質問してください。すでに明らかなことや、妥当なデフォルトで決められることは質問しないでください。質問は簡潔にまとめて一度に尋ね、複数のターンに分けないでください。

ステップ 2：仕様書の下書きを作成する

以下のテンプレートを使用します。必要に応じてセクションを調整してください。すべての仕様書にすべてのセクションが必要とは限りません。適切に判断し、該当しないセクションはプレースホルダーテキストで埋めずに省略してください。

---

仕様書テンプレート

# [Product Name] — Specification

> **Context:** [1–2 sentences on why this is being built and what informed this spec — e.g. team discussions, user research, a UI sketch.]

## Overview

[2–4 sentences. What is this? Who uses it? What problem does it solve? What is it NOT?]

---

## Goals

- [Concrete, measurable goal]
- [Another goal]
- [Keep this list short — 3–6 items]

---

## User Roles

### [Role Name]
- [What they can do]
- [What they cannot do / what they see or don't see]
- [How they authenticate or access the system]

[Repeat for each role]

---

## Core Features

### 1. [Feature Name]

[Description. Be specific — what does the user do, what happens, what are the constraints? Mention edge cases where relevant.]

### 2. [Feature Name]

[...]

[Continue for all major features, numbered.]

---

## Technical Stack

- **[Layer]** — [Technology]
- **[Layer]** — [Technology]

---

執筆ガイドライン

曖昧にせず、具体的に書いてください。「ユーザーはアカウントを管理できます」ではなく、「ユーザーは登録済みのメールアドレスに送信されるリンクから、メールアドレスの更新やパスワードのリセットができます」と書きます。

**妥当なデフォルトで曖昧さを解消してください。**ユーザーが指定していないこと（例：ページネーションの上限）は、妥当な値を選んで明記します。空欄のままにしないでください。

**顧客向けと内部向けを分けてください。**対象者が 2 種類（例：エンドユーザーとスタッフ）いる場合は、構造を明確にし、セクションやロールの説明を分けてください。

**暗黙の制約を明示してください。**入力情報から制約が推測される場合（例：スケッチに検索バーがないため、検索はおそらく対象外であること）は、該当する機能の説明に記載してください。

**技術スタックの記載は任意です。**技術スタックが判明している、または強く示唆されている場合にのみ記載します。不明な場合は、セクション自体を省略してください。技術を提案する際は、ウェブ検索を行って、推奨内容が最新で今も標準的な選択肢か確認してください。すでに置き換えられていたり、一般的に使われなくなったりしたパッケージやライブラリは避けてください。

**「対象外」セクションは決して追加しないでください。**仕様書テンプレートにある構成だけを使用し、テンプレートにないセクションは追加しないでください。

---

出力形式

仕様書を .md ファイルとして /mnt/user-data/outputs/spec.md に保存します。present_files を使ってユーザーに提示してください。

ファイルを提示した後、重要な前提を明記した簡潔な要約を 1～2 文で伝えてください。