ask-compose

add_askのquestion/context欄を、questionの概要/選択肢/おすすめ、contextの対象activity/背景という構成テンプレートに沿って組み立てる。question/contextの記入品質をここに集約しているため、add_askを呼ぶ前に本スキルの手順を必ず通す。

発動契機

以下のいずれかに該当する場合に発動する。

• AI自発判断: 離席中・セッション跨ぎでしか答えられない判断が発生し、add_askを呼ぼうとしている場面
• ユーザー明示指示: 「これ聞いといて」「これaskして」「判断委譲しといて」「離席するから後で確認して」「非同期で聞いておいて」「これは私が戻ってから判断する」など、ユーザーが明示的に非同期の判断委譲を指示した場面

いずれの場合も、add_askを呼ぶ前に必ず本スキルの手順（テンプレートに沿った構成）を通す。

対象

• add_askのquestion/context欄の構成

add_ask呼び出し後、レスポンスのsimilar_asksから同型askの反復に気づいたときのメタask起票はask-distill skillが担当する。本スキルはメタask化の判定を行わない。

kind="meta"のメタask自体の起票は本スキルを経由しない。ask-distill・ask-watchが各々の組み立て方（question/context/blocksの構成）に従って直接add_askを呼ぶ。

なぜこの構成にするか

askはダッシュボード等、Markdown装飾が効かない環境で読まれることがある。装飾に頼らず「今どの節を読んでいるか」が見出し文字列だけで伝わるよう、節を固定順の構成に分けている。

LINE（askくん）等の通知経路はquestionしか表示せず、contextは別途開かないと読めない。そのため、その場で答えを決めるのに必要な情報（概要・選択肢・おすすめ）はquestionに集約し、前提知識や経緯などcontextを開かなくても答えに支障が出ない情報だけをcontextの背景に置く。対象activityは、contextのどの節よりも前に置く。読み手がまず「これは何の作業の話か」を把握してから背景を読めるようにするためである。

テンプレート

questionには「## 概要」「## 選択肢」「## おすすめ」を、contextには先頭の対象activity行と「## 背景」を記入する分担を基本とする（questionは500字以内の制約があるため、選択肢とおすすめも含めて簡潔に書き切る。詳しい経緯や比較はcontextの背景に逃がす）。

## 概要
- 問題：(何が起きていて、なぜ今判断が要るのかを1-2文で)
- 決めてほしいこと：(Yes/No、またはA/B/Cのどれかを選ぶ、という形に落とし込む)

## 選択肢
- A: 〜 — 良い点：… / 悪い点：…
- B: 〜 — 良い点：… / 悪い点：…

## おすすめ
- 推奨：A（理由：…）

---
一言で答える場合は `A`/`B`/`はい`/`いいえ` だけでもOK

対象activity: 「(このaskが答え待ちで止めているactivityのタイトル。blocksに渡す各activity IDに対応する、人間可読なタイトル文字列。IDそのものは書かない)」

## 背景
- 今のタスク：(このセッションが何に取り組んでいるか。前提知識ゼロで読める粒度で)
- 経緯：(何をしていてこの分岐に当たったか)
- 影響範囲：(この判断がどこまで効くか。可逆/不可逆をここに含める)
- 放置するとどうなるか：(今のままだと何が止まり続けるか)

questionを500字に収める書き方

question本文は概要・選択肢・おすすめの3節を合わせて500字以内に収める必要がある。目安と、超えたときの削り方は次のとおり。

• 概要: 問題1文＋決めてほしいこと1文で150字程度に収める
• 選択肢: 2〜3案。1案につき「ラベル — 良い点：◯◯ / 悪い点：◯◯」の1行（60字程度）に圧縮する。良い点・悪い点はそれぞれ10〜15字程度の一言に削る
• おすすめ: 推奨ラベルと理由を1行（50字程度）にまとめる
• 上記の目安どおりなら3択でも400字前後に収まる。それでも超える場合は、①選択肢を2件に絞る、②良い点・悪い点のうち判断に効く方だけ残す、③決めてほしいことの文言をさらに削る、の順で切り詰める。削った詳しい比較や経緯はcontextの背景に書けば情報は失われない

