ask-answer

open askを一覧し、1件ずつ人間に提示して回答を得たらanswer_askで記録する最小skill。トリアージ判定・同型判定・監視ループは持たず、「聞く→答える→記録する」の直線フローだけを担当する。

「askに答える」「open ask消化して」「溜まってるask片付けたい」「判断待ちに回答する」などの依頼で使う。

手順

1. get_asks()を1回だけ呼ぶ（statusの既定値は"open"なので省略してよい）。ユーザーが明示的にkind/tags等を指定しない限り、追加のフィルタ引数は渡さない。limitはデフォルト（20件）のままでよく、ページネーションのために追加呼び出しを重ねる必要はない。
2. total_countが0件なら「open askはありません」と提示し、answer_askを呼ばずにここで終了する。
3. 返り値のasks件数がtotal_countより少ない場合は「上位N件のみ表示（全M件）」と明記してから、1件ずつ順に人間へ提示する。提示はquestion（概要）を中心に、必要ならcontextも見せる。内部ID（id_raw）は表示せず、タイトル・要約ベースで「これは何のaskか」が伝わる形にする。
4. 人間から回答が得られたら、その発言をそのまま、または意図を汲んだ文面でanswer_ask(ask_id=<該当askのid_raw>, answer_body=<回答本文>)を呼ぶ。回答本文は人間の判断そのものであり、AIが代わりに考えて埋めない。A/はいのような一言回答も、そのままanswer_bodyに渡してよい（ask-composeのテンプレートが一言回答を許容しているため）。
5. answer_askが成功し、返り値のnext_stepにトリアージへの誘導が含まれていても、それはこのskillでは実行しない（次のaskへ進む）。対象がすでにanswered/promoted/dismissed等でanswer_askがエラーを返した場合は、エラーをそのまま提示して次のaskへ進む。
6. 残りのaskについて3〜5を繰り返し、最後まで進んだら完了を短く報告する。

注意

• 回答本文（answer_body）は人間の発言・意図をそのまま反映したものであり、AIが自分の判断で作文して埋めてはならない
• 1つのaskに対してanswer_askが成功するのは1回だけ。既にanswered/promoted/dismissed等になったaskへの再回答は拒否される
• triage_ask（promote/dismiss）・withdraw_askはこのskillの手順に含めない。答えた後の裁定（一般化ルールとして発効させるか、見送るか）は別経路（次回のcheck-in・get_asks(triage_pending_only=true)を使った非メタask自走裁定等）に委ねる。理由: このskillのスコープは「順に答えるだけ」であり、答えたその場でのtriageまでは含まない設計判断のため
• answer_askだけではaskは「回答済み・未triage」として残り、止めているactivityのcheck_inにも回答済み未triageとして出続ける（待ちから外れるのはtriage_askのpromote/dismiss、またはwithdraw_ask）。このskillで回答した後もその状態のままであることを、完了報告時に人間へ伝える
• 提示は常にタイトル・question・context等の内容ベースで行い、内部ID（id_raw）をユーザーに見せない
• kind="meta"のaskも通常のaskと同じ手順（一覧→提示→answer_ask）で処理できる（answer_askのシグネチャはkindに依存しない）。メタask固有の配置作業（rule-placement skillへの誘導）はこのskillの手順に含めない

関連skillとの境界

• ask-compose: add_askを呼ぶ前にquestion/contextを構成する。ask-answerは既に起票済みのaskに答える側であり、起票前の作業は担当しない
• ask-distill: add_ask呼び出し後、similar_asksから同型askの反復に気づいたときにメタaskを起票する。ask-answerは回答フローに専念し、同型判定・メタask起票は行わない
• ask-watch: open askの滞留をMonitorでイベント駆動監視し続けるスキル。ask-answerは1回限りの一覧+回答フローであり、継続監視は行わない