mcpField
T
to-spec

to-spec

github.com/tt-a1i開発192132 回インストール2 日前に更新
リポジトリ

to-spec について

to-specは、会話の文脈とコードベースの理解から機能仕様を作成し、課題トラッカーに公開する開発スキルです。テスト境界を確認し、準備できた作業の実装経路を選びます。

主な機能

  1. 01文脈を統合して機能仕様を作成
  2. 02コードを調査しドメイン決定を尊重
  3. 03ユーザーとテスト境界を確認
  4. 04トリアージラベルを付けて仕様を公開
  5. 05実装への引き継ぎ経路を選択

活用シーン

  1. 01進行中の議論から機能仕様を作成
  2. 02実装前にテスト境界を定義
  3. 03準備済みの作業を課題トラッカーに公開
  4. 04追加分割が必要な作業の経路を決定

インストール

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

$npx skills add https://github.com/tt-a1i/matt-skills-with-to-goal --skill to-spec

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

同梱ファイルagents/openai.yaml

詳細

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

課題トラッカーとトリアージラベルの用語集は、すでに提供されているはずです。提供されていない場合は、/setup-matt-pocock-skills を実行するようユーザーに伝えてください。

プロセス

  1. まだ行っていない場合は、リポジトリを調査してコードベースの現在の状態を把握します。仕様書全体でプロジェクトのドメイン用語集の用語を使用し、対象領域の ADR を遵守してください。

  2. この機能をテストする境界を検討します。新しく設ける境界より、既存の境界を優先してください。可能な限り上位の境界を使用します。新しい境界が必要な場合は、可能な限り上位の箇所に提案してください。コードベース全体の境界はできるだけ少なくします。実際に外部境界が必要な場合を除き、仕様書あたり 1 つを基本とします。

これらの境界がユーザーの期待に沿っているか確認してください。

  1. 以下のテンプレートを使って仕様書を作成し、プロジェクトの課題トラッカーに登録します。トリアージラベル ready-for-agent を適用してください。追加のトリアージは不要です。

問題の説明

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

解決策

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

ユーザーストーリー

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

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

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

実装上の決定事項

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

  • 作成・変更するモジュール
  • 変更するモジュールのインターフェース
  • 開発者からの技術的な補足
  • アーキテクチャ上の決定事項
  • スキーマの変更
  • API の契約
  • 具体的なインタラクション

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

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

テスト上の決定事項

決定したテスト上の事項のリスト。以下を含めてください。

  • 優れたテストの説明(実装の詳細ではなく、外部から見える動作のみをテストすること)
  • テスト対象となるモジュール
  • テストの先例(コードベース内の類似したテストの種類)

対象外

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

補足事項

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

  1. 登録後に実行ルートを選びます。
  • 仕様書全体を 1 つの実装コンテキストで扱え、現在の会話に十分な一貫性があって分岐できる場合は、fork → /spec-executor 用として指定します。
  • 複数のトレーサーバレットのスライス、並行作業、エージェント間の引き継ぎ、またはコンテキストの圧縮が必要な場合は、代わりに /to-tickets 用として指定します。大規模な仕様書を、分岐可能な状態であるかのように扱ってはいけません。
  • プロダクト上の決定事項またはテスト境界が未解決の場合は、不足している決定事項とともに SPEC NOT READY を出力します。実装を開始してはいけません。
  1. 準備完了の結果は、分岐したスレッドが草案を取り違えることなく最終的な合意内容を見つけられるよう、最後に以下の簡潔な起動ブロックを付けてください。
SPEC READY

- Status: ready for implementation
- Source: <published spec URL or path>
- Repository: <implementation repository>
- Baseline: <current commit, branch, or explicit source baseline>
- Test seam: <highest agreed behavior seam>
- Non-goals: <explicit exclusions>
- External authority: <commit, push, review, deploy, tracker, data, and real-service permissions; default ungranted>
- Next route: fork + /spec-executor | /to-tickets

起動ブロックは承認済みの仕様書へのインデックスであり、仕様書そのものの代わりではありません。ブロック内で仕様書全体を繰り返してはいけません。

コメント