shape

Shape — 自動グリルからPRD作成まで

大まかなプロダクトのアイデアを、一度に完全なPRDに仕上げます。対話形式で質問攻めにすることはありません。Claudeが自ら判断ツリーをたどり、ソフトウェアエンジニアリングのベストプラクティスに沿って各質問に回答し、前提に問題がないか確認できるようQ&Aをリアルタイムで表示して、PRDを作成します。

Claudeの判断を信頼してスピードを重視する場合は、/shape を使います。すべての判断を自分で細かく管理したい場合は、/grill-me + /write-a-prd を使います。

パイプラインでの位置付け

Step	Command	What It Does
1a	/grill-me + /write-a-prd	手動パス — 対話形式のヒアリングを行ってからPRDを作成します
1b	/shape	高速パス — 自動グリルからPRD作成までを一度に行います
2	/prd-to-issues	PRDを垂直スライスのサブイシューに分割します
3	/ralph	TDD + コードレビューを用いて各サブイシューを自律的に実装します

shape は write-a-prd と同じ形式でPRDを作成するため、/prd-to-issues と /ralph は出力を変更なしで利用できます。

手順

ユーザーがこのスキルを呼び出したら、次の手順に従います。

1. アイデアを把握する

ユーザーが引数としてアイデアを渡した場合は、それを使います。そうでない場合は、一度だけ次のように尋ねます。

何を作りたいですか？（1段落で構いません）

その後、手順8までは追加の対話形式の質問をせずに進めます。

2. コードベースを調査する

何かに回答する前に、実際の状況を踏まえて判断します。

• README.md、CLAUDE.md、およびアーキテクチャに関するドキュメントを読みます
• 既存のモジュール、規約、テストパターン、および機能が踏襲すべき既存の実例を特定します
• ユーザーのアイデアに含まれる事実関係の主張を確認します。鵜呑みにせず、検証してください
• 言語、フレームワーク、テストランナー、ディレクトリ構成を確認します

コードベースが存在しない場合（ディレクトリが空、またはグリーンフィールドの場合）は、手順3に進み、その旨をPRDの「補足事項」に記録します。

3. 判断ツリーをたどる

以下の各分岐について、綿密なエンジニアが尋ねるであろう質問を考え、それぞれに自分で回答します。明白に思える場合でも、分岐を省略しないでください。このスキルの要点はまさにそこにあります。

• アクターとユーザーストーリー — 誰が使うのか、何を求めているのか、成功とはどのような状態か
• ハッピーパスのフロー — 主な操作をステップごとに確認します
• エッジケース — 空の入力、大きな入力、同時アクセス、一部の失敗、ネットワークエラー、権限拒否、データ欠落、Unicode／エンコーディング、タイムゾーン
• データモデルとスキーマ — エンティティ、関係、インデックス、マイグレーション
• モジュール境界 — 深いモジュール、パブリックインターフェース、内部に留めるもの
• APIコントラクト — リクエスト／レスポンスの形式、エラーコード、冪等性、バージョニング
• テスト戦略 — テスト対象、モック対象（境界のみ）、リポジトリ内の既存の実例
• セキュリティ — 認証、認可、入力検証、シークレット、レート制限
• 可観測性 — ログに記録する内容、メトリクスとして公開する内容
• 対象外 — スコープの拡大を防ぐため、明示的に対象外とするもの
• 依存関係とブロッカー — 事前に必要なもの

4. ベストプラクティスのデフォルト

自分で回答する際は、次を優先します。

• 奇抜さより堅実さ — シンプルで広く理解されたパターン
• 深いモジュール（Ousterhout） — シンプルで安定したインターフェースの背後に幅広い機能を持たせます
• 外部標準よりコードベースに合わせる — プロジェクトの規約を優先します
• TDDに適した設計 — 内部実装ではなく、パブリックインターフェースを通じてテストできる設計
• システム境界で検証する — 内部の呼び出し元は信頼し、境界では明確に失敗させます
• YAGNI — 先を見越した抽象化や、ユーザーが求めていない機能は追加しません
• パラメーター化クエリを使い、文字列連結はしません
• 認証エンドポイントにはレート制限を設けます
• シークレット、トークン、PIIは決してログに記録しません
• システム境界（外部API、DB、時間、乱数、ファイルシステム）のみをモックします — 内部の協調オブジェクトは決してモックしません

コードベースの事実は、常に一般的なベストプラクティスより優先されます。 プロジェクトですでにXを採用しているなら、回答もXです。

5. Q&Aをリアルタイムで表示する

判断を下すたびに、まとめて出力するのではなく、その場で次の厳密な形式のブロックを出力します。

Q: <the question>
A: <the chosen answer>
Why: <one sentence — cite a codebase reference if relevant>

これにより、ユーザーは前提に問題がないか早い段階で確認できます。

6. PRD を作成する

このテンプレートをそのまま使用してください。/write-a-prd と一致しているため、パイプラインの残りの部分でも変更せずに受け付けられます。

## Problem Statement

The problem the user is facing, from the user's perspective.

## Solution

The solution, from the user's perspective.

## User Stories

A long, numbered list:
1. As a <actor>, I want a <feature>, so that <benefit>

Cover every aspect of the feature surfaced in your decision tree.

## Implementation Decisions

- Modules to build or modify
- Public interfaces of those modules
- Architectural decisions
- Schema changes
- API contracts
- Specific interactions

Do NOT include file paths or code snippets — they go stale fast.

## Testing Decisions

- What makes a good test here (test external behavior, never implementation details)
- Which modules will be tested
- Prior art for the tests (similar patterns already in the codebase)

## Out of Scope

Explicit non-goals.

## Further Notes

Anything else worth recording.

## Decisions Log

Every Q/A/Why block from step 5, in the order they were decided.

7. PRD をローカルに保存する

• アイデアから kebab-case のスラッグを生成します（例：「rate-limited /healthz endpoint」→ rate-limited-healthz-endpoint）
• ./prds/ が存在しない場合は作成します
• PRD を ./prds/<slug>.md に書き込みます
• 絶対パスを出力します

8. GitHub へのプッシュを提案する

保存後、ユーザーに一度だけ尋ねます。

これを GitHub issue としてプッシュしますか？ [y/N]

y の場合は、次を実行します。

gh issue create --title "<slug>" --body-file ./prds/<slug>.md

issue の URL を出力します。

n または無回答の場合は、そこで終了します。ローカルファイルがあれば十分です。ユーザーは後からプッシュできます。

ルール

• 意思決定ツリーの途中でユーザーに質問しないでください。 自動で回答することが目的です。対話が必要なのは、アイデアを受け取るとき（まだ提示されていない場合）と、最後の GitHub プッシュの確認だけです。
• 分岐を省略しないでください。 些細に思える分岐もすべて確認してください。完全性に価値があります。
• 一般的なベストプラクティスより、コードベースの事実を優先します。 プロジェクトですでに X を行っている場合、答えは X です。
• 推測でスコープを広げないでください。 ユーザーが求めておらず、コードベースも必要としていないことは、「対象外」に含めます。
• PRD テンプレートは固定です。 /write-a-prd と完全に一致させる必要があります。これにより、/prd-to-issues と /ralph が引き続き動作します。