to-spec について
現在の会話とコードベースの情報から、ユーザーへの聞き取りをせずにプロジェクト仕様をまとめるスキルです。リポジトリの確認、テスト箇所の選定、指定ラベルを付けた課題トラッカーへの公開を案内します。
主な機能
- 01リポジトリとドメイン用語の確認
- 02テスト箇所の選定と確認
- 03構成化された機能仕様の作成
- 04課題トラッカーへの仕様公開
- 05ready-for-agent ラベルの付与
活用シーン
- 01機能の議論を仕様にまとめる
- 02テストと実装の判断を記録
- 03エージェント作業用の仕様を準備
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/to-specを入力して読み込まれたか確認します。
同梱ファイルagents/openai.yaml
詳細
このスキルは、現在の会話コンテキストとコードベースの理解を基に仕様書を作成します。ユーザーへのヒアリングは行わず、すでに把握している内容をまとめるだけにしてください。
イシュートラッカーとトリアージラベルの語彙は提供されているはずです。もし提供されていない場合は、ユーザーに /setup-matt-pocock-skills を実行するよう伝えてください。
プロセス
-
まだ行っていない場合は、リポジトリを調査してコードベースの現状を把握してください。仕様書全体を通じてプロジェクトのドメイン用語集の語彙を使用し、変更を加える領域の ADR を尊重してください。
-
これから機能をテストする際のシームを設計してください。新しいシームよりも既存のシームを優先してください。可能な限り最も上位のシームを使用してください。新しいシームが必要な場合は、可能な限り上位のポイントで提案してください。コードベース全体でのシームは少ないほどよく、理想的な数は 1 つです。
これらのシームがユーザーの期待と一致しているかを確認してください。
- 以下のテンプレートを使用して仕様書を作成し、プロジェクトのイシュートラッカーに公開してください。
ready-for-agentトリアージラベルを適用してください — 追加のトリアージは不要です。
問題の説明
ユーザーが直面している問題を、ユーザーの視点から記述します。
解決策
問題に対する解決策を、ユーザーの視点から記述します。
ユーザーストーリー
長く、番号付きのユーザーストーリーのリストです。各ユーザーストーリーは以下の形式にしてください。
- として、 が欲しい。そうすれば
このユーザーストーリーのリストは極めて網羅的であり、機能のあらゆる側面をカバーする必要があります。
実装の決定事項
行われた実装の決定事項のリストです。以下を含めることができます。
- 構築/変更されるモジュール
- 変更されるこれらのモジュールのインターフェース
- 開発者からの技術的な明確化
- アーキテクチャ上の決定
- スキーマの変更
- API コントラクト
- 具体的なインタラクション
具体的なファイルパスやコードスニペットは含めないでください。すぐに古くなる可能性があります。
例外: プロトタイプが、散文よりも正確に決定を表現するスニペット（状態機械、リデューサー、スキーマ、型の形状）を生成した場合は、関連する決定事項内にインラインで記載し、プロトタイプから得られたものであることを簡潔に注記してください。動作するデモではなく、決定事項を多く含む部分に絞り、重要な部分だけにしてください。
テストの決定事項
行われたテストの決定事項のリストです。以下を含めてください。
- 良いテストを構成するものの説明（外部の振る舞いのみをテストし、実装の詳細はテストしない）
- どのモジュールがテストされるか
- テストの先行事例（つまり、コードベース内の類似するタイプのテスト）
スコープ外
この仕様書のスコープ外となる事項の説明です。
補足
機能に関する追加の補足事項です。