| name | proposal-review |
| description | 「保留中の提案を確認」「pending な候補をレビュー」「溜まってる draft を捌いて」「提案を承認/却下」と頼まれたら、Suasor MCP の propose.list（state=pending）で生成済み候補を一覧し、ユーザーに提示して確認を取った上で、承認分のみ propose.apply で適用し、不要分は propose.reject（任意で理由）で却下する。auto-apply 経路は存在しない。 |
| readOnly | false |
| category | triage |
| triggers | ["保留中の提案を確認","pending な候補をレビュー","溜まってる draft を捌いて","提案を承認/却下"] |
| pairs | [] |
| mcp_tools_read | ["propose.list"] |
| mcp_tools_write | ["propose.apply","propose.reject","propose.batch","proposal.feedback"] |
proposal-review
各 skill（reply-draft / source-extract / meeting-followup / inbox-triage / commitment-review）が貯めた pending 候補をまとめてレビューし、承認/却下する HITL write skill。propose.* ライフサイクル（Issue #89）の「出口」= 承認キューに当たる（ADR-0004）。
いつ発火するか
- 「保留中の提案を確認」「pending な候補をレビュー」
- 「溜まってる draft を捌いて」「提案を承認/却下」「承認待ちある?」
何をするか（MCP tool flow）
read で集めて、write は HITL。auto-apply 経路は存在しない（ADR-0004）。
propose.list（state=pending）で承認待ち候補を一覧する。kind（task / decision / reply_draft / triage / commitment）や updated_at 時間窓で絞り込める。各行は candidateId / mode / kind / summary / createdAt。既に却下した候補とその理由を振り返るときは state=rejected で一覧する（各行の reason に却下理由が入る、#197）- 候補を kind / mode 別に整理し、ユーザーに提示して 1 件ずつ（または一括で）承認 / 却下の判断を取る（native framing: ホスト側で人の承認を促す）
- 承認分は
propose.apply でまとめて適用する（対応する domain event を append、idempotent。既適用は skipped）。適用で ledger が pending → applied に遷移する
- 却下分は
propose.reject（candidateId、任意で reason）で却下する。ledger が pending → rejected に遷移し、以後 propose.list の pending に現れない（再提示しない）
- 承認と却下が混在するときは
propose.batch（operations: [{action: "apply", candidate}, {action: "reject", candidateId, reason?}]）で 1 RPC・単一トランザクションにまとめられる（atomic、apply/reject と同じ semantics）。HITL（人の一括判断後にのみ呼ぶ、#197）
- 却下でも承認でもなく「修正して再生成」したいときは
proposal.feedback（candidateId、reason 必須）で再生成ヒントを記録する（#279）。候補は pending のまま（state を遷移させない）で、記録した reason は propose.list で読める。ユーザーがその方向で作り直したいときは生成元 skill（reply-draft 等）で propose.generate し直す
制約
- HITL。人の承認なしに
propose.apply / propose.reject を呼ばない。auto-apply しない。propose.list は read（候補確認）
- 候補は生成元 skill が
propose.generate で作る。本 skill は候補を生成しない（横断レビューに専念）。新規候補が要るなら生成元 skill（reply-draft 等）を使う
- 状態依存:
propose.reject は pending のときのみ却下。applied（適用済み）/ missing（該当なし）は遷移させず status で報告し、rejected 再呼び出しは already_rejected（no-op）。proposal.feedback も pending のときのみ reason を記録（state 据え置き）。applied / rejected / missing は status 報告のみ
- 本 skill は手順書のみで実処理を持たない
