to-spec

このスキルは、現在の会話のコンテキストとコードベースの理解をもとに仕様書を作成します。ユーザーに質問してはいけません。すでに把握している内容をまとめてください。会話でまだ共通認識ができていない場合は、仕様書を作成するのではなく、grill-me セッションを行ってください。

トラッカー。 リポジトリのエンジニア向けスキルと同じ場所にある TRACKER.md を読みます。そこには、トラッカーの名前、コマンド、このリポジトリで使うラベル文字列とその意味が記載されています。ファイルがない場合は、ユーザーから提供された情報、git リモート、インストール済みかつ認証済みの CLI をもとに、今回使用するトラッカーを特定します。どれも特定できない場合は、ローカルの Markdown ファイルで構成されるディレクトリを既定で使用します。

エンジニア向けスキルのディレクトリはハーネスによって異なるため、glob で探してください。

ls */skills/*-engineer/TRACKER.md .*/skills/*-engineer/TRACKER.md 2>/dev/null

プロセス

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

2. 機能をテストする境界を概略化します。新しい境界より既存の境界を優先してください。できるだけ高いレベルの境界を選びます。新しい境界が必要な場合は、可能な限り高いレベルで提案してください。コードベース全体にまたがる境界は少ないほどよく、理想は1つです。

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

3. 以下のテンプレートを使って仕様書を作成し、トラッカーに登録します。エージェントが対応可能な作業には、TRACKER.md に記載されたラベルを付けてください。ラベルが指定されていない場合は、付与せず、その旨を伝えてください。

問題の説明

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

解決策

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

ユーザーストーリー

ユーザーストーリーを番号付きで、長いリストとして記載します。各ユーザーストーリーは、次の形式にしてください。

1. <アクター>として、<メリット>を得るために、<機能>を使いたい

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

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

実装上の決定事項

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

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

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

例外：プロトタイプで作成したスニペットが、文章よりも正確に決定事項を表現している場合は、該当する決定事項の中にインラインで記載し、プロトタイプに由来することを簡潔に説明してください。実用的なデモではなく、決定事項を明確に示す部分だけを抜き出してください。

テスト上の決定事項

テスト上の決定事項を列挙します。以下を含めてください。

• 適切なテストの条件（実装の詳細ではなく、外部から見た動作のみをテストする）
• テスト対象のモジュール
• テストの先例（コードベース内にある、類似したテスト）

対象外

この仕様書の対象外となる内容を記載します。

補足

機能に関するその他の補足を記載します。

---

このファイルをコピーする場合は、この行を残してください。mattpocock/skills をもとに作成。MIT © 2026 Matt Pocock。