MS Teams Announcement from Pull Requests
Overview
Generate professional Microsoft Teams channel announcements based on pull request changes. Analyze PR diffs, descriptions, and commit history using the GitHub MCP server, then produce a structured markdown message ready to paste into a Teams channel.
Announcement structure:
- Title - Emoji prefix + concise topic headline
- Subtitle - Context line with scope, version, or key qualifier
- Message Body - Opening context, bold section headers, bulleted details, links, and closing call to action
Prerequisites
The GitHub MCP server must be available in the current session. Verify by checking available MCP tools at the start of the workflow. If the GitHub MCP server is not available, inform the user that it is required for fetching pull request data.
Workflow
Step 1: Gather PR Information
Determine whether the announcement covers a single PR or multiple PRs.
For a single PR, use the GitHub MCP server to fetch:
- PR title, description, and labels
- Changed files list and diff summary
- Commit messages
For multiple PRs (e.g., a release or migration), fetch the above for each PR and identify common themes, affected areas, and the overall scope of changes.
If the user provides PR numbers or URLs, use those directly. If not, ask the user to specify which PR(s) to announce.
Step 2: Analyze Changes
Categorize the changes from the PR(s):
- What changed - Upgrades, new features, deprecations, security patches, tooling additions
- What areas are affected - Frameworks, libraries, developer workflows, build pipelines
- Why it matters - Security, performance, developer experience, compliance
- What action is needed - Verification, migration steps, version upgrades, nothing
Focus on impact and outcomes rather than implementation details. Translate technical diffs into language that communicates value to the target audience.
Step 3: Compose the Announcement
Produce the announcement following the format and guidelines below.
Announcement Format
Title: [emoji] [Topic]
Subtitle: [Context — Qualifier]
[Opening paragraph]
[Bold section headers with content]
[Links and closing]
Title Guidelines
- Begin with a relevant emoji that visually identifies the topic
- Follow with a concise topic (framework name, feature, tool)
- Keep under 60 characters (excluding emoji)
- Use version transition notation where applicable (e.g., "v18→19")
Examples:
🔒 Security Patch — Auth Library v3.2.1
🚀 Welcome ECMAScript 2025
⚛️ React 18→19
⚠️ Drop Node.js 18 Support
🤖 AI Assistant First-Class Support
🤖 New Calude Code Skill: localize
Subtitle Guidelines
- One line providing scope, version detail, or key qualifier
- Use em dash (—) to separate topic from qualifier
- Keep under 100 characters
Examples:
Critical Security Patch — March Release Target
ES2025 is Here — New Language Features Now Available
Node v22 is supported for local development and CI runners
Message Body Guidelines
Structure the body with these elements as applicable:
- Opening paragraph - One to three sentences establishing context: what happened, who did it, and when. Include the PR link inline.
- Bold section headers - Use
**Header** to organize content into logical sections. Common headers:
**Notable Changes** or **What's New** - for listing changes
**Impact** - for downstream effects
**⚠️ IMPORTANT ⚠️** - for critical action items or deprecations
**What should I know** - for linking to external docs or guides
- Bulleted details - List specific changes, versions, or features under each section header
- Links - Include PR URLs, changelog links, documentation links, and discussion links inline where relevant
- Closing - End with a call to action, invitation for questions, or team contact line
Writing style:
- Professional but approachable — use "we" and team attribution
- Write in past tense for completed actions ("has been upgraded"), present tense for current state ("is now available")
- Include version numbers with transition notation where relevant (e.g., "5.5.4 -> 5.8.3")
- Bold key dates, version numbers, and action items for scannability
- Link to external resources (changelogs, official docs, guides) rather than repeating their content
- Keep total body under 250 words for single-PR announcements, under 400 words for multi-PR
Step 4: Present and Refine
Present the composed announcement to the user in a copyable markdown block. Offer to adjust tone, length, or detail level if needed.
Announcement Categories
Different change types call for different emphasis:
- Framework/library upgrades - Lead with version transition, list notable dependency changes with changelog links, mention release timeline
- Security patches - Lead with urgency, reference CVEs or advisories, specify release target
- Deprecation notices - Lead with the deadline, bold the deprecation date, provide migration steps
- New tooling/features - Lead with the value proposition, describe setup or usage, invite the team to try it
- Documentation - Lead with what's covered, link directly to the resource, invite contributions
Multi-PR Announcements
When summarizing multiple PRs into a single announcement:
- Group changes by theme or affected area rather than listing per-PR
- Identify the most significant changes and lead with those
- Mention the total number of PRs and provide links to all of them
- Use a milestone or release-style title when appropriate
Tone Calibration
Default to a professional, approachable tone suitable for engineering channels — the kind of message a tech lead would post. If the user specifies a different audience, adjust accordingly:
- Engineering channel - Include version numbers, dependency names, changelog links, CLI commands
- Broader audience - Focus on user-facing impact, avoid internal tooling details
- Leadership - Emphasize business value, timelines, and risk mitigation
Output Expectations
Always output the final announcement inside a single fenced code block (```markdown) so the user can easily copy and paste it into Teams. Teams supports markdown formatting including bold, italic, bulleted lists, and links.
Additional Resources
Reference Files
For detailed examples of announcements across different categories:
references/announcement-examples.md - Full example announcements covering upgrades, security patches, deprecations, new tooling, and documentation releases
Example Files
examples/single-pr-announcement.md - Example output for a framework upgrade announcement
examples/multi-pr-announcement.md - Example output for a multi-topic release announcement
1---2name: create-announcement3description: This skill should be used when the user asks to "create an announcement", "write a Teams message for a PR", "write a Slack message for a PR", "announce PR changes", "generate a release announcement", "summarize PR for Teams", "summarize PR for Slack", "draft a channel post", or needs to turn GitHub pull request changes into a formatted announcement for IM platforms (MS Teams, Slack). Supports single-PR and multi-PR release announcements.4---56# MS Teams Announcement from Pull Requests78## Overview910Generate professional Microsoft Teams channel announcements based on pull request changes. Analyze PR diffs, descriptions, and commit history using the GitHub MCP server, then produce a structured markdown message ready to paste into a Teams channel.1112**Announcement structure:**13- **Title** - Emoji prefix + concise topic headline14- **Subtitle** - Context line with scope, version, or key qualifier15- **Message Body** - Opening context, bold section headers, bulleted details, links, and closing call to action1617## Prerequisites1819The GitHub MCP server must be available in the current session. Verify by checking available MCP tools at the start of the workflow. If the GitHub MCP server is not available, inform the user that it is required for fetching pull request data.2021## Workflow2223### Step 1: Gather PR Information2425Determine whether the announcement covers a single PR or multiple PRs.2627**For a single PR**, use the GitHub MCP server to fetch:28- PR title, description, and labels29- Changed files list and diff summary30- Commit messages3132**For multiple PRs** (e.g., a release or migration), fetch the above for each PR and identify common themes, affected areas, and the overall scope of changes.3334If the user provides PR numbers or URLs, use those directly. If not, ask the user to specify which PR(s) to announce.3536### Step 2: Analyze Changes3738Categorize the changes from the PR(s):39401. **What changed** - Upgrades, new features, deprecations, security patches, tooling additions412. **What areas are affected** - Frameworks, libraries, developer workflows, build pipelines423. **Why it matters** - Security, performance, developer experience, compliance434. **What action is needed** - Verification, migration steps, version upgrades, nothing4445Focus on impact and outcomes rather than implementation details. Translate technical diffs into language that communicates value to the target audience.4647### Step 3: Compose the Announcement4849Produce the announcement following the format and guidelines below.5051#### Announcement Format5253```markdown54Title: [emoji] [Topic]55Subtitle: [Context — Qualifier]5657[Opening paragraph]5859[Bold section headers with content]6061[Links and closing]62```6364#### Title Guidelines6566- Begin with a relevant emoji that visually identifies the topic67- Follow with a concise topic (framework name, feature, tool)68- Keep under 60 characters (excluding emoji)69- Use version transition notation where applicable (e.g., "v18→19")7071**Examples:**72- `🔒 Security Patch — Auth Library v3.2.1`73- `🚀 Welcome ECMAScript 2025`74- `⚛️ React 18→19`75- `⚠️ Drop Node.js 18 Support`76- `🤖 AI Assistant First-Class Support`77- `🤖 New Calude Code Skill: localize`7879#### Subtitle Guidelines8081- One line providing scope, version detail, or key qualifier82- Use em dash (—) to separate topic from qualifier83- Keep under 100 characters8485**Examples:**86- `Critical Security Patch — March Release Target`87- `ES2025 is Here — New Language Features Now Available`88- `Node v22 is supported for local development and CI runners`8990#### Message Body Guidelines9192Structure the body with these elements as applicable:93941. **Opening paragraph** - One to three sentences establishing context: what happened, who did it, and when. Include the PR link inline.952. **Bold section headers** - Use `**Header**` to organize content into logical sections. Common headers:96 - `**Notable Changes**` or `**What's New**` - for listing changes97 - `**Impact**` - for downstream effects98 - `**⚠️ IMPORTANT ⚠️**` - for critical action items or deprecations99 - `**What should I know**` - for linking to external docs or guides1003. **Bulleted details** - List specific changes, versions, or features under each section header1014. **Links** - Include PR URLs, changelog links, documentation links, and discussion links inline where relevant1025. **Closing** - End with a call to action, invitation for questions, or team contact line103104**Writing style:**105- Professional but approachable — use "we" and team attribution106- Write in past tense for completed actions ("has been upgraded"), present tense for current state ("is now available")107- Include version numbers with transition notation where relevant (e.g., "5.5.4 -> 5.8.3")108- Bold key dates, version numbers, and action items for scannability109- Link to external resources (changelogs, official docs, guides) rather than repeating their content110- Keep total body under 250 words for single-PR announcements, under 400 words for multi-PR111112### Step 4: Present and Refine113114Present the composed announcement to the user in a copyable markdown block. Offer to adjust tone, length, or detail level if needed.115116## Announcement Categories117118Different change types call for different emphasis:119120- **Framework/library upgrades** - Lead with version transition, list notable dependency changes with changelog links, mention release timeline121- **Security patches** - Lead with urgency, reference CVEs or advisories, specify release target122- **Deprecation notices** - Lead with the deadline, bold the deprecation date, provide migration steps123- **New tooling/features** - Lead with the value proposition, describe setup or usage, invite the team to try it124- **Documentation** - Lead with what's covered, link directly to the resource, invite contributions125126## Multi-PR Announcements127128When summarizing multiple PRs into a single announcement:129130- Group changes by theme or affected area rather than listing per-PR131- Identify the most significant changes and lead with those132- Mention the total number of PRs and provide links to all of them133- Use a milestone or release-style title when appropriate134135## Tone Calibration136137Default to a professional, approachable tone suitable for engineering channels — the kind of message a tech lead would post. If the user specifies a different audience, adjust accordingly:138139- **Engineering channel** - Include version numbers, dependency names, changelog links, CLI commands140- **Broader audience** - Focus on user-facing impact, avoid internal tooling details141- **Leadership** - Emphasize business value, timelines, and risk mitigation142143## Output Expectations144145Always output the final announcement inside a single fenced code block (```markdown) so the user can easily copy and paste it into Teams. Teams supports markdown formatting including bold, italic, bulleted lists, and links.146147## Additional Resources148149### Reference Files150151For detailed examples of announcements across different categories:152- **`references/announcement-examples.md`** - Full example announcements covering upgrades, security patches, deprecations, new tooling, and documentation releases153154### Example Files155156- **`examples/single-pr-announcement.md`** - Example output for a framework upgrade announcement157- **`examples/multi-pr-announcement.md`** - Example output for a multi-topic release announcement