to-spec について
to-specは、既存の会話コンテキストとコードベースの理解から仕様書を作るエージェントスキルです。ユーザーへの聞き取りは行わず、テストの境界を定めてプロジェクトの課題トラッカーに公開します。
主な機能
- 01コンテキストを仕様書にまとめる
- 02リポジトリの状態とドメイン用語を確認
- 03テストの境界を特定
- 04構造化された仕様テンプレート
- 05ready-for-agentラベル付きで仕様を公開
活用シーン
- 01議論で合意した機能を文書化
- 02コードベースの調査結果を実装可能な仕様に変換
- 03実装とテストの決定事項を記録
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ eszxcvfd/ skills --skill to-specインストール後、Claude Code で/to-specを入力して読み込まれたか確認します。
同梱ファイルagents/openai.yaml
詳細
リポジトリに関する作業を始める前に、../../WORK-ROUTING.md を読んでください。これは、プロジェクトドキュメント、作業レーンの選択、計画の担当範囲、作業完了時の手順に関する共通のルーティング情報源です。
このスキルでは、現在の会話のコンテキストとコードベースの理解をもとに、仕様書を作成します。ユーザーに質問してはいけません。すでに把握している情報を統合してください。
課題トラッカーとトリアージラベルの用語一覧は、すでに提供されているはずです。提供されていない場合は、/setup-matt-pocock-skills を実行してください。
プロセス
-
まだ確認していない場合は、リポジトリを調査してコードベースの現状を把握してください。仕様書全体でプロジェクトのドメイン用語集の語彙を使用し、変更する領域に関係する ADR を尊重してください。
-
この機能をテストする接点を整理してください。新しい接点より、既存の接点を優先してください。可能な限り高いレベルの接点を使用してください。新しい接点が必要な場合は、可能な限り高いレベルで提案してください。コードベース全体にまたがる接点は少ないほどよく、理想は 1 つです。
これらの接点がユーザーの期待に沿っているか確認してください。
- 以下のテンプレートを使用して仕様書を作成し、プロジェクトの課題トラッカーに公開してください。トリアージラベル
ready-for-agentを適用してください。追加のトリアージは不要です。
問題の説明
ユーザーの視点から見た、ユーザーが直面している問題。
解決策
ユーザーの視点から見た、問題の解決策。
ユーザーストーリー
長く、番号付きのユーザーストーリーのリスト。各ユーザーストーリーは次の形式にしてください。
- として、を得るために、を使いたい
このユーザーストーリーのリストは、機能のあらゆる側面を網羅する、非常に充実したものにしてください。
実装上の決定事項
決定した実装上の事項のリスト。以下を含めることができます。
- 構築または変更するモジュール
- 変更するモジュールのインターフェース
- 開発者による技術的な明確化
- アーキテクチャ上の決定
- スキーマの変更
- API コントラクト
- 具体的なインタラクション
具体的なファイルパスやコードスニペットは含めないでください。すぐに古くなる可能性があります。
例外:プロトタイプで作成されたスニペットが、文章よりも明確に決定事項を表現している場合(ステートマシン、リデューサー、スキーマ、型の形状など)は、関連する決定事項に含め、プロトタイプに由来することを簡潔に記してください。動作するデモ全体ではなく、決定事項を明確にする部分だけに絞ってください。
テストに関する決定事項
決定したテスト上の事項のリスト。以下を含めてください。
- 良いテストの条件(実装の詳細ではなく、外部から観測できる動作のみをテストする)
- テスト対象となるモジュール
- テストの先例(コードベースにある類似のテストなど)
対象外
この仕様書の対象外となる事項の説明。
補足事項
この機能に関するその他の補足事項。