announcement-draftlisted

# announcement-draft — 告知文 text を opshub の context から組み立てて返す opshub MCP server (`opshub mcp serve`、ADR-0022) の read tool 群 (`recall.search` / `decision.list` / `brief`) をホスト LLM が合成して、リリース告知 / お知らせ文の text を 1 発で組み立てる。Phase 12 H5 (`docs/phase-12-plan.md` §3 H5) で導入された Tier 2 draft 系 skill。 **persist しない**: `reply-draft` と異なり、本 skill は `propose.generate` + `propose.apply` 経路を **使わない**。告知文は自発生成で natural key を持たないため (返信元 source のような対応付けがない)、proposal table に保存しても operator から見て idempotency / 削除 / 編集の semantics が曖昧になる。ADR-0016 §決定 (l)(a) で「返信元 source の有無」で persist 境界を切る方針が pin されており、本 skill は text-only 返却に留める。 ## 何が起きるか 1. ユーザーが「リリース告知書いて」「announcement 作って」「アナウンス文章」と頼む 2. ホストが本 skill を発火 3. ホストが下記「呼び出し順」に従って read tool を順次呼ぶ 4. 戻り値を集約してホスト LLM が告知文 text を 1 発で構成 (Markdown 推奨、投稿先 SaaS の syntax は user が手で調整) 5. ユーザーに text を提示 (画面表示のみ) 6. ユーザーが手で SaaS (Slack / Notion / GitHub release / メール 等) に投稿する opshub 側に候補保存 / apply 経路は存在しない (`propose.generate` / `propose.apply` を呼ばない)。「保存」のような UX を提示しないこと。 ## 呼び出し順 (MCP tool) ### Step 1: 関連 release / change context を recall ```text tool: recall.search input: query: "<リリース対象 / 機能名 / プロジェクト名>" limit: 20 ``` 告知対象の機能 / 変更 / リリース内容を recall で拾う。ADR-0012 hybrid recall (本文 embedding + FTS5 + graph 補強) で GitHub PR / Slack 議論 / Office 文書 / Outlook メール等から該当 context を集める。 ユーザーが PR 番号 / リリースタグ / 機能名を明示している場合は、それを query にそのまま渡す。 ### Step 2: last_release 以降の decision を列挙 ```text tool: decision.list input: recorded_after: "<前回 release の timestamp