to-spec について
現在の会話とコードベースの理解から、ユーザーへの聞き取りを行わずに機能仕様を作成するスキルです。テスト境界を特定して確認し、定義済みのテンプレートでプロジェクトのトラッカーに公開します。
主な機能
- 01会話とコードベースの背景を統合
- 02テスト境界を特定して確認
- 03定義済みテンプレートで仕様を作成
- 04実装とテストの決定事項を記録
- 05準備完了ラベル付きで仕様を公開
活用シーン
- 01既知の要件を機能仕様にまとめる
- 02機能テストの高レベルな境界を定める
- 03アーキテクチャ・インターフェース・範囲の決定を記録
- 04仕様をプロジェクトの課題トラッカーに公開
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ leandrocfe/ skills --skill to-specインストール後、Claude Code で/to-specを入力して読み込まれたか確認します。
同梱ファイルagents/openai.yaml
詳細
このスキルは、会話の現在のコンテキストとコードベースの理解を取り込み、仕様書を作成します。ユーザーに質問してはいけません。すでに把握している内容だけをまとめてください。
Issue トラッカーとトリアージラベルの語彙は、すでに提供されているはずです。提供されていない場合は、/setup-leandrocfe-skills を実行してください。
プロセス
-
まだ行っていない場合は、リポジトリを調べてコードベースの現在の状態を理解します。仕様書全体を通して、プロジェクトのドメイン用語集の語彙を使い、作業対象領域の ADR を遵守してください。
-
この機能をテストする接点を概説します。新たに設ける接点より既存の接点を優先してください。可能な限り高いレベルの接点を使います。新たな接点が必要な場合は、可能な限り高いレベルに提案してください。コードベース全体に散在する接点は少ないほどよく、理想は 1 つです。
これらの接点がユーザーの期待に合っているか確認してください。
- 以下のテンプレートを使って仕様書を作成し、プロジェクトの Issue トラッカーに公開します。トリアージラベル
ready-for-agentを適用してください。追加のトリアージは不要です。
問題の説明
ユーザーの視点から見た、ユーザーが直面している問題。
解決策
ユーザーの視点から見た、問題の解決策。
ユーザーストーリー
多数のユーザーストーリーを番号付きリストで記載します。各ユーザーストーリーは次の形式にしてください。
- <行為者>として、<メリット>を得るために、<機能>したい
このユーザーストーリーのリストは非常に詳細にし、機能のあらゆる側面を網羅してください。
実装に関する決定事項
実装に関して決定した事項をリストで記載します。以下を含めることができます。
- 構築または変更するモジュール
- 変更するモジュールのインターフェース
- 開発者向けの技術的な補足
- アーキテクチャ上の決定
- スキーマの変更
- API コントラクト
- 具体的な連携方法
具体的なファイルパスやコードは含めないでください。すぐに古くなる可能性があります。
例外:prototype によって、文章よりも明確に決定事項を示すコード片が作成された場合(ステートマシン、reducer、スキーマ、型形式など)は、該当する決定事項に含め、prototype から得られたことを簡潔に注記してください。デモとして機能するものではなく、決定事項を明確に示す部分だけを含めてください。
テストに関する決定事項
テストに関して決定した事項をリストで記載します。以下を含めてください。
- 優れたテストの内容(実装の詳細ではなく、外部から観察できる振る舞いだけをテストする)
- テスト対象となるモジュール
- テストの先行事例(コードベースにすでに存在する類似のテストの種類)
対象外
この仕様書の対象外となる内容を記載します。
補足
機能に関する追加の注記があれば記載します。