roundup-setup — скилл для GitHub Copilot: настройка

---
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.