to-spec について
to-spec は、会話の文脈とコードベースの理解から機能仕様をまとめるスキルです。ユーザーストーリー、実装・テストの決定事項を定型で記述し、ready-for-agent ラベルを付けて issue tracker に公開します。
主な機能
- 01文脈とコードベースから仕様を作成
- 02ドメイン用語と ADR を反映
- 03テスト境界を提案して確認
- 04定型テンプレートで内容を構成
- 05ラベルを付けて issue tracker に公開
活用シーン
- 01既存の議論を開発仕様に整理
- 02機能のテスト境界を定義
- 03実装決定と対象外事項を記録
- 04仕様をプロジェクトのトラッカーに登録
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ nstaab1/ nathan-agent-skills --skill to-specインストール後、Claude Code で/to-specを入力して読み込まれたか確認します。
同梱ファイルagents/openai.yaml
詳細
このスキルは、現在の会話のコンテキストとコードベースの理解に基づいて仕様書を作成します。ユーザーに質問してはいけません。すでに把握している内容をまとめてください。
イシュートラッカーとトリアージラベルの語彙が提供されているはずです。提供されていない場合は、/setup-agent-skills を実行するようユーザーに伝えてください。
プロセス
-
まだ確認していない場合は、リポジトリを調べてコードベースの現状を把握します。仕様書ではプロジェクトのドメイン用語集を全体を通じて使用し、変更対象の領域に関する ADR を遵守します。
-
この機能をテストする境界を検討します。新たに設ける境界より、既存の境界を優先します。可能な限り高いレベルの境界を使用します。新たな境界が必要な場合は、可能な限り高いレベルに提案します。コードベース全体にまたがる境界はできるだけ少なくします。理想的な数は 1 つです。
これらの境界がユーザーの期待に合っているか確認します。
- 以下のテンプレートを使って仕様書を作成し、プロジェクトのイシュートラッカーに公開します。トリアージラベル
ready-for-agentを適用します。追加のトリアージは不要です。
問題の説明
ユーザーの視点から見た、ユーザーが直面している問題。
解決策
ユーザーの視点から見た、問題の解決策。
ユーザーストーリー
長く、番号付きのユーザーストーリーのリスト。各ユーザーストーリーは次の形式にします。
- <アクター>として、<機能>を実現したい。それによって、<メリット>が得られる。
このユーザーストーリーのリストは非常に詳細にし、機能のあらゆる側面を網羅してください。
実装上の決定事項
決定した実装上の決定事項のリスト。次の内容を含めることができます。
- 作成・変更するモジュール
- 変更するモジュールのインターフェース
- 開発者による技術的な明確化
- アーキテクチャ上の決定
- スキーマの変更
- API コントラクト
- 具体的なインタラクション
具体的なファイルパスやコードスニペットは含めないでください。すぐに古くなる可能性があります。
例外:プロトタイプで作成したスニペットが、文章よりも正確に決定事項(状態機械、リデューサー、スキーマ、型の形状など)を表している場合は、該当する決定事項にその内容を含め、プロトタイプに由来することを簡潔に記してください。動作するデモではなく、決定事項を明確に表す要点に絞ってください。
テスト上の決定事項
決定したテスト上の決定事項のリスト。以下を含めます。
- 優れたテストの条件(実装の詳細ではなく、外部から観測できる動作のみをテストする)
- テスト対象のモジュール
- テストの先行事例(コードベース内の類似したテストなど)
対象外
この仕様書の対象外となる項目の説明。
補足
この機能に関するその他の補足。