speckit-baseline

speckit-baseline

出典に関する説明：このスキルが生成する仕様の構造は、GitHub Spec Kit のテンプレート規約（MIT License, Copyright GitHub, Inc.。全文は同じディレクトリの LICENSE.txt を参照）に準拠しています。 「既存コードから要件を逆抽出する」実行フローは本プロジェクト独自のものであり、Spec Kit 公式のコマンドセットには含まれません。

使用するタイミング

• コードベースに要件ドキュメントがなく、信頼できる仕様を補う必要がある場合。
• リファクタリング、移行、または引き継ぎの前に、現行の実際の振る舞いをレビュー可能なベースラインとして記録する場合。
• ドキュメントのないレガシーシステムを引き継ぎ、「現行の振る舞い」と「あるべき振る舞い」を区別する必要がある場合。

入力

• 対象範囲：パス、ファイル一覧、モジュール名、または glob パターン。
• コードベースのコンテキスト：ソースコードを読み取れる必要があります。.specify/ ディレクトリが存在する場合は、その中のテンプレートとスクリプトも読み取ります。
• 任意のビジネス背景：ドメイン用語、ユーザーの役割、外部依存先。

対象範囲が不足しているか曖昧な場合は、先に焦点を絞った質問を 1 つしてから続行します。

ワークフロー

Step 1 — 範囲を定義する

分析対象となる最小の完全な単位を確認します。1 つのモジュール、インターフェース群、またはエンドツーエンドのフローなどです。 範囲が広すぎると一般論に終始した仕様になり、狭すぎると完全な要件をまとめられません。

Step 2 — 観察可能な振る舞いを抽出する

コードから事実を収集し、それぞれの根拠の場所（ファイルと行番号）を記録します。

• エントリーポイント：HTTP ルート、CLI 引数、イベントコンシューマー、公開 API。
• 入力と検証：受け付けるフィールド、型、制約、デフォルト値。
• 出力と副作用：レスポンスの構造、書き込み先のストレージ、発行されるイベント、外部呼び出し。
• エラーパス：スローされる例外、返されるエラーコード、再試行とフォールバックのロジック。
• 状態とライフサイクル：永続化モデル、ステートマシン、並行処理に関する前提。

コードで観察できる振る舞いだけを記録します。命名やコメントから設計意図を推測してはいけません。

Step 3 — 要件としてまとめる

散在する振る舞いの事実を、「ユーザー／システムができること」を示す記述にまとめます。

• すべての要件はテスト可能でなければなりません。つまり、入力を与えたときに要件を満たすかどうかを判断できる必要があります。
• 既存の振る舞いにおける意図的な設計と歴史的な経緯による制約を区別します。判断できないものは仮定または確認事項に含め、コードの作者を擁護するような説明を加えてはいけません。
• 発見した欠落（未処理の境界ケースなど）は個別に列挙し、要件として直接記述してはいけません。

Step 4 — Spec Kit の構造に従って spec.md を作成する

specs/<feature>/spec.md に書き込み、章構成は Spec Kit の規約（次節を参照）に従います。 .specify/templates/spec-template.md が存在する場合は、それに従います。

Step 5 — 不確定事項と仮定を明記する

• [NEEDS CLARIFICATION] マーカーは最大 3 つまでとし、範囲、安全性、またはユーザー体験に影響する重要な相違点にのみ使用します。
• その他の不確定な点は Assumptions の章に記載し、採用した妥当なデフォルト値を記録します。

仕様の構造（Spec Kit の規約に準拠）

• 必須セクション：各機能で必ず完成させる必要があります。
• 任意セクション：関連する場合にのみ含めます。
• 適用されない章は章全体を削除し、「N/A」を残してはいけません。

品質要件（Spec Kit に準拠）：

1. 質問するよりも、コンテキストと業界の慣例で不足を補うことを優先します。
2. 採用したデフォルト値を Assumptions の章に記録します。
3. 確認事項は、範囲 > 安全性／プライバシー > ユーザー体験 > 技術的詳細の優先順位で並べます。
4. テスターの視点で確認します。曖昧な要件は、「テスト可能かつ曖昧さがない」という基準を通過できないものでなければなりません。

成功基準（Success Criteria）

成功基準は、次の要件を満たす必要があります。

1. 測定可能 —— 時間、割合、数量、比率など、具体的な指標を含めます。
2. 技術に依存しない —— フレームワーク、言語、データベース、またはツールに言及しません。
3. ユーザー中心 —— システム内部の構造ではなく、ユーザー／ビジネスの視点から結果を記述します。
4. 検証可能 —— 実装の詳細を知らなくても検証できるようにします。

例（良い例）：「ユーザーは 3 分以内にチェックアウトを完了できる」、「検索の 95% が 1 秒以内に結果を返す」。 例（悪い例）：「API の応答時間が 200ms 未満」、「Redis のキャッシュヒット率が 80% を超える」。

出力

• specs/<feature>/spec.md —— 逆抽出して生成したベースライン仕様。
• 実装の欠落が見つかった場合：報告では「既存の実装との差異」として別途記載し、仕様本文には含めません。

ガードレール

• 意図を推測しない：コードが行っていないことを要件として記述しません。
• ベースラインと目標を区別する：このスキルが生成するのは「現行の振る舞いのベースライン」であり、「期待される状態」ではありません。
• 根拠を追跡可能にする：各要件を具体的なコードの場所までたどれるようにします。
• コードを変更しない：これは読み取り専用の分析フローであり、成果物は仕様ドキュメントのみです。