| name | announcement-summary |
| description | Build 2026 の個別発表・新機能の content/announcements/*.md を作成・更新する。Use when: アナウンス作成、announcement、エントリ作成、製品まとめ、新機能追加、コンテンツ追加 |
アナウンスメントまとめスキル
Build 2026 の個別発表・新機能を調査し、content/announcements/{id}.md を生成・更新する。
When to Use
- 新しい製品・サービスの発表エントリを作成するとき
- 既存 announcement を深掘り・更新するとき
- Build 2026 ニュースからエントリ化するとき
前提
- 調査方法論は
research スキルに従う（ツール使い分け、ソース探索深さ、例外ハンドリング）
docs/content-guide.md の announcement テンプレートと深さ基準に従う- 1 製品/サービスにつき 1 ファイル
Procedure
Step 1: 対象の特定
調査対象の製品・サービスを特定し、以下を確認:
Step 2: 調査
research スキルの「ソース探索の深さ基準」に従い、8 カテゴリすべてを探索する。
特に announcement で重要なソース:
- Build ニュースハブ (
news.microsoft.com/build-2026/) — スコープの正
- 公式ブログ — 発表の詳細と技術的背景
- Microsoft Learn — ドキュメント、クイックスタート、What's New
Step 3: ドラフト生成
frontmatter
---
id: {kebab-case-product-name}
title: "{製品名}"
summary: {200-300文字。何が変わったか・何ができるようになったかを直接記述}
tags:
- {content/tags.json のスラッグ}
content_type: announcement
topic: {content/topics.json のスラッグ}
official_sources:
- {一次ソース URL}
---
title: 製品名そのまま。修飾語不要。「Build 2026」も不要。
summary: 製品名は title で表示されるため繰り返し不要。
本文構造（CI 検査対象）
## 概要
何が発表されたか、なぜ重要かを 2-3 段落で。
## 主な発表
Build 2026 で発表された事項の一覧（≥ 3 項目）。
- **機能名**: 一文の説明（**GA** / **Public Preview** / **Private Preview** を明記）
- **機能名**: ...
## 詳細
製品の仕組み、機能、アーキテクチャ。### でサブトピック分割（≥ 3 サブセクション）。
### サブトピック 1
### サブトピック 2
### サブトピック 3
## 応用シナリオ
ユースケースの具体的記述（≥ 3 項目）。
- シナリオ 1
- シナリオ 2
- シナリオ 3
## 制約・注意点
プレビュー制限、既知の問題、対応リージョン等。内容がなければ省略可。
## 参考リンク
最低 3 件。5 件以上推奨。
- [公式ブログ](URL)
- [ドキュメント](URL)
- [Build セッション](URL)
## 関連エントリ
content/ 内の関連エントリへの相互リンク。省略可。
Step 4: CI 深さ基準の確認
| ルール | 閾値 |
|---|
| 必須セクション | ## 概要、## 主な発表、## 詳細、## 応用シナリオ、## 参考リンク が全存在 |
| 「主な発表」の項目数 | ≥ 3（- ** で始まる行） |
| 「詳細」のサブセクション数 | ≥ 3（### で始まる行） |
| 「応用シナリオ」の項目数 | ≥ 3（- で始まる行） |
| 「参考リンク」のリンク数 | ≥ 3（- [ で始まる行） |
| 本文行数（frontmatter 除く） | ≥ 60 |
これらは 警告（コミットブロックしない）だが、可能な限り満たす。
Step 5: バリデーション
research スキルの「セルフバリデーション」チェックリストを実行し、npm run validate で確認。
加えて、タグの十分性を確認する: エントリの主要テーマに対応するタグが content/tags.json に存在しない場合、タグの追加を検討する。既存タグの aka で吸収できるか先に確認し、できなければ新規タグを追加する（slug は kebab-case、name は公式表記、aka に略称・旧名を含める）。
Step 6: 相互リンク
- 関連する
content/sessions/ エントリがあれば「関連エントリ」にリンク
- 関連する他の announcements もリンク（例: GitHub Copilot App ↔ GitHub Copilot SDK）
粒度の判断基準
- 1 ファイル = 1 製品/サービスのアップデートまとめ
- 判断基準: 「この製品について知りたい人が 1 ファイルで全体像を掴めるか」
- 独立性が高い発表は分離してよい（例: 料金変更は別ファイル）
対象範囲
- 含める: Build キーノート/セッションで言及、
news.microsoft.com/build-2026 掲載、公式ブログで「Build 2026」明示
- 含めない: Build と無関係な通常リリース、Build 前の事前発表で当日追加情報なし
- グレーゾーン: Build 直前に公開されセッションで深掘り → 含める
