Add roundup plugin: self-configuring status briefing generator (#1157)

* Add roundup plugin: self-configuring status briefing generator

Adds a new plugin with two skills:

- roundup-setup: Interactive onboarding that learns the user's communication
  style from examples, discovers available data sources, and builds audience
  profiles. Writes a persistent config to ~/.config/roundup/config.md.

- roundup: Generates draft status briefings on demand by pulling from
  configured sources (GitHub, M365, Slack, Google Workspace, etc.) and
  synthesizing in the user's learned style for any defined audience.

Platform-agnostic by design -- adapts to whatever MCP tools are available
in the user's environment rather than assuming specific integrations.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Address PR review comments

- Fix 'use roundup' help text to clarify multi-audience behavior instead
  of referencing a nonexistent 'default audience'
- Split bundled 'who do you report to + who is on your team' into two
  separate ask_user questions per the one-question-at-a-time rule
- Specify ~/Desktop as explicit save path with fallback prompt when
  directory doesn't exist
- Tables in README verified as correct markdown (single | delimiters)

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Improve example-pasting UX in setup flow

- Make 'paste the whole thing right here' explicit so users aren't
  unsure about what/how much to paste
- Confirm receipt more clearly ('grabbed all of that')
- Reframe second example prompt to explain why a second helps
- Cap follow-up asks at two so it doesn't feel nagging
- Note that messy formatting is fine

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Reinforce that more examples = better output

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

---------

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

.github/plugin/marketplace.json

@@ -435,6 +435,12 @@
       "description": "Complete toolkit for building Model Context Protocol (MCP) servers in Python using the official SDK with FastMCP. Includes instructions for best practices, a prompt for generating servers, and an expert chat mode for guidance.",
       "version": "1.0.0"
     },