各項目の記入ガイド

概要（questionに記入）

• 問題: 前提を知らない人がこの1-2文だけで「何が起きているか」を理解できるように書く。技術的詳細は背景に譲り、ここでは状況の要約に徹する
• 決めてほしいこと: 自由記述の問いにしない。人間が数秒で答えられる形（Yes/No、A/B/Cのどれか）に必ず落とし込む。「どう思いますか」のような開いた問いは書かない

対象activity（contextの先頭、## 背景より前）

• add_askのblocks引数に渡す各activity IDについて、そのタイトル（人間可読な文字列）を対象activity: 「タイトル」の形式でcontextの一番先頭に書く。IDそのものを書いてはいけない（calm内部識別子は読み手に解決できないため）
• タイトルは基本、そのセッションが既にcheck_inやget_activitiesで取得済みの値をそのまま使う。手元に無い場合のみ、あらためてget_activitiesで解決してから記入する
• blocksが複数件のときは 対象activity: 「タイトルA」、「タイトルB」 のようにカギ括弧を読点で区切って1行に収める。件数が多く1行が読みにくくなる場合（目安3件超）は、1行1タイトルの箇条書きに切り替えてよい

背景

• 今のタスク: 読み手がこのセッションの文脈を一切知らない前提で、何に取り組んでいるかを書く
• 経緯: なぜこの分岐に当たったのか、直前の作業の流れを書く
• 影響範囲: この判断が及ぶ範囲を書く。特に「後から取り消せるか（可逆）」「一度実行すると戻せないか（不可逆）」を明示する。不可逆な判断ほど詳しい背景が必要になる
• 放置するとどうなるか: 判断を待たずに放置した場合に何が止まるか、どんな実害が生じるかを書く。緊急度の判断材料になる

選択肢（questionに記入）

• 最低2案は出す。「やる/やらない」のような単純な二択でも、それぞれの良い点・悪い点は省略しない
• questionの500字予算があるため、各案は「ラベル — 良い点：… / 悪い点：…」の1行に圧縮する。詳しい比較が要るならcontextの背景に書く（書き方の目安は前節「questionを500字に収める書き方」参照）
• 選択肢がある場合のみ、各選択肢のラベル（- A: 〜 — 良い点：…の〜部分。良い点/悪い点の説明文は含めない）をadd_askのchoices引数（list[str]）にも渡すことを推奨する。Yes/Noのみで案として列挙するものがないaskではchoicesを渡さなくてよい（省略時はnull扱い）。ダッシュボード等でのボタン表示に使われるため、Markdown本文のラベルと重複してよい
• choicesには最大3件・1件100字以内という制約がある。Markdown側の選択肢が4件以上ある場合は、「## おすすめ」に近い優先度上位3件のみをchoicesに渡す（残りはquestionの「## 選択肢」節にのみ残す）。ラベルが100字を超える場合は、100字以内に要約してから渡す（詳しい説明はquestionの「## 選択肢」節に残せばよく、choices側で削っても情報は失われない）

おすすめ（questionに記入）

• 必ず1案を推奨する。「どちらでもいい」は書かない（推奨が無いと判断委譲の意味が薄れる）
• 理由は一言で、良い点・悪い点のどちらを重視したかが伝わる書き方にする。「Aがいいと思う」だけで終わらせない。詳しい論拠が要るならcontextの背景に書く

記入例

question:

## 概要
- 問題：夜間バッチでの外部API同期中にレート制限（429）を受けた。リトライ待機時間はAPI側の応答で60分と判明している。
- 決めてほしいこと：60分待ってリトライを続行する（A）か、今回は中断し翌日の定期実行に任せる（B）かを選んでほしい。

