validate-feature

機能を検証する

ユニットテストが成功しても、書かれたアサーションが通ることを証明するだけです。機能が動作することまでは証明しません。その2つの間にある隔たり――クライアントが200を読むところでAPIが201を返す、チェックボックスの状態はメモリ上で切り替わるのにストアには反映されない、送信に失敗するとフォームがクリアされる――そこから、壊れた機能がリリースされます。このスキルでその隔たりを埋めます。テストスイートではなく、実行中のシステムを操作してください。

inspect-changeの後、land-branchの前に実行してください。

コールドスタートの制御。 docs/agents/verify.mdが存在する場合は、チェックリストの項目に取りかかる前に、そのファイルの手順に従ってLaunchとDoctorを実行してください（後続のエージェントがこのアプリを起動する方法を定めているのはこのファイルです）。該当するFeatureセクションがあれば、それに従って各項目を操作してください。Evidenceには、そのファイルに記載された永続化／再読み込みの確認を含めてください。存在しない場合は、これまでどおりproject.mdのRun locally (dev)から続行し、ユーザーがレシピを生成できるように/configure-repoの名前を一度だけ伝えてください（Decision M）。実行してはいけません。

1. 仕様から受け入れチェックリストを導き出す

機能のrequirements.md、design.md、tasks.mdを読みます。ユーザーが観察できる動作を記述した要件ごとに、具体的な確認項目を列挙します。正常系と、各エッジケース／エラー条件の両方を含め、要件IDに紐付けてください。仕様が根拠です。誰も事前に教えてくれなかった動作も確認対象です。追跡されていない動作はスキップせず、指摘すべき抜け漏れです。

チェックリストを.skills/<CODE>/acceptance.md（作業用の記録。gitで無視されます）に書き、各項目につきTodoを1つ作成します。読み込む量が多い場合は、スキャン用のサブエージェントに変更対象の範囲を洗い出させ、記録に要約させてください。このコンテキストは簡潔に保ちます。完了条件：ユーザー向けの要件IDすべてに、期待される結果を含む具体的で観察可能な確認項目が少なくとも1つあること。

プロダクトコンテキストのドキュメント（任意）

**適用条件：**受け入れ条件がペルソナまたは測定可能な成功指標に関わる場合。
読み込み：skills/project/define-system-doc/consult-recipe.md。
パス：docs/product/personas.md、metrics.md、principles.md。

**承認済みの場合：**関連する制約をチェックリストの期待値に反映します（参考情報であり、規範となるのは引き続き要件です）。**存在しない場合：**続行します。欠落が受け入れ条件を実質的に明確にする場合に限り、/define-system-doc product/personas|metrics|principlesを一度だけ提案してください。自動実行してはいけません。

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

チェックリストは各動作が存在する場所に応じて分かれます。該当するものを実行してください。ほとんどの機能では両方が必要です。

• 変更によって、クライアントが呼び出すHTTP/RPC APIが公開される → 必須サブスキル：validate-apiを使用する。
• 変更に、ユーザーが操作するフロントエンドが含まれる → 必須サブスキル：validate-uiを使用する。操作にはkimi-webbridgeを使います。 ブラウザハーネスはインストールされません。
• 動作がAPIでもUIでもない（CLI、ライブラリ、バッチ／cronジョブなど）→ 実行中のシステムを直接操作し、観察した結果をそれぞれ記録に残してください。合格した確認項目は、ドメインの動作を記述するコミット対象のテストに昇格させます（docs-only spine — テストファイルに要件IDのタグは不要です）。見た目や使い心地など、人の目で判断する品質はwrite-dogfoodに引き継いでください。

各子タスクには、記録の該当範囲をパスで渡してください。結果は同じファイルに書き戻します。

3. 最後まで確認する

各項目の観察結果を添えて、チェックリストを報告してください。実行できなかった項目はすべて未解決のリスクです。明示してください。黙って合格扱いにしてはいけません。その後、land-branchに引き継ぎます。UIの受け入れ確認の証拠は、webbridgeでの操作記録.skills/<CODE>/validate-ui.mdです。プロダクトの不具合には、リポジトリ既存のテストスタックで回帰テストも追加します。完了条件：実行中のシステムでチェックリストの全項目が成功と確認され、失敗はすべて既存のテストスタックに回帰テストを追加して修正され、UI操作の記録がディスク上に保存されていること。