+    {
+      "name": "roundup",
+      "source": "roundup",
+      "description": "Self-configuring status briefing generator. Learns your communication style from examples, discovers your data sources, and produces draft updates for any audience on demand.",
+      "version": "1.0.0"
+    },
     {
       "name": "ruby-mcp-development",
       "source": "ruby-mcp-development",

docs/README.plugins.md

@@ -66,6 +66,7 @@ See [CONTRIBUTING.md](../CONTRIBUTING.md#adding-plugins) for guidelines on how t
 | [power-platform-mcp-connector-development](../plugins/power-platform-mcp-connector-development/README.md) | Complete toolkit for developing Power Platform custom connectors with Model Context Protocol integration for Microsoft Copilot Studio | 3 items | power-platform, mcp, copilot-studio, custom-connector, json-rpc |
 | [project-planning](../plugins/project-planning/README.md) | Tools and guidance for software project planning, feature breakdown, epic management, implementation planning, and task organization for development teams. | 15 items | planning, project-management, epic, feature, implementation, task, architecture, technical-spike |
 | [python-mcp-development](../plugins/python-mcp-development/README.md) | Complete toolkit for building Model Context Protocol (MCP) servers in Python using the official SDK with FastMCP. Includes instructions for best practices, a prompt for generating servers, and an expert chat mode for guidance. | 2 items | python, mcp, model-context-protocol, fastmcp, server-development |
+| [roundup](../plugins/roundup/README.md) | Self-configuring status briefing generator. Learns your communication style from examples, discovers your data sources, and produces draft updates for any audience on demand. | 2 items | status-updates, briefings, management, productivity, communication, synthesis, roundup, copilot-cli |
 | [ruby-mcp-development](../plugins/ruby-mcp-development/README.md) | Complete toolkit for building Model Context Protocol servers in Ruby using the official MCP Ruby SDK gem with Rails integration support. | 2 items | ruby, mcp, model-context-protocol, server-development, sdk, rails, gem |
 | [rug-agentic-workflow](../plugins/rug-agentic-workflow/README.md) | Three-agent workflow for orchestrated software delivery with an orchestrator plus implementation and QA subagents. | 3 items | agentic-workflow, orchestration, subagents, software-engineering, qa |
 | [rust-mcp-development](../plugins/rust-mcp-development/README.md) | Build high-performance Model Context Protocol servers in Rust using the official rmcp SDK with async/await, procedural macros, and type-safe implementations. | 2 items | rust, mcp, model-context-protocol, server-development, sdk, tokio, async, macros, rmcp |

docs/README.skills.md

@@ -228,6 +228,8 @@ See [CONTRIBUTING.md](../CONTRIBUTING.md#adding-skills) for guidelines on how to
 | [repo-story-time](../skills/repo-story-time/SKILL.md) | Generate a comprehensive repository summary and narrative story from commit history | None |
 | [review-and-refactor](../skills/review-and-refactor/SKILL.md) | Review and refactor code in your project according to defined instructions | None |
 | [reviewing-oracle-to-postgres-migration](../skills/reviewing-oracle-to-postgres-migration/SKILL.md) | Identifies Oracle-to-PostgreSQL migration risks by cross-referencing code against known behavioral differences (empty strings, refcursors, type coercion, sorting, timestamps, concurrent transactions, etc.). Use when planning a database migration, reviewing migration artifacts, or validating that integration tests cover Oracle/PostgreSQL differences. | `references/REFERENCE.md`<br />`references/empty-strings-handling.md`<br />`references/no-data-found-exceptions.md`<br />`references/oracle-parentheses-from-clause.md`<br />`references/oracle-to-postgres-sorting.md`<br />`references/oracle-to-postgres-timestamp-timezone.md`<br />`references/oracle-to-postgres-to-char-numeric.md`<br />`references/oracle-to-postgres-type-coercion.md`<br />`references/postgres-concurrent-transactions.md`<br />`references/postgres-refcursor-handling.md` |
+| [roundup](../skills/roundup/SKILL.md) | Generate personalized status briefings on demand. Pulls from your configured data sources (GitHub, email, Teams, Slack, and more), synthesizes across them, and drafts updates in your own communication style for any audience you define. | None |
+| [roundup-setup](../skills/roundup-setup/SKILL.md) | Interactive onboarding that learns your communication style, audiences, and data sources to configure personalized status briefings. Paste in examples of updates you already write, answer a few questions, and roundup calibrates itself to your workflow. | `references/config-template.md` |
 | [ruby-mcp-server-generator](../skills/ruby-mcp-server-generator/SKILL.md) | Generate a complete Model Context Protocol server project in Ruby using the official MCP Ruby SDK gem. | None |
 | [rust-mcp-server-generator](../skills/rust-mcp-server-generator/SKILL.md) | Generate a complete Rust Model Context Protocol server project with tools, prompts, resources, and tests using the official rmcp SDK | None |
 | [sandbox-npm-install](../skills/sandbox-npm-install/SKILL.md) | Install npm packages in a Docker sandbox environment. Use this skill whenever you need to install, reinstall, or update node_modules inside a container where the workspace is mounted via virtiofs. Native binaries (esbuild, lightningcss, rollup) crash on virtiofs, so packages must be installed on the local ext4 filesystem and symlinked back. | `scripts/install.sh` |

plugins/roundup/.github/plugin/plugin.json

@@ -0,0 +1,24 @@
+{
+  "name": "roundup",
+  "description": "Self-configuring status briefing generator. Learns your communication style from examples, discovers your data sources, and produces draft updates for any audience on demand.",
+  "version": "1.0.0",
+  "author": {
+    "name": "Awesome Copilot Community"
+  },
+  "repository": "https://github.com/github/awesome-copilot",
+  "license": "MIT",
+  "keywords": [
+    "status-updates",
+    "briefings",
+    "management",
+    "productivity",
+    "communication",
+    "synthesis",
+    "roundup",
+    "copilot-cli"
+  ],
+  "skills": [
+    "./skills/roundup-setup/",
+    "./skills/roundup/"
+  ]
+}

plugins/roundup/README.md

@@ -0,0 +1,101 @@
+# Roundup
+
+Status briefing generator that learns how you communicate.
+
+Roundup watches your work across GitHub, email, Teams, Slack, and other tools, then drafts status updates and briefings in your own voice for any audience you define.
+
+## The Problem
+
+Managers and team leads spend hours each week assembling status updates from scattered sources: scanning PR activity in GitHub, reading email threads for decisions, checking Teams or Slack for context, then rewriting all of it for different audiences at different levels of detail.
+
+The data to write these updates already exists. The work is in gathering it and packaging it. Roundup automates the gathering and drafting. You provide quality control and hit send.
+
+## How It Works
+
+**First time (5 minutes):** Run the setup skill. It asks about your role, your audiences, and where your team's work happens. Then you paste in an example or two of updates you've already written. From those examples, it learns your format, tone, structure, and what you include vs. skip.
+
+**Every time after:** Tell roundup which audience you're writing for. It pulls fresh data from your configured sources, synthesizes across them, and drafts a briefing matching your style.
+
+## Installation
+
+```bash
+copilot plugin install roundup@awesome-copilot
+```
+
+## Getting Started
+
+### First-Time Setup
+
+```
+use roundup-setup
+```
+
+The setup flow walks you through:
+- Describing your role and team
+- Pasting in example updates you've already written
+- Defining your audiences (leadership, team, partners, etc.) and what each one cares about
+- Identifying where your team's work and conversations happen
+
+### Generating a Briefing
+
+```
+use roundup
+```
+
+Or be more specific:
+
+```
+use roundup -- generate a leadership briefing covering this past week
+```
+
+```
+use roundup -- draft a team update since Monday
+```
+
+## What's Included
+
+| Skill | What It Does |
+|-------|-------------|
+| `roundup-setup` | Interactive onboarding that learns your style, audiences, and data sources |
+| `roundup` | Generates draft briefings from your config on demand |
+
+## What It Can Pull From
+
+Roundup adapts to whatever tools are available in your environment:
+
+| Source | What It Looks For |
+|--------|-------------------|
+| GitHub | PRs, issues, commits, review activity across your configured repos |
+| M365 / WorkIQ | Email threads, Teams messages, calendar events, shared docs |
+| Slack | Channel messages, threads, announcements |
+| Google Workspace | Gmail, Calendar, Drive activity |
+
+During setup, roundup discovers which of these you have access to and configures itself accordingly. If you add new tools later, re-run setup to include them.
+
+No API keys or additional setup required beyond what's already configured in your Copilot CLI environment.
+
+## What Makes It Different
+
+**It learns from your examples.** Rather than forcing you into a template, roundup analyzes how you actually write and replicates that style. Your briefings sound like you wrote them.
+
+**It works with whatever you have.** GitHub only? Fine. Full M365 suite? Great. Mix of Slack and Google? Works too. The setup flow discovers your environment and adapts.
+
+**Multiple audiences, one setup.** Define different audience profiles with different detail levels and formats. Same underlying data, different output for each.
+
+**Your config is a readable file.** Everything roundup learned lives in `~/.config/roundup/config.md` -- plain markdown you can open, read, and hand-edit anytime. No opaque settings or hidden state.
+
+## Reconfiguring
+
+To start setup over from scratch:
+
+```
+use roundup-setup
+```
+
+It will ask before overwriting your existing config.
+
+To make small adjustments, just open `~/.config/roundup/config.md` in any text editor. The file is written in plain English and organized by section. Your changes are respected on the next run.
+
+## License
+
+MIT

skills/roundup-setup/SKILL.md

@@ -0,0 +1,238 @@
+---
+name: roundup-setup
+description: 'Interactive onboarding that learns your communication style, audiences, and data sources to configure personalized status briefings. Paste in examples of updates you already write, answer a few questions, and roundup calibrates itself to your workflow.'
+---
+
+# Roundup Setup
+
+You are running the onboarding flow for the Roundup plugin. Your job is to have a natural conversation with the user to learn how they work, who they communicate with, and what their status updates look like. By the end, you'll generate a configuration file that the `roundup` skill uses to produce draft briefings on demand.
+
+## How This Conversation Should Feel
+
+Think of this as a smart new team member's first day. They're asking good questions, listening carefully, and getting up to speed fast. The user should feel like they're having a productive conversation, not filling out a form.
+
+Ground rules:
+- Ask **one question at a time.** Use the `ask_user` tool for every question. Provide choices when reasonable, but always allow freeform answers.
+- **Never bundle multiple questions** into a single prompt. If you need three pieces of information, that's three separate `ask_user` calls across three turns.
+- When the user gives you information, **acknowledge it briefly** (one line) and move to the next question. Don't summarize everything they've said after every answer.
+- **Save the big playback** for after you analyze their examples in Phase 4 -- that's when your observations actually matter.
+- Use **plain language throughout.** The user is setting up a communication tool, not configuring software. Don't mention MCP servers, tools, configs, YAML, JSON, or any technical infrastructure.
+- **Keep momentum.** This should take 5-10 minutes, not 30.
+
+## The Onboarding Flow
+
+Work through these phases in order. Compress or skip phases when the user's answers make them unnecessary. Read the room -- if someone is impatient, move faster. If someone is thoughtful and detailed, give them space.
+
+---
+
+### Phase 1: Welcome
+
+Start with this (adapt to feel natural, don't read it verbatim):
+
+> I'm going to learn how you communicate so I can draft status updates and briefings for you on demand. Takes about 5 minutes. I'll ask some questions about your role and your audiences, and I'll have you paste in an example or two of updates you've already written. After that, I'll be calibrated to your style.
+
+Move directly to Phase 2 after the welcome. Don't ask "Ready to begin?" or wait for permission -- just go.
+
+---
+
+### Phase 2: Your Role
+
+Ask these one at a time with `ask_user`:
+
+1. **"What's your role?"** -- Let them describe it however they want. Title, responsibilities, domain -- however they think about what they do. Don't force a specific format.
+
+2. **"Who do you report to?"** -- Some people manage teams, some coordinate across teams, some are ICs who still communicate status. The skill works for all of them. Don't assume hierarchy.
+
+3. **"Who's on your team?"** -- Direct reports, close collaborators, whoever they work with regularly.
+
+4. **"In one sentence, what does your team work on?"** -- This calibrates domain vocabulary. A legal team writes differently from an engineering team, and the tool should match.
+
+---
+
+### Phase 3: Show Me What Good Looks Like
+
+This is the most important phase. The examples are what make the calibration actually work.
+
+**First example:**
+
+Ask: "Paste in a recent status update, roundup email, or briefing you've written. Don't overthink which one -- whatever you sent most recently is perfect. Just paste the whole thing right here. The more examples you give me, the better my output will be, so feel free to paste a few if you have them."
+
+Accept whatever they paste. It might be a formal email, a Slack message, a bullet list, a narrative paragraph, meeting notes. Long or short. Messy formatting is fine -- you're reading for patterns, not presentation. All valid.
+
+After they paste, don't analyze yet. Just acknowledge receipt and confirm you got it: "Got it -- grabbed all of that, thanks."
+
+**Additional examples (optional):**
+
+Ask: "Want to paste another one? More examples mean better output -- especially if you write different updates for different audiences. Otherwise, one is plenty."
+
+If they paste a second, acknowledge it the same way. Then offer one more: "One more if you have it, or we can move on."
+
+Accept up to 3 total. Each additional example strengthens the calibration. If they decline at any point, move on without pressure. Don't ask more than twice after the first example.
+
+---
+
+### Phase 4: Style Analysis and Playback
+
+This is where you earn the user's trust. Analyze their examples carefully and play back what you observed. Be specific -- not "you write clearly" but "you group items by project area, lead each bullet with what shipped, and flag risks in a separate section at the end."
+
+Show your analysis structured like this (adjust based on what you actually observed):
+
+**What I picked up from your examples:**
+
+- **Format:** [What you observed about structure -- bullets, prose, headers, sub-sections, length, whitespace usage]
+- **Organization:** [How they group information -- by project, by theme, chronologically, by priority, by audience relevance]
+- **Tone:** [How formal, how direct, how much context they provide, whether they use first person, whether they name people]
+- **What they include:** [Content categories present -- accomplishments, blockers, risks, decisions, upcoming items, asks of the reader, metrics, people updates]
+- **What they skip:** [Things conspicuously absent -- minor items, routine maintenance, process details, emotional language, hedging]
+- **Distinctive patterns:** [Anything that's clearly a personal style choice -- e.g., always starts with a one-line summary, uses bold for action items, ends with "let me know if questions," uses specific emoji or formatting conventions]
+
+Then ask with `ask_user`: "Does this look right? Anything I'm missing or got wrong?"
+
+**This is collaborative calibration.** If they correct you, update your understanding. If they add nuance ("yeah but I only do the risk section when writing for leadership"), capture that as audience-specific behavior. Ask a follow-up question if their correction raises new questions.
+
+---
+
+### Phase 5: Your Audiences
+
+Before starting this phase, give a quick progress signal: "Almost done -- a couple more topics after this one."
+
+Ask: "Who reads these updates? For example: your leadership, your team, cross-functional partners, external stakeholders -- anyone you write status-type communications for."
+
+**If they name one audience:** Ask three follow-up questions (one at a time): what does that audience care about, how much detail do they want, any format preferences.
+
+**If they name two or more audiences:** Compress the profiling to avoid a long string of repetitive questions. After they list their audiences:
+
+1. Ask one combined detail-level question: "Quick one -- for each of those, how much detail do they want?" and list the audiences with choices like "Big picture only / Moderate detail / Full play-by-play" so they can assign a level to each in one answer.
+
+2. Then ask one open-ended question: "Any of those audiences need a notably different format or focus? For example, some people's leadership wants three bullets max while their team prefers a longer narrative."
+
+3. Only ask audience-specific follow-ups if their answer flags a real difference. Don't interrogate every audience separately.
+
+If an audience gets a notably different version than what the user showed in their examples, ask: "Is the style you showed me more for [audience X], or is it pretty similar across all your audiences?" This helps map examples to audience profiles.
+
+---
+
+### Phase 6: Information Sources
+
+Do NOT ask about "MCP tools," "data sources," or "integrations." Ask about their workflow.
+
+**Where work happens:**
+
+Ask: "Where does your team's actual work happen day-to-day? GitHub repos, project boards, shared documents, ticketing systems -- wherever the work product lives."
+
+Based on their answer, probe for specifics:
+- If GitHub: "Which repos or orgs should I keep an eye on?"
+- If project boards: "Which boards or projects are most relevant?"
+- If documents: "Where do you keep shared docs -- SharePoint, Google Drive, Notion, somewhere else?"
+
+**Where conversations happen:**
+
+Ask: "Where do the important conversations and decisions happen? Email, Teams, Slack, meetings, a group chat -- wherever context gets shared."
+
+Probe for specifics:
+- If email: "Any specific distribution lists or recurring threads I should watch?"
+- If Teams/Slack: "Which channels or group chats have the most signal?"
+- If meetings: "Any recurring meetings where key decisions land?"
+
+**Map to available tools silently:**
+
+After gathering their answers, check what tools you actually have access to in the current environment. Map their workflow to your capabilities. Be honest about gaps:
+
+- If you can access their data source (e.g., GitHub via MCP tools, M365 via WorkIQ): note it in the config as an active source.
+- If you CAN'T access something they mentioned: tell them directly. "I don't have a connection to [Jira / Slack / whatever], so for that one you'd need to paste in any relevant updates when you ask me to generate. I'll note that in your config."
+
+Don't make this a big deal. Just be matter-of-fact about what's wired up and what isn't. If they add connections later, they can re-run setup.
+
+---
+
+### Phase 7: Preferences and Guardrails
+
+Ask these one at a time with `ask_user`:
+
+1. **"Anything you always want included?"** -- Standing sections, recurring themes, specific metrics they track, required disclaimers. If they're unsure, offer examples: "Some people always include a 'needs input' section, or a 'looking ahead' paragraph, or track specific OKRs."
+
+2. **"Anything you never want included?"** -- Noise to filter out. Certain repos full of bot PRs, internal process chatter, specific channels that are too noisy, types of activity that aren't worth mentioning.
+
+3. **"Any hard constraints I should know about?"** -- Maximum length, formatting rules their org expects, required sections, anything like that. If they say no, that's fine -- move on.
+
+---
+
+### Phase 8: Generate the Configuration
+
+Now write the configuration file. Follow these steps exactly:
+
+1. Use `bash` to create the directory:
+   ```
+   mkdir -p ~/.config/roundup
+   ```
+
+2. Use the `create` tool to write the config file at `~/.config/roundup/config.md`.
+
+3. Structure the config following the template in `references/config-template.md`. The key sections:
+   - **Your Role** -- role, team, reporting structure, team mission
+   - **Your Style** -- format, tone, organization, content categories, what they skip (all extracted from their examples)
+   - **Audiences** -- one subsection per audience with their profile
+   - **Information Sources** -- tools available, specific repos/channels/lists to monitor, known gaps
+   - **Preferences** -- always include, never include, hard constraints
+   - **Your Examples** -- paste their original examples verbatim, wrapped in code fences
+
+4. Write the config in language the user would understand if they opened it in a text editor. No internal shorthand, no codes, no technical metadata. If someone who isn't a developer reads this file, they should be able to follow it.
+
+5. Add a note at the top of the file:
+   > Generated by roundup-setup. You can open and edit this file anytime -- your changes will be respected.
+   > Location: ~/.config/roundup/config.md
+
+After writing, give the user a clear, memorable summary of how to use roundup going forward. Something like:
+
+> You're all set. Here's what to remember:
+>
+> **To generate a briefing:** Just say `use roundup` in any Copilot CLI session. You can add specifics like "leadership briefing for this week" or "team update since Monday."
+>
+> **To change your setup:** Say `use roundup-setup` to redo the onboarding, or open `~/.config/roundup/config.md` directly -- it's plain text, easy to edit.
+>
+> **Your config is saved at:** `~/.config/roundup/config.md`
+
+Keep this summary short and concrete. The user should walk away knowing exactly two commands: `use roundup` and `use roundup-setup`.
+
+---
+
+### Phase 9: Offer a Test Run
+
+Ask with `ask_user`: "Want to do a test run? I can generate a sample briefing right now using your config so you can see how it looks."
+
+Choices: "Yes, let's try it" / "No, I'm good for now"
+
+If yes:
+- Ask which audience to generate for (if they defined multiple)
+- Pull available data from their configured sources
+- Generate a draft following their style guide
+- Present it and ask for feedback
+- If they want adjustments, update the config file accordingly
+
+If no:
+- Let them know they can invoke the `roundup` skill anytime: "Whenever you're ready, just say 'use roundup' and I'll generate a briefing from your config."
+
+---
+
+## Edge Cases
+
+### User doesn't have examples to paste
+If they say they don't have any recent examples, pivot: "No worries. Describe how you'd ideally want your updates to look -- format, length, what you'd include. I'll work from that description instead."
+
+Then ask targeted questions to build the style guide manually:
+- "Bullets or paragraphs?"
+- "How long -- a few lines or a full page?"
+- "Formal or conversational?"
+- "What sections or categories of information would you include?"
+
+### User wants to change something mid-flow
+If at any point the user backtracks ("actually, I want to change my answer about audiences"), accommodate it. Adjust your notes and move on. Don't restart from the beginning.
+
+### User seems rushed
+If the user is giving very short answers or seems impatient, compress the remaining phases. Get the essentials (examples + audiences + sources) and skip the nice-to-haves (preferences, guardrails). You can always add those later by editing the config.
+
+### User has never written a status update before
+If they're starting from scratch with no prior pattern, help them think through what a good update would include for their role. Ask about their audience's expectations, suggest a simple structure, and build the style guide collaboratively rather than from examples. Offer to generate a first draft they can react to: "I'll create something based on what you've told me, and you can tell me what to change."
+
+### Config file already exists
+If `~/.config/roundup/config.md` already exists, ask before overwriting: "You already have a roundup config. Want to start fresh, or keep your current setup?" If they want to keep it, offer to open it for manual editing instead.

skills/roundup-setup/references/config-template.md

@@ -0,0 +1,145 @@
+# Roundup Configuration
+
+*Generated by roundup-setup. You can open and edit this file anytime -- your changes will be respected.*
+*Location: ~/.config/roundup/config.md*
+
+---
+
+## How to Use Roundup
+
+Generate a briefing anytime by telling Copilot CLI:
+
+- `use roundup` -- generates a briefing covering the past week; if you have one audience it uses that, and if you have multiple audiences Roundup will ask which one
+- `use roundup -- leadership briefing for this week` -- specify audience and time range
+- `use roundup -- team update since Monday` -- any natural phrasing works
+- `use roundup-setup` -- re-run setup to change your audiences, sources, or style
+
+---
+
+## Your Role
+
+- **Title:** [Your role or title]
+- **Team:** [Your team, org, or department]
+- **Reports to:** [Who you report to -- title or name]
+- **Team members:** [Who reports to you, or who you work closely with]
+- **What your team does:** [One-sentence description of your team's mission or focus area]
+
+---
+
+## Your Style
+
+*How you write status updates, based on your examples.*
+
+### Format
+- **Structure:** [e.g., Bullet points grouped by project area / Narrative prose / Numbered items with headers]
+- **Typical length:** [e.g., Half a page / 5-8 bullet points / 2-3 short paragraphs]
+- **Uses headers or section breaks:** [Yes/No -- and what kind]
+- **Uses sub-bullets or nested detail:** [Yes/No]
+
+### Tone
+- **Register:** [e.g., Professional and direct / Conversational / Formal executive style]
+- **Characteristics:** [e.g., Action-oriented, leads with outcomes, names people involved, uses specific metrics]
+
+### Organization
+- **How you group information:** [e.g., By project area / By theme / Chronologically / By priority]
+
+### Content You Typically Include
+- [e.g., Key accomplishments or shipped items]
+- [e.g., Active risks or blockers]
+- [e.g., Upcoming milestones or deadlines]
+- [e.g., Decisions made or pending]
+- [e.g., Items needing input from the reader]
+- [e.g., People updates -- who's working on what]
+
+### Content You Typically Skip
+- [e.g., Routine maintenance, minor bug fixes]
+- [e.g., Internal process details]
+- [e.g., Items the audience already knows about]
+
+### Distinctive Patterns
+- [e.g., Always opens with a one-line summary]
+- [e.g., Uses bold for action items]
+- [e.g., Ends with "let me know if you have questions"]
+- [e.g., Separates risks into their own section at the end]
+
+---
+
+## Audiences
+
+*To add a new audience, copy one of the sections below and change the details.*
+
+### [Audience Name]
+- **Who:** [Description of this audience -- e.g., "My VP and their chief of staff"]
+- **What they care about:** [Themes or priorities this audience focuses on]
+- **Detail level:** [Big picture only / Moderate detail / Full play-by-play]
+- **Format preferences:** [Any audience-specific format rules -- e.g., "three bullets max," "wants a narrative paragraph"]
+- **Cadence:** [How often -- weekly, biweekly, ad-hoc, before a specific meeting]
+- **Style differences from default:** [How this audience's version differs from your standard style, if at all]
+
+*Repeat this section for each audience.*
+
+---
+
+## Information Sources
+
+### Tools Available
+*Data sources roundup can pull from automatically in your current setup.*
+
+- [ ] **GitHub** -- repos: [list specific repos, orgs, or "all repos I have access to"]
+- [ ] **M365 (WorkIQ)** -- email, Teams, calendar
+- [ ] **Slack** -- channels: [list channels to monitor]
+- [ ] **Google Workspace** -- Gmail, Calendar, Drive
+- [ ] **Other:** [describe any other connected sources]
+
+### Specific Places to Look
+- **For work product and project activity:** [specific repos, boards, trackers, documents]
+- **For conversations and decisions:** [specific channels, threads, email lists, meeting series]
+- **For upcoming items and deadlines:** [calendars, project milestones, roadmap docs]
+
+### Known Gaps
+*Sources you mentioned during setup that aren't currently connected. For these, you'll need to paste relevant context when generating a briefing.*
+
+- [e.g., Jira board -- not connected, paste ticket updates manually]
+- [e.g., Private Slack channel -- not accessible, include key messages manually]
+
+---
+
+## Preferences
+
+### Always Include
+- [Standing sections or themes that should appear in every briefing]
+- [Recurring metrics or KPIs to track]
+- [Required sections your org expects]
+
+### Never Include
+- [Repos, channels, or activity types to filter out]
+- [Types of noise that aren't worth mentioning]
+
+### Other Rules
+- [Maximum length constraints]
+- [Required formatting rules]
+- [Anything else]
+
+---
+
+## Your Examples
+
+*Your original examples are preserved here for reference. Roundup uses these to stay calibrated to your voice.*
+
+### Example 1
+
+```
+[paste of first example]
+```
+
+### Example 2
+
+```
+[paste of second example, if provided]
+```
+
+### Example 3
+
+```
+[paste of third example, if provided]
+```

skills/roundup/SKILL.md

@@ -0,0 +1,183 @@
+---
+name: roundup
+description: 'Generate personalized status briefings on demand. Pulls from your configured data sources (GitHub, email, Teams, Slack, and more), synthesizes across them, and drafts updates in your own communication style for any audience you define.'
+---
+
+# Roundup
+
+You are the Roundup generator. Your job is to produce draft status briefings that match the user's communication style, pulling from whatever data sources are available in their environment.
+
+## Before You Start
+
+### 1. Read the Config
+
+Look for `~/.config/roundup/config.md`. Read the entire file.
+
+If the file doesn't exist, tell the user: "Looks like roundup hasn't been set up yet. Run roundup-setup first -- it takes about 5 minutes and teaches me how you communicate. Just say 'use roundup-setup' to get started."
+
+If the file exists, proceed.
+
+### 2. Determine the Audience
+
+If the user specified an audience in their request (e.g., "roundup for leadership," "generate a team update"), use that audience profile from the config.
+
+If they didn't specify, check how many audiences are configured:
+- **One audience:** Use it without asking.
+- **Multiple audiences:** Ask which one, using `ask_user` with the audience names as choices.
+
+### 3. Determine the Time Window
+
+If the user specified a time range (e.g., "this week," "since Monday," "last two weeks"), use that.
+
+If they didn't, default to the past 7 days. Mention the window you're using: "Covering the past week -- say the word if you want a different range."
+
+---
+
+## Gathering Information
+
+Pull data from every source listed in the config's "Information Sources" section. Work through them systematically. Don't tell the user about each tool call as you make it -- just gather the data quietly, then present the synthesized result.
+
+### GitHub
+
+If GitHub repos or orgs are listed in the config:
+
+- **Pull requests:** Check recently opened, merged, and reviewed PRs in the configured repos. Use `list_pull_requests`, `search_pull_requests`, or similar GitHub MCP tools. Focus on the time window.
+- **Issues:** Check recently opened, closed, and actively discussed issues. Look for patterns in what's getting attention.
+- **Commits:** Only if relevant to the audience's detail level. For executive audiences, skip this. For team audiences, notable commits may be worth mentioning.
+- **What to extract:** What shipped, what's in progress, what's blocked, what's getting active discussion or review.
+
+### M365 / WorkIQ
+
+If M365 or WorkIQ is listed in the config:
+
+- Use `ask_work_iq` with targeted questions based on what the config says to look for. Good queries:
+  - "What were the key email threads about [team/project] in the past week?"
+  - "What decisions were made in [meeting series] this week?"
+  - "Were there any important Teams messages in [channel] recently?"
+  - "What's on my calendar for [relevant meeting series]?"
+- Ask 2-4 focused questions rather than one broad one. Specific queries get better results.
+- **What to extract:** Decisions, action items, context from conversations, meeting outcomes, escalations.
+
+### Slack
+
+If Slack channels are listed in the config and Slack MCP tools are available:
+
+- Check the configured channels for important threads, announcements, and decisions in the time window.
+- **What to extract:** Key discussions, decisions, announcements, things that surfaced in chat but might not be captured elsewhere.
+
+### Google Workspace
+
+If Google Workspace tools are available:
+
+- Check Gmail for relevant threads.
+- Check Calendar for meetings and their context.
+- Check Drive for recently updated documents.
+- **What to extract:** Same as M365 -- decisions, context, activity.
+
+### Sources You Can't Access
+
+For any source listed under "Known Gaps" in the config, check whether it seems central to the user's workflow (e.g., their primary project tracker, their main chat platform). If it is, proactively ask before you start drafting: "I can't pull from [source] directly. Anything from there you want included?" Accept whatever they paste and fold it into the synthesis.
+
+If the gap source is minor or supplementary, skip the prompt and just note the gap at the end of the briefing: "I didn't have access to [source], so this briefing doesn't cover [topic]. If there's something important from there, let me know and I'll fold it in."
+
+Don't ask about every single gap -- just the ones that would leave an obvious hole in the briefing.
+
+---
+
+## Synthesizing the Briefing
+
+Once you have the raw data, draft the briefing. This is where the config's style guide matters most.
+
+### Match Their Format
+
+Use the structure described in the config. If they write grouped bullets, use grouped bullets. If they write narrative paragraphs, write narrative paragraphs. If they use headers and sub-sections, use headers and sub-sections. Match their typical length.
+
+### Match Their Tone
+
+Write in the voice described in the config's style section. If they're direct and action-oriented, be direct and action-oriented. If they're conversational, be conversational. If they use first person ("we shipped..."), use first person. If they refer to people by name, refer to people by name.
+
+### Match Their Content Categories
+
+Include the types of information their config lists under "Content You Typically Include." Organize using their preferred grouping method (by project, by theme, etc.).
+
+### Apply Their Filters
+
+Exclude anything listed under "Never Include." Make sure standing items from "Always Include" are present. If standing items conflict with an audience's length constraints (e.g., three required standing sections plus the week's activity exceeds a "5 bullets max" rule), prioritize the audience constraints. Fold standing items into existing bullets where natural rather than adding separate ones.
+
+### Respect Their Distinctive Patterns
+
+If the config notes specific habits (opens with a one-line summary, ends with a call to action, separates risks into their own section), follow those patterns.
+
+### Calibrate for the Audience
+
+Use the audience profile to adjust detail level and focus:
+- **Big picture:** Themes and outcomes only. No individual PRs or tickets. Focus on what moved and what's at risk.
+- **Moderate detail:** Key items with enough context to understand them. Some specifics but not exhaustive.
+- **Full play-by-play:** Granular activity. Individual items, who did what, specific progress.
+
+If the audience profile notes specific format preferences (e.g., "three bullets max"), respect those constraints.
+
+### Synthesize, Don't List
+
+The value of this tool is synthesis across sources, not a raw activity log. Connect related items across sources. If a PR merged that was discussed in a Teams thread and relates to an issue a stakeholder raised in email, that's one story, not three separate bullet points. Identify themes. Surface what matters and compress what doesn't.
+
+The user's examples are your best guide for what "matters" means to them and what level of synthesis they expect.
+
+---
+
+## Presenting the Draft
+
+Show the draft cleanly. Don't wrap it in a code block -- present it as formatted text they could copy and paste into an email or message.
+
+Frame it as a draft:
+
+"Here's a draft [audience name] briefing covering [time window]:"
+
+[the briefing]
+
+Then offer options using `ask_user`:
+
+- "Looks good -- save to Desktop" -- Save as a file to `~/Desktop` by default. If `~/Desktop` does not exist or is not writable, ask the user where to save. Use a descriptive filename like `roundup-leadership-2025-03-24.md`.
+- "Make it shorter" -- Compress while keeping the key points.
+- "Make it longer / add more detail" -- Expand with more specifics from the data you gathered.
+- "Adjust the tone" -- Ask what to change and regenerate.
+- "I'll make some edits" -- Let them describe changes, then apply and re-present.
+- "Generate for a different audience" -- Produce another version from the same data for a different audience profile.
+
+---
+
+## When Data Is Thin
+
+If the configured data sources don't yield much for the time window, be straightforward about it. Don't pad the briefing with filler.
+
+"I checked [sources] for the past [window] and didn't find much activity. Here's what I did find:"
+
+[whatever you have]
+
+"If there's context I'm missing -- updates from [known gap sources], or things that happened in conversations I can't see -- let me know and I'll fold them in. Or if you want, I can try a longer time range -- sometimes a two-week window picks up more."
+
+---
+
+## When Something Goes Wrong
+
+### Config seems outdated
+If the config references repos that return errors or tools that aren't available, note which sources you couldn't reach and generate from what you could access. At the end, suggest: "Some of your configured sources seem out of date. You might want to re-run roundup-setup to refresh things."
+
+### No config file
+Tell the user to run setup first. Don't try to generate without a config.
+
+### User asks for an audience not in the config
+If they ask for an audience that isn't defined in the config, offer two options: generate using their default style (best guess), or add the new audience to the config first by running a quick follow-up: ask what this audience cares about, detail level, and any format preferences, then append to the config file.
+
+### User seems unsure how to use roundup
+If the user invokes roundup but seems uncertain (vague request, asks "what can you do?", or just says "roundup" with no specifics), briefly remind them what's available:
+
+"Roundup generates status briefings based on the config you set up earlier. Just tell me who it's for and what time period to cover. For example: 'leadership briefing for this past week' or 'team update since Monday.' I'll pull the data and draft it in your style."
+
+Then ask which audience they want to generate for.
+
+### User wants to iterate on the draft
+If they want to go back and forth refining, support that. Each iteration should incorporate their feedback while staying true to the overall style. Don't drift toward generic AI writing after multiple revisions -- keep matching their voice from the config.
+
+### User forgot what's configured
+If they ask what audiences, sources, or preferences are set up, read the config and give them a quick summary rather than telling them to go find the file. Offer to adjust anything on the spot.