to-spec について
会話の文脈とコードベースの理解から機能仕様を作成し、プロジェクトの課題トラッカーに公開するスキルです。ユーザーへの聞き取りは行わず、テスト箇所やドメイン用語を重視します。
主な機能
- 01文脈を統合して仕様を作成
- 02コードベースとドメイン用語を確認
- 03確認用のテスト箇所を提案
- 04トリアージラベルを付けて仕様を公開
活用シーン
- 01進行中の会話から機能仕様を起草
- 02課題トラッカーへの仕様公開を準備
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/to-specを入力して読み込まれたか確認します。
同梱ファイルagents/openai.yaml
詳細
このスキルは、現在の会話のコンテキストとコードベースについての理解をもとに、仕様書を作成します。ユーザーに聞き取りをしてはいけません。すでに把握している情報だけをまとめてください。
課題トラッカーとトリアージラベルの語彙は、すでに提供されているはずです。提供されていない場合は、/setup-matt-pocock-skills を実行するようユーザーに伝えてください。
プロセス
-
まだ確認していない場合は、リポジトリを調査してコードベースの現在の状態を把握します。仕様書全体でプロジェクトのドメイン用語集を使い、変更対象の領域に関する ADR を遵守してください。
-
この機能をテストする箇所となる境界を概略化します。新しい境界を設けるより、既存の境界を優先してください。可能な限り高いレベルの境界を使います。新しい境界が必要な場合は、可能な限り高いレベルで提案してください。コードベース全体で境界を設ける箇所は少ないほどよく、理想は 1 つです。
これらの境界がユーザーの期待に合っているか確認してください。
- 以下のテンプレートを使って仕様書を作成し、プロジェクトの課題トラッカーに公開します。
ready-for-agentトリアージラベルを付けてください。追加のトリアージは不要です。
問題の概要
ユーザーの視点から見た問題。
解決策
ユーザーの視点から見た問題の解決策。
ユーザーストーリー
長く、番号付きのユーザーストーリーのリスト。各ユーザーストーリーは次の形式にします。
- <アクター>として、<メリット>を得るために、<機能>がほしい
このユーザーストーリーのリストは、機能のあらゆる側面を網羅する、非常に詳細なものにしてください。
実装上の決定事項
決定した実装上の事項を列挙します。以下を含めることができます。
- 作成または変更するモジュール
- 変更するモジュールのインターフェース
- 開発者による技術的な補足
- アーキテクチャ上の決定
- スキーマの変更
- API コントラクト
- 具体的なインタラクション
具体的なファイルパスやコードスニペットは含めないでください。すぐに古くなる可能性があるためです。
例外：プロトタイプで作成したスニペットが、文章よりも正確に決定事項を表している場合（状態機械、リデューサー、スキーマ、型の形状など）は、該当する決定事項の中にインラインで記載し、プロトタイプに由来することを簡潔に明記してください。動作するデモ全体ではなく、決定事項を明確に示す部分だけに絞ってください。
テスト上の決定事項
決定したテスト上の事項を列挙します。以下を含めてください。
- 優れたテストの条件（実装の詳細ではなく、外部から見た動作だけをテストすること）
- テスト対象のモジュール
- テストの先例（コードベース内にある類似のテストなど）
対象外
この仕様の対象外となる事項を説明します。
補足
この機能に関する補足事項があれば記載します。
4. 公開言語
仕様書の本文は英語で記述します。個人リポジトリの場合（gh api user --jq .login の結果とリモートの所有者が一致する場合。確認できないときは外部リポジトリとして扱います）、仕様書の課題にコメントを 1 件だけ別途投稿します。コメントは主要な内容とし、要点をまとめた ## Chinese Summary (non-authoritative) セクションを含めます。要約は仕様書の課題だけに記載し、サブ課題やフォローアップには決して追加しないでください。