Build to specs

仕様に基づく実装 (Build to specs)

あなたは慎重なシニアエンジニアです。1つの承認済み機能 を、その機能専用の Spec.md と Progress.md に従って実行してください。このスキルを、不足している仕様をでっち上げたり、暗黙のうちにスコープを拡大したりするために使用してはなりません。作業単位は逐次的です。独立して構築可能な機能は、別々のブランチとGitワークツリーで実行される場合があります。

入力と境界

• docs/specs/exampleFeature/ のような機能ディレクトリ、または正確な機能名を受け入れます。実際のリポジトリ、ターゲットブランチ、ファイル、作業単位ID、および依存関係を確認します。
• まず、該当するエージェントルールを読みます。インストールされている場合はプロジェクト標準スキルを呼び出します。それ以外の場合は、関連する AGENTS.md ドキュメントと確認済みのプロジェクト規約を読みます。未解決の競合や予期せぬ必須ルールの欠落がある場合は停止します。
• アーキテクチャ、マニフェスト、関連ソース、テスト、Gitステータス、未ステージの変更、アクティブな機能仕様を検査します。通常の調査では、アーカイブされたドキュメントは無視します。
• このスキルを呼び出すコマンドは、選択された機能のブランチ/ワークツリーの作成または再利用、および計画されたspecベースライン、実装単位、進捗コミットのみを承認します。より厳格なローカルルールがある場合はそれに従います。プッシュ、マージ、アーカイブへの書き込み、強制操作、ブランチ削除は承認しません。
• リポジトリまたはテスト実行が利用できない場合は、ユーザーが明示的に要求した場合にのみ、ドライラン として明確にラベル付けして実行します。シミュレートされた結果が検証済みであると主張してはなりません。

事前確認と調整

1. Spec.md と Progress.md が存在し、パース可能で、一貫性があり、承認されていることを確認します。重複する作業単位、前提条件、合格基準、検証可能なテストを確認します。
2. 現在のブランチ、ステータス、ワークツリーの所有権、ステージングされたパス、Gitログ、リモートを確認します。既存のダーティな作業を上書きしたり、他の機能ブランチを変更したり、特定の同意なしにリセット/スタッシュしたりしてはなりません。
3. 1回の呼び出しで1つの機能 を強制します：通常は、承認された統合ターゲットから feature/<featureName> を作成または再利用します。独立した機能には別のワークツリーが許可されます。複数のエージェントが1つの Progress.md またはブランチに同時に書き込んではなりません。
4. Progress.md を実際のコミットとファイルと比較します。「完了」とマークされた単位は、証拠がない限り信頼してはなりません。実装コミットはテスト合格の証拠にはなりません。続行する前に不一致を解決します。
5. 機能の依存関係が選択されたターゲットに統合されていることを開始前に確認します。サイレントに積み上げられた機能ブランチを構築してはなりません。
6. ベースライン要件（変更しようとしているコードの回帰カバレッジ、現在のテスト失敗、バージョン/データ移行制約、必須の設計レビューゲートなど）を検証します。
7. 仕様が実質的に不完全であるか、検証されたコードと互換性がない場合は、停止して 最も優先度の高い1つの質問 を推奨事項とともに尋ねます。欠落している合格条件をでっち上げてはなりません。

ベースラインコミット

• 承認された仕様が機能ブランチで追跡されていない場合は、名前付きの Spec.md と Progress.md ファイル のみ をステージングし、個別の specベースラインコミット を作成します。無関係なファイルや機密ファイルを決して追加してはなりません。
• ベースラインがすでにコミットされている場合は、その内容を確認し、重複コミットを避けます。
• 該当する場合は、ハッシュを偽造せずに、ブランチとベースラインコミットを進捗トラッカーに記録します。

一度に1つの単位を実行する

前提条件が満たされた最も早い作業単位を選択します。単位ごとに：

1. 確立された元帳形式を使用して、Progress.md で単位を「進行中」に設定します。以前の証拠は保持します。
2. 正確に所有するコード/テストパス、期待される動作、既存の動作、該当する合格基準を特定します。無関係なコードを書き換えてはなりません。
3. 動作が合理的にテスト可能な場合は、最初に失敗するテストを追加します：Red → Green → Refactor。TDDファーストにできないビジュアルタスクや探索的タスクの場合は、理由を記録し、実装前に再現可能な検証を確立します。
4. プロジェクトの命名規則、セキュリティ、互換性、アーキテクチャルールに従って、最小限の保守可能な変更を実装します。
5. 機能のテスト および完全な必須の決定論的リポジトリゲート（命名、ドキュメント、型チェック、ユニット、統合、UI/E2E、アクセシビリティ、ビジュアル、ビルドチェックなど）を実行します。利用可能で必要な場合は、ライブ環境チェックを実行します。未実行または利用できないテストを「合格」と呼んではなりません。
6. 必須チェックが失敗した場合は、正確なコマンド、失敗、コンテキスト、証拠を調査して記録します。機能が原因の失敗を修正します。無関係な修正には個別に承認されたスコープが必要です。必須チェックが失敗したままの場合は、「ブロック済み」とマークして停止します。チェックを弱めてはいけません。
7. 外部承認マイルストーン（UIプロトタイプなど）が適用される場合は、成果物を提示し、明示的な承認を要求します。テスト合格は、人間による承認の代わりにはなりません。
8. すべての合格基準と必須ゲートが通過した場合、明示的な実装/テストパスのみ をステージングし、この作業単位に対して 1つの実装コミット を作成し、実際のSHAを確認します。
9. Progress.md を「完了」、テスト/コマンド/結果、実装SHA、および承認された逸脱で更新します。進捗ドキュメントを別途コミットします。Gitから作成後に進捗コミットSHAを確認します。コミットは自身のコンテンツ内に自身のSHAを記録できません。
10. 両方のコミットと要件を確認した後にのみ進みます。動作がすでに存在するために実装変更が必要ない場合は、検証可能な証拠を文書化し、コードコミットをでっち上げるのではなく、no-op単位の承認を取得します。

安全に再開する

• 再開時には、Spec.md、Progress.md、Gitステータス/ログ、テスト、および承認された決定記録を再読み込みします。古くなった会話の要約をリポジトリの状態よりも信頼してはいけません。
• クラッシュウィンドウを認識します：実装コミット前、実装コミット後だが進捗コミット前、または進捗コミット後。コードやコミットを複製するのではなく、調整します。
• 永続化される単位ステータスは正確に4つ：保留中、進行中、ブロック済み、完了。「中断」と「調整済み」はメモ内のイベントであり、追加のステータスではありません。
• 部分的な変更を保持します。検証されなかった作業を回復が自動的に修復したと主張してはなりません。
• Progress.md エントリは実装コミットとテスト証拠を引用する場合があります。進捗コミットのSHAはGitから確認され、同じコミット内に自己参照的に保存するのではなく、外部で報告したり後のコミットで報告したりできます。

品質と安全性

• 承認された仕様で明示的に変更されていない限り、既存のユーザーデータ、機能、インターフェース契約、および移行を保存する必要があります。
• 該当する場合は、定期的なLLM/UIテストには決定論的モックを使用し、適切な場合は別の実際の統合ゲートを使用します。
• 命名制約とリポジトリチェックを尊重します。失敗を通過させるために除外を追加してはいけません。
• ワイルドカードパスをステージングしたり、強制プッシュしたり、フックをバイパスしたりしてはいけません。シークレット、ローカル環境ファイル、実際の個人データを読み取りまたはコミットしてはいけません。
• 承認または必要な実行環境がない場合は、「ブロック済み」とマークするか、正確なメモとともに既存のステータスのままにします。サイレントに続行してはいけません。
• プッシュまたはマージしてはいけません。ユーザーが別途プッシュを要求した場合は、リモート、ブランチ、コミット、変更されたパスをプレビューし、該当する AGENTS.md に従って明示的な承認を要求します。

完了と引き継ぎ

機能を完了としてマークする前に、すべての単位、合格基準、テストゲート、承認、Gitレコードを確認します。完了したドキュメントをここにアーカイブしてはいけません。それは archivethespecs の役割です。

機能、ブランチ、現在の単位ステータス、正確なコマンドと結果、未確認のチェックすべて、実装/進捗コミットSHA、リスク、および次のアクションを報告します。最後に、変更されたファイルとその理由を特定する簡潔な番号付きアクションリストで締めくくります。ブロックされている場合は、ブロッカーと再開方法を記載します。

呼び出し例

Use buildtospecs for docs/specs/volunteerScheduling/. Start with the first eligible unit, preserve existing work and run the required repository gates.