announcement-summary

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: 対象の特定

調査対象の製品・サービスを特定し、以下を確認:

• content/announcements/ に既存エントリがないか（重複防止）
• content/tags.json に適切なタグがあるか（なければ追加を検討）
• ソース URL が既にカバー済みでないかを確認:

  node scripts/check-url.mjs "<ソースURL>"
  

  ✓ が返る場合はそのエントリに情報追記を検討。✗ が返る場合は新規エントリ候補。

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 直前に公開されセッションで深掘り → 含める