spec-executor

Spec Executor

分離された実行用会話で、承認済みの作業単位を1つ実装します。承認済みのソースを正式な根拠として扱い、実装の詳細はこの会話内にとどめ、元の会話に貼り戻せる簡潔な実施報告を返します。

実行契約を確認する

1. 継承された会話履歴、またはユーザーが明示した参照先から、承認済みのソースを1つ特定します。後からのユーザーによる修正は、内容が競合する古い要件に優先します。
2. 直接リンクされた決定事項を含め、ソース全体を読みます。2つ目の長大な目標を再構築してはいけません。
3. この実装コンテキスト内で作業範囲を限定でき、未解決のプロダクト上の決定がないことを確認します。そうでない場合は、特定の上流ワークフローを要求せずに作業を止め、分割または明確化を提案します。
4. 以下を抽出し、維持します。
   • リポジトリと開始時のベースライン
   • ユーザーに見える成果と受け入れ基準
   • 合意済みの検証箇所
   • 明示された非目標とワークスペースの境界
   • コミット、プッシュ、レビュー依頼、デプロイ、トラッカーの編集、データ変更、その他の外部への作用に関する許可

決着済みのプロダクト上の論点を再検討してはいけません。承認済みのソース内に矛盾がある場合、リポジトリと実質的に競合する場合、必要な外部契約が不足している場合、または新たな権限が必要な場合に限り、一時停止します。

編集前にスコープを固定する

リポジトリの指示、ブランチ、HEAD、ワークツリーの状態、関連する最近の履歴、合意済みの検証箇所における現在の実装を確認します。レビューの固定点として、実装前の実際の HEAD を記録します。

実質的な編集を始める前に、次の形式で短い実行ロックを送ります。

Executing: <one-sentence outcome>
Source: <approved conversation, issue, file, or spec>
In scope: <compact list>
Out of scope: <compact list>
Validation: <primary seam and required gates>
External authority: <what is and is not authorized>

必要に応じて、適切なローカルブランチを作成するか、そこへ切り替えます。無関係な未コミット変更や未追跡の作業を破棄、上書き、または取り込んではいけません。指定されたベースラインからずれている場合は、仕様が引き続き適用可能かを判断し、現在の固定点を記録します。ずれによってプロダクトの動作や受け入れ基準が変わる場合は、作業を止めます。

仕様を実装する

1. 各受け入れ基準について、既存の動作、基準を満たす最小のコード箇所、観測可能な証拠をたどります。
2. リポジトリ、リスク、合意済みの検証箇所に適した実装およびテスト方法を選びます。実装詳細に関するアサーションよりも、動作の証拠を優先します。
3. 最小範囲で完結する垂直スライスを実装します。後続チケット、機会に乗じたリファクタリング、新たなプロダクト動作を持ち込んではいけません。
4. 開発中に関連する最小限のチェックを実行し、その後、リスクに応じてリポジトリで必須の広範なゲートを実行します。
5. 完了した差分をすべての受け入れ基準と照合し、記録したベースラインを基準にレビューします。役立つ場合は利用可能な専門レビューのスキルやツールを使いますが、必須ではありません。スコープ内の重大な指摘を修正し、残りは解決するか、明示的に報告します。
6. 最終的なワークツリーを確認し、この実行による変更と、以前から存在する変更を区別します。

このスキルの実行は、スコープ内のローカル実装と検証を許可します。ただし、それ自体でコミット、プッシュ、レビューの開始やマージ、トラッカーの状態変更、デプロイ、本番データの書き込み、高額な実サービスの呼び出し、関係者への連絡を許可するものではありません。承認済みのソースまたは後続のユーザーメッセージで明示的に許可されている場合に限り、これらの操作を行います。ある操作への許可を、別の操作へ拡大解釈してはいけません。

ブロッカーとコンテキスト超過への対処

ブロックされた場合は、まず安全な読み取り専用の調査とローカル検証を可能な限り行います。その後、証拠と、計画スレッドで必要となる最小限の判断または権限を示して停止します。

作業が1つの実装コンテキストで確実に完了できる範囲を超えると判明した場合は、履歴を黙って省略して続行してはいけません。部分的な実施報告を返し、ワークツリーを保持したうえで、残りの作業を分割するか、持ち運び可能な目標にまとめることを提案します。

レシートを返す

依頼がない限り、引き継ぎファイルは作成しないでください。最後に、コピーしてそのまま使えるブロックを1つ出力してください。

SPEC EXECUTION RECEIPT

- Conclusion: completed / partially completed / blocked
- Spec source:
- Review fixed point:
- Acceptance criteria: <each criterion with pass/fail and evidence>
- Main changes:
- Changed files:
- Branch / commit / review:
- Validation results:
- Review findings:
- Not validated or not executed:
- Risks and remaining work:
- Planning-thread decision needed:
- Final worktree state:
- External effects: <push, deploy, tracker, data, real services, messages>
- Goal / spec quality: <optional: accurate / criteria-too-vague / criteria-wrong / missing-constraint / over-scoped — plus one sentence>

レシートは簡潔にしつつ、完了を裏付ける証拠を含めてください。完了を実質的に証明する場合は、正確なコマンド、件数、識別子、リンクを記載してください。確認していない実環境、デプロイ、外部への操作について、実施したと主張してはいけません。 レシートが実行スレッドから出る前に、認証情報、トークン、Cookie、個人データ、機密性の高い環境識別子を削除してください。

Goal / spec quality は任意であり、完了条件ではありません。実行エージェントは空欄のままにできます。計画スレッドまたはユーザーが、レシートを実際の差分と照合した後に記入します。