## 選択肢
- A: 60分待ってリトライを続行する — 良い点：今日中に完走 / 悪い点：1時間他処理をブロック
- B: 中断し翌日の定期実行に任せる — 良い点：即座にリソース解放 / 悪い点：同期が1日遅れる

## おすすめ
- 推奨：B（理由：アカウント一時停止のリスク回避を最優先。1日の遅延は許容範囲）

---
一言で答える場合は `A`/`B` だけでもOK

context:

対象activity: 「夜間バッチでの外部API同期処理」

## 背景
- 今のタスク：夜間バッチで外部APIから1000件のデータを同期する処理を実行中。
- 経緯：600件処理した時点でレート制限に達した。APIの利用規約上、制限中に再度リクエストを送るとアカウントが一時停止されるリスクがある。
- 影響範囲：可逆。今回のバッチを中断しても、翌日の定期実行で自動的に残り400件を含めて再同期される設計になっている。
- 放置するとどうなるか：判断を待たずに放置すると、バッチプロセスがタイムアウトするまで無応答のまま残り続ける。

goalの条件をこのaskに束縛する

このaskが、goalの条件（担い手human）の待ちを形にするために起票するものなら、次も行う。

• blocks には、その条件を持つactivityに加え、同じgoalに紐づく兄弟activityのうち、そのactivityへのcheck_inでも回答待ち・振り分け待ちを出したいものを含める
• add_ask の呼び出し後、update_goal で対象の条件を {"op": "edit", "id": <条件id>, "actor": "human", "bound": {"type": "ask", "id": <このaskのid>}} に束縛する

ask を起票するのは、その場で聞けずユーザーが離席中・セッションをまたぐときに限る（発動契機のとおり）。その場で聞けるなら ask を起票せず、聞いて decision-record で決定として記録する。

add_ask呼び出し後: 回答の受け取り方

Claude Codeでは、add_askを呼んだ直後からCALMのhookが裏で回答を待つ。回答（またはpromote/dismiss）されると、hookがこのセッションを起こし、askの番号と状態だけを知らせる。Monitorを張る必要はない。

起こされたら次の順で進める。

1. get_asks(ids=[<番号>], status=null)で回答を読む（statusを省略すると既定の"open"で絞り込まれ、回答済みのaskが返らない）
2. 回答に沿って作業を続ける
3. statusがansweredなら、読んだら早めにtriage_askで処理済みにする（決定として残す内容ならpromote、そうでなければdismiss）。回答済み・未トリアージのまま残すと、check_inでの再配達や外部の作業再開の仕組みが同じaskで二重に動くことがある

その場で待つ必要が無いask（後で気づけば十分な優先度のもの）はnotify=Falseで積む。hookは待たず、起こしもしない。積んだ後で待つのをやめたい場合はunsubscribe_askを呼ぶ（待機中のhookも止まる。ただし複数セッションから積まれた同じ問いのaskには使えない）。

積んだaskが、その後の会話の途中で実質決着していると気づいたとき（ユーザーが別の場で同じ件に答えた、議論の中で結論が出た、など）は、その時点で答えを add_decisions で決定事項に記録してから取り下げる（未回答なら withdraw_ask、回答済み未triageなら triage_ask）。askを開いたまま残すと、完了したactivityにぶら下がって誰にも届かない待ちになる。

hookが待つのは最長で約24時間。それを過ぎた場合や、hookの無いハーネス（Codex等）では、SessionStart/UserPromptSubmit hookがこのセッションの登録したaskの解決状況を毎ターン確認して知らせる。

ask-distillとの境界

• ask-compose（本スキル）: add_askを呼ぶ前に、question/contextの構成を担当する
• ask-distill: add_askを呼んだ後、レスポンスのsimilar_asksを見て同型askの反復に気づいたときのメタask起票を担当する

両者は時系列で別の場面に発動する別スキルであり、混同しない。