Roundup Setup

Roundup setup

Run the Roundup onboarding conversation, turn the user's role, examples, audiences, sources, and guardrails into ~/.config/roundup/config.md, and finish with clear instructions for using roundup and roundup-setup.

When to invoke

• "Set up roundup for my status updates."
• "Calibrate roundup to my writing style."
• "Configure personalized briefings for my team."
• "I want GitHub Copilot to learn how my updates should sound."
• "Change how this conversation should feel."

Prerequisites and context

• Use ask_user for every onboarding question when that tool is available; ask one question per turn.
• Save the final configuration at ~/.config/roundup/config.md after creating ~/.config/roundup with mkdir -p ~/.config/roundup.
• Use references/config-template.md as the configuration structure.
• Do not mention MCP servers, tools, configs, YAML, JSON, or internal infrastructure during conversational intake.
• If ~/.config/roundup/config.md already exists, ask whether to start fresh or keep the current setup before overwriting.

Conversation style

Treat onboarding like a smart new team member getting up to speed, not a form. Keep the flow natural and finish in 5-10 minutes when possible.

Procedure

1. Welcome the user by explaining that setup learns their role, audiences, and examples so Roundup can draft status updates and briefings on demand. Do not ask "Ready to begin?"; move directly to role questions.
2. Ask role questions one at a time: "What's your role?", "Who do you report to?", "Who's on your team?", and "In one sentence, what does your team work on?"
3. Ask for one recent status update, roundup email, briefing, Slack message, bullet list, narrative paragraph, meeting note, or similar example. Accept messy formatting and acknowledge: "Got it -- grabbed all of that, thanks."
4. Offer up to two more examples: "Want to paste another one?" and then "One more if you have it, or we can move on." Stop at three total examples.
5. Analyze examples and play back: Format, Organization, Tone, What they include, What they skip, and Distinctive patterns. Ask: "Does this look right? Anything I'm missing or got wrong?" Capture corrections as audience-specific behavior when needed.
6. Ask who reads the updates. For one audience, ask what they care about, how much detail they want, and format preferences. For multiple audiences, ask one detail-level mapping question and one differences question; only add audience-specific follow-ups for real differences.
7. Ask where work happens day-to-day and probe specifics: GitHub repos or orgs, project boards, SharePoint, Google Drive, Notion, ticketing systems, or shared documents.
8. Ask where important conversations and decisions happen and probe specifics: email distribution lists, recurring threads, Teams or Slack channels, group chats, and recurring meetings.
9. Map sources to available tools silently. If a source is unavailable, say plainly that the user will need to paste relevant updates for that source and note the gap in the config.
10. Ask preferences and guardrails one at a time: always include, never include, and hard constraints such as maximum length, required sections, metrics, OKRs, disclaimers, or noisy sources.
11. Create ~/.config/roundup/config.md from references/config-template.md with sections for Your Role, Your Style, Audiences, Information Sources, Preferences, and Your Examples. Paste original examples verbatim inside code fences.
12. Add this note at the top: "Generated by roundup-setup. You can open and edit this file anytime -- your changes will be respected." and "Location: ~/.config/roundup/config.md".
13. Summarize usage: say use roundup to generate a briefing, optionally with specifics such as "leadership briefing for this week" or "team update since Monday"; say use roundup-setup or edit ~/.config/roundup/config.md to change setup.
14. Offer a test run. If accepted, ask the audience, pull available configured data, generate a sample briefing, collect feedback, and update the config if needed.

Edge cases

Progressive disclosure and bundled resources

• references/config-template.md: use as the exact structure for ~/.config/roundup/config.md.

Calibration vocabulary

Preserve these Roundup concepts when capturing user preferences: M365, Teams/Slack, bash, create, cross-functional, matter-of-fact, mid-flow, nice-to-haves, one-line, open-ended, play-by-play, re-run, repos/channels/lists, status-type, and sub-sections. Use them only when they describe the user's actual workflow or the setup mechanics.

Output template

### Roundup setup result

**Status:** configured | needs follow-up | blocked
**Config path:** `~/.config/roundup/config.md`

**Captured profile**
- Role: <role>
- Team: <team and mission>
- Audiences: <audience list>
- Sources: <active sources and known gaps>

**Style calibration**
- Format: <observed format>
- Organization: <observed organization>
- Tone: <observed tone>
- Include: <content categories>
- Skip: <filtered content>
- Distinctive patterns: <personal conventions>

**How to use**
- `use roundup` for a briefing.
- `use roundup-setup` or edit `~/.config/roundup/config.md` to change setup.

Quality gate

• Every onboarding question was asked one at a time.
• User examples were collected verbatim or the no-examples fallback was completed.
• The Phase 4 playback covered Format, Organization, Tone, What they include, What they skip, and Distinctive patterns.
• Audiences include detail level and any format or focus differences.
• Information sources identify accessible sources and known gaps without claiming unavailable integrations.
• mkdir -p ~/.config/roundup was run before writing ~/.config/roundup/config.md.
• The config follows references/config-template.md and is written in plain language.
• Existing config was not overwritten without user approval.
• The final response teaches both use roundup and use roundup-setup.