acceptance-check

受け入れ確認

ユニットテストがすべて成功しても、それが証明するのは、作成者が書いたアサーションを満たしたということだけです。機能が動作することまでは証明しません。この2つの間にはギャップがあります。たとえば、クライアントが 200 を読み取るのに API が 201 を返す、チェックボックスはメモリ上で切り替わるもののストアに反映されない、送信に失敗するとフォームがクリアされる、といったケースです。このギャップが機能の不具合を生みます。このスキルで、テストスイートではなく、実行中のシステムを操作して確認します。

code-review の後、finish-branch の前に実行してください。

1. 仕様から受け入れチェックリストを作成する

機能の requirements.md、design.md、tasks.md を読みます。ユーザーから見える動作を記述した要件ごとに、具体的なチェック項目を列挙します。正常系と、各境界条件・エラー条件の両方を含め、要件 ID と対応づけてください。仕様が基準です。誰も手取り足取り教えてくれなかった動作にも対応する必要があります。追跡されていない項目は省略せず、ギャップとして報告してください。

チェックリストを .skills/<slug>-acceptance.md（作業用の台帳。Git では無視されます）に書き、項目ごとに TODO を1つ作成します。読む量が多い場合は、スキャン用サブエージェントに変更箇所を洗い出して台帳にまとめてもらい、このコンテキストを軽く保ちます。完了条件：ユーザー向けの要件 ID ごとに、期待結果を伴う具体的かつ観察可能なチェックが少なくとも1つあること。

2. 対象ごとに振り分ける

チェックリストは、各動作がどこにあるかに応じて分かれます。該当するものを実行してください。多くの機能では両方が必要です。

• 変更によって、クライアントが呼び出す HTTP/RPC API が公開される場合 → 必須サブスキル：acceptance-api を使用する。
• 変更に、ユーザーが操作するフロントエンドが含まれる場合 → 必須サブスキル：acceptance-ui を使用する。
• 動作が API でも UI でもない場合（CLI、ライブラリ、バッチ／cron ジョブなど） → 実行中のシステムを自分で直接操作し、観察した結果をそれぞれ台帳に記録します。合格したチェックは、コミット対象の ID 付きテストにします。見た目や使い心地など、人の目で確認する品質は dogfood に引き継ぎます。

各子エージェントには、台帳の担当箇所をパスで指定してください。結果は同じファイルに書き戻します。

3. 検証を完了する

各項目で観察した結果とともにチェックリストを報告します。実行できなかった項目は、未解決のリスクです。内容を明記し、黙って合格にしないでください。その後、finish-branch に引き継ぎます。完了条件：実行中のシステムに対してすべてのチェック項目が合格と確認され、各失敗に回帰テストが追加され、永続的なテストがコミットされて ID でタグ付けされていること。これにより、finish-branch の検証ゲートで継続的に確認されます。