mcpField
T
to-spec

to-spec

github.com/nstaab1開発049 回インストール3 週間前に更新
リポジトリ

to-spec について

to-spec は、会話の文脈とコードベースの理解から機能仕様をまとめるスキルです。ユーザーストーリー、実装・テストの決定事項を定型で記述し、ready-for-agent ラベルを付けて issue tracker に公開します。

主な機能

  1. 01文脈とコードベースから仕様を作成
  2. 02ドメイン用語と ADR を反映
  3. 03テスト境界を提案して確認
  4. 04定型テンプレートで内容を構成
  5. 05ラベルを付けて issue tracker に公開

活用シーン

  1. 01既存の議論を開発仕様に整理
  2. 02機能のテスト境界を定義
  3. 03実装決定と対象外事項を記録
  4. 04仕様をプロジェクトのトラッカーに登録

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/nstaab1/nathan-agent-skills --skill to-spec

インストール後、Claude Code で/to-specを入力して読み込まれたか確認します。

同梱ファイルagents/openai.yaml

詳細

このスキルは、現在の会話のコンテキストとコードベースの理解に基づいて仕様書を作成します。ユーザーに質問してはいけません。すでに把握している内容をまとめてください。

イシュートラッカーとトリアージラベルの語彙が提供されているはずです。提供されていない場合は、/setup-agent-skills を実行するようユーザーに伝えてください。

プロセス

  1. まだ確認していない場合は、リポジトリを調べてコードベースの現状を把握します。仕様書ではプロジェクトのドメイン用語集を全体を通じて使用し、変更対象の領域に関する ADR を遵守します。

  2. この機能をテストする境界を検討します。新たに設ける境界より、既存の境界を優先します。可能な限り高いレベルの境界を使用します。新たな境界が必要な場合は、可能な限り高いレベルに提案します。コードベース全体にまたがる境界はできるだけ少なくします。理想的な数は 1 つです。

これらの境界がユーザーの期待に合っているか確認します。

  1. 以下のテンプレートを使って仕様書を作成し、プロジェクトのイシュートラッカーに公開します。トリアージラベル ready-for-agent を適用します。追加のトリアージは不要です。

問題の説明

ユーザーの視点から見た、ユーザーが直面している問題。

解決策

ユーザーの視点から見た、問題の解決策。

ユーザーストーリー

長く、番号付きのユーザーストーリーのリスト。各ユーザーストーリーは次の形式にします。

  1. <アクター>として、<機能>を実現したい。それによって、<メリット>が得られる。
1. モバイルバンキングの顧客として、支出についてより適切な判断を下せるよう、自分の口座残高を確認したい。

このユーザーストーリーのリストは非常に詳細にし、機能のあらゆる側面を網羅してください。

実装上の決定事項

決定した実装上の決定事項のリスト。次の内容を含めることができます。

  • 作成・変更するモジュール
  • 変更するモジュールのインターフェース
  • 開発者による技術的な明確化
  • アーキテクチャ上の決定
  • スキーマの変更
  • API コントラクト
  • 具体的なインタラクション

具体的なファイルパスやコードスニペットは含めないでください。すぐに古くなる可能性があります。

例外:プロトタイプで作成したスニペットが、文章よりも正確に決定事項(状態機械、リデューサー、スキーマ、型の形状など)を表している場合は、該当する決定事項にその内容を含め、プロトタイプに由来することを簡潔に記してください。動作するデモではなく、決定事項を明確に表す要点に絞ってください。

テスト上の決定事項

決定したテスト上の決定事項のリスト。以下を含めます。

  • 優れたテストの条件(実装の詳細ではなく、外部から観測できる動作のみをテストする)
  • テスト対象のモジュール
  • テストの先行事例(コードベース内の類似したテストなど)

対象外

この仕様書の対象外となる項目の説明。

補足

この機能に関するその他の補足。

コメント