mcpField
T
to-spec

to-spec

github.com/eszxcvfd開発135 回インストール11 週間前に更新
リポジトリ

to-spec について

to-specは、既存の会話コンテキストとコードベースの理解から仕様書を作るエージェントスキルです。ユーザーへの聞き取りは行わず、テストの境界を定めてプロジェクトの課題トラッカーに公開します。

主な機能

  1. 01コンテキストを仕様書にまとめる
  2. 02リポジトリの状態とドメイン用語を確認
  3. 03テストの境界を特定
  4. 04構造化された仕様テンプレート
  5. 05ready-for-agentラベル付きで仕様を公開

活用シーン

  1. 01議論で合意した機能を文書化
  2. 02コードベースの調査結果を実装可能な仕様に変換
  3. 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 を実行してください。

プロセス

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

  2. この機能をテストする接点を整理してください。新しい接点より、既存の接点を優先してください。可能な限り高いレベルの接点を使用してください。新しい接点が必要な場合は、可能な限り高いレベルで提案してください。コードベース全体にまたがる接点は少ないほどよく、理想は 1 つです。

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

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

問題の説明

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

解決策

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

ユーザーストーリー

長く、番号付きのユーザーストーリーのリスト。各ユーザーストーリーは次の形式にしてください。

  1. として、を得るために、を使いたい
1. モバイルバンキングの顧客として、支出についてより適切な判断をするために、自分の口座残高を確認したい

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

実装上の決定事項

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

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

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

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

テストに関する決定事項

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

  • 良いテストの条件(実装の詳細ではなく、外部から観測できる動作のみをテストする)
  • テスト対象となるモジュール
  • テストの先例(コードベースにある類似のテストなど)

対象外

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

補足事項

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

コメント