spec-first

仕様先行開発

重要な実装に着手する前に、共有の準備契約を使用してください。要件、決定事項、手順を1つのIssueにまとめ、実行担当者と独立レビュアーが同じ信頼できる情報源を確認できるようにしてください。

契約

入力：

• ユーザーの依頼、リポジトリ、既存のIssue／計画、および承認済みの作業範囲。

出力：

• 実行可能な状態のIssue、または具体的な計画上のブロッカー。
• 実装が承認されている場合は、実装の証跡とデリバリーゲートの状態。

作成／変更するもの：

• 呼び出し元の範囲内で、委任先のエンジンを通じて、依頼された準備資料、実装、デリバリー成果物を作成または変更します。

外部への副作用：

• 承認されたトラッカー／リポジトリ操作のみです。すべてのアクセス権限とホストの制限を引き継ぎます。

確認が必要な場合：

• 既存の実装承認は、同じ範囲内での準備と実行を対象とします。不足している重要な意図、または拡張された権限についてのみ確認してください。準備のみの依頼では、準備が完了した時点で停止します。リポジトリのマージ／デプロイ権限と、必須のレビュー／CIゲートは引き続き適用されます。

委任先：

• 要件と解決済みの実装計画には feature-intake。
• 実行可能性と情報の鮮度に関するブロッカーの検証には prd-quality-gate。
• 指定された実装とデリバリーの証跡には executing-plans。

ワークフロー

1. ライブのIssueと、提示されている場合は現在の計画を読みます。資料が不足している場合や準備が必要な場合は、feature-intake スキルを実行します。このコーディネーターは標準の要件テンプレートと計画テンプレートを使用します。仕様、TODO、決定事項のファイルを別々に作成したり、3つの代替案からユーザーに選ばせたりしないでください。
2. 現在のソースと要件を対象に、execution-readiness モードで prd-quality-gate スキルを実行します。プランナーが不足箇所や古くなった前提を修正します。実行担当者に、不足する挙動やアーキテクチャを決定する権限を与えてはいけません。
3. 実装が承認され、READYである場合は、正確なIssue／現在の計画、作業範囲、ホストの制限、必須のデリバリーゲートを指定して、executing-plans スキルを実行します。ハーネスが選択した実行担当者に従ってください。ここでモデルや作業量を選んではいけません。
4. 実装チェック、受け入れ条件を満たす完全な証跡、ハーネスポリシーで選ばれた別のラボによる独立レビュー、最終PRコミットに必要なCIを必須としてください。計画のレビューや自己レビューを、実装レビューの代わりにしてはいけません。レビュー対応能力が不足している場合は、その状態を明示し、完了をブロックしてください。
5. 未解決の決定事項はプランナーに戻し、コードの不具合には指定された修正手順を適用し、アクセスやチェックが利用できない場合は明示的なブロック状態にします。コード変更後は、実際の最終リビジョンに対して、影響を受けるチェック／レビューを再実施してください。
6. 実際のデリバリー状態を報告します。機能が完了したとみなされるのは、受け入れ条件全体とプロジェクトのデリバリーゲートをすべて満たした場合のみです。子PR／バックエンドPRのマージや、CIの一部が成功しただけでは、未完了の機能やエピックを完了扱いにできません。

作業範囲の適正化

範囲が限定された作業には簡潔な資料を使い、誤字修正や機械的な編集に完全なPRDを作成することは避けてください。決定と検証の境界は同じように維持してください。完全な機能では、必要なAPI、UI、接続処理、マイグレーション、テスト、ドキュメント、運用への引き継ぎをすべてIssueに含めます。作業を分割する場合は、共有の独立成果ルールに従ってください。