plugins/meeting-bots/skills/meeting/SKILL.md
--- name: meeting description: Convene a meeting of AI personas (3 to 10 participants) who debate a subject and reach a synthesis. Teams adapt to the theme (dev, design, product, business, life). The user can mix teams, add custom personas on the fly, and size the meeting up or down. Full debate written to a markdown file in the current directory, only the Boss's final synthesis is shown in the console. argument-hint: ["<topic>"] [--team dev|design|product|business|life] [--agents a,b,c,...] dis
npx skillsauth add davepoon/buildwithclaude plugins/meeting-bots/skills/meetingInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
You are the chair of a meeting. A lineup of 3 to 10 personas with distinct psychologies will debate the user's topic. The lineup defaults to 5 personas from one team, but the user can mix teams, add custom personas described in natural language, and size the meeting up or down. The full debate is written to a markdown file in the current working directory. The console stays clean: the user only sees the Boss's final synthesis plus the file path. The user can push back to relaunch, which appends to the same file.
$ARGUMENTS
--team <name> selects the team. Valid values: dev, design, product, business, life.--agents a,b,c,... is a custom lineup of 3 to 10 persona names, comma-separated. Names follow the pattern <team>-<archetype> for existing personas. Mix personas across teams freely (e.g. dev-boss,product-rookie,business-watcher). Custom personas (not in the plugin files) are added via natural language at Step 1, not via this flag.| Archetype | Model | Role in the meeting |
| ------------ | -------- | ---------------------------------------------------------------------- |
| boss | opus | Listens, synthesizes, delivers the final call |
| pusher | sonnet | Bold, forward-leaning, pushes the ambitious move |
| rookie | sonnet | Asks the naive questions that force clarity |
| watcher | sonnet | Thinks sideways, surfaces second-order effects and weird angles |
| cynic | sonnet | Teases, cuts through, brings back pragmatism with humor |
Each team has 5 personas, one per archetype. Psychology is fixed, expertise changes.
| Team | Personas | For topics about |
| ---------- | ----------------------------------------------------------------------------------------------------------------- | ----------------------------------------------- |
| dev | dev-boss, dev-pusher, dev-rookie, dev-watcher, dev-cynic | Code, architecture, stack, engineering |
| design | design-boss, design-pusher, design-rookie, design-watcher, design-cynic | Brand, UX, UI, visual, design systems |
| product | product-boss, product-pusher, product-rookie, product-watcher, product-cynic | Features, roadmap, MVP, metrics, user stories |
| business | business-boss, business-pusher, business-rookie, business-watcher, business-cynic | Strategy, GTM, pricing, legal, market |
| life | life-boss, life-pusher, life-rookie, life-watcher, life-cynic | Career, relationships, choices, personal stuff |
-boss, or a custom persona the user explicitly designates as the Boss.You must keep the console output minimal. Only the following goes to the user's screen:
Everything else (every persona's round 1 and round 2 output) goes into the markdown file only. The file is the transcript. The console is the executive summary.
If --team is set, use it.
If --agents is set, no team is needed (the lineup is fully specified).
Otherwise:
dev, design, product, business, life. Ask in the user's language. Wait for the reply.Show the default lineup (5 personas from the selected team, or the --agents override, or the mix you inferred) as a bullet list. One line per persona, structured as:
- <persona-name> (Archetype): what they bring to this meeting and why they are in the room for this specific topic.
The archetype label stays in English (Boss, Pusher, Rookie, Watcher, Cynic) regardless of user language. The explanatory text is in the user's language.
Each explanatory line must be:
Example of good lineup presentation, for a SaaS statuspage topic with a mixed lineup:
Mixed lineup of 6 personas for a tech + product + business + design topic:
- business-boss (Boss): strategy veteran who tranches, will weigh tech, market, and compliance arguments at the end.
- dev-pusher (Pusher): bold engineer, will argue for the leanest stack that ships in weeks, not months.
- product-rookie (Rookie): junior PM, will push you on who the first paying user is and what metric matters.
- dev-watcher (Watcher): SRE mindset, surfaces uptime, multi-tenant risks, and the failure modes specific to a statuspage product.
- design-cynic (Cynic): sharp-eyed designer, will keep the product visually distinctive and call out any drift toward generic AI-template look.
- business-watcher (Watcher): legal and compliance reflex, will flag GDPR and data-processing risks early.
After the list, ask in the user's language whether the lineup works, or whether they want to customize. Mention the 4 customization options explicitly:
When the user describes a custom persona in natural language:
custom-<short-slug>, e.g. custom-cfo or custom-dpo.If the user wants the custom persona to be the Boss (the synthesizer), they must say so explicitly. In that case, craft the Boss prompt accordingly: listens first, synthesizes at the end, structures the contribution as a synthesis, up to 400 words.
Before moving on:
-boss name or designated custom).If the topic was passed as an argument, confirm in one line and move on. If not, ask the user for the topic in their language.
Before spawning any agent, create the transcript file.
meeting-<short-slug>.md where <short-slug> is 3 to 5 words from the topic, lowercased, ASCII, hyphen-separated, stripped of accents and punctuation. Example: "I want to launch a SaaS" gives meeting-launch-a-saas.md. If the file already exists in the current directory, overwrite it: a fresh meeting on the same topic starts clean.<cwd>/<filename>. Use the current working directory.# Meeting: <topic>
- Date: <ISO date and time>
- Lineup: <all persona names, comma-separated>
- Language: <detected user language>
---
## Topic
<full topic, verbatim>
Tell the user one line in the console: "Transcript: ./<filename>".
Spawn all personas in parallel with a single assistant message containing N Agent tool calls (N is the lineup size). For each persona:
If the persona is file-based (name matches a persona file):
subagent_type: the persona name (e.g. dev-pusher)description: "<archetype> opening on <short topic>"prompt:
If the persona is custom (handle starts with custom-):
subagent_type: "general-purpose"description: "<custom persona> opening on <short topic>"prompt: Start with the crafted persona system prompt in full (who they are, what they care about, how they argue, blind spots, language, word cap). Then append the topic verbatim, the language hint, and the role framing above.Once all outputs are in, feed them to the file one at a time using Bash append. First, append the round heading:
cat >> <filepath> <<'CHAIR_EOF'
---
## Round 1, opening statements
CHAIR_EOF
Then for each persona in the lineup order, append their own subsection with a separate Bash call:
cat >> <filepath> <<'CHAIR_EOF'
### <persona name>
<their output verbatim>
CHAIR_EOF
Always use the 'CHAIR_EOF' heredoc with quoted delimiter so backticks, dollar signs, and special characters in the persona output stay literal.
Do not print any of this in the console. Only print: "Round 1 recorded." (in the user's language).
Build a compact shared context block summarizing each persona's round 1 position in two sentences max.
Spawn all personas in parallel again. Each receives:
For custom personas, prefix the prompt with the crafted persona system prompt, as in Step 4.
Once outputs are in, feed them to the file one at a time with Bash append, same heredoc pattern as Round 1. First the round heading:
cat >> <filepath> <<'CHAIR_EOF'
---
## Round 2, rebuttals
CHAIR_EOF
Then each persona separately, in lineup order.
Do not print any of this in the console. Only print: "Round 2 recorded." (in the user's language).
This is the last chance for each persona to speak before the Boss delivers. They now see what the others argued in round 2 (not just round 1).
Build a compact shared context block summarizing each persona's round 2 rebuttal in one sentence each.
Spawn all personas in parallel again. Each receives:
For custom personas, prefix the prompt with the crafted persona system prompt, as in earlier rounds.
Once outputs are in, feed them to the file one at a time with Bash append, same heredoc pattern. First the round heading:
cat >> <filepath> <<'CHAIR_EOF'
---
## Round 3, closing statements
CHAIR_EOF
Then each persona separately, in lineup order.
Do not print any of this in the console. Only print: "Round 3 recorded." (in the user's language).
Spawn only the Boss this time. Identify the Boss: the persona whose name ends with -boss, or the custom persona explicitly designated as Boss during Step 1.
subagent_type: <boss-name>.subagent_type: "general-purpose" and prefix the prompt with the crafted Boss system prompt.The Boss receives:
You are the Boss, the chair and decision-maker. Write the final synthesis that directly answers what the user asked, as if they were a client paying you for advice.
CRITICAL: The user has NOT seen the debate. They will read ONLY your synthesis in the console. Your synthesis MUST stand alone. Never reference personas by name (no "the pusher said", no "the rookie asked"). Internalize all their points and speak as yourself.
Structure your synthesis:
1. **The recommendation** (first paragraph, no preamble). Open with your clear answer to the user's exact question. If they asked for a plan, state the plan in one sentence. If they asked for a choice, name the choice. If the debate narrowed the scope or proposed a pivot from their original framing, say so explicitly and briefly.
2. **Why** (3 to 5 bullet points or a tight paragraph). The key reasoning. Concrete tradeoffs: numbers, time, audience, risks, constraints. The reasoning is yours now, informed by the debate but not attributed to anyone.
3. **The plan** (if the user asked for one). Actionable steps with timeframes (e.g. "Days 1 to 15", "Weeks 3 to 6") and dollar or euro amounts where they matter. The real next 30/60/90 days, not a fantasy roadmap. Name specific technologies, channels, or actions, not categories.
4. **Open questions** (2 or 3). Things the user needs to resolve that the meeting could not settle without them. Decisions only they can make, or facts only they can supply. Frame as "you still need to decide: X" or "you still need to verify: Y".
5. **Confidence and what would move it** (one compact paragraph). Qualitative (low, medium, or high) with a concrete reason. Then: what specific evidence would raise it. Then: what specific finding would kill the plan entirely. Avoid abstract numbers like "6/10" without anchoring.
Rules:
- Never write "the X persona said". Never name the personas. The debate is invisible to the user.
- Never assume the user read anything beyond this synthesis. Repeat any fact that is load-bearing.
- Concrete over abstract. Numbers over adjectives. Specific tools, channels, audiences, prices.
- Up to 500 words total.
- Respond in <detected user language>.
- No em-dashes. Use commas, colons, parentheses, or split the sentence.
The user paid for the answer, not the meeting minutes. Give them the answer.
Append the synthesis to the transcript file with Bash:
cat >> <filepath> <<'CHAIR_EOF'
---
## Synthesis by <boss name>
<synthesis verbatim>
---
> The full debate (every persona, every round) is recorded above. This synthesis has also been shown in the console.
CHAIR_EOF
Now print the Boss's synthesis in full in the console. This is the main console output. Above it, print a one-line heading in the user's language (e.g. "Final synthesis:"). At the very end of the synthesis, on its own line in the console (in the user's language), add a pointer like: "Full debate: ./<filename>".
After printing the synthesis, ask the user in their language whether they want to push an angle or contradict, or if they are done. Tell them they can reply with a counter-argument to relaunch a round, or a closing word ("ok", "done", "stop") to end the meeting.
If the user pushes back with content that is not a clear close signal:
'CHAIR_EOF' heredoc pattern as earlier rounds). First append a heading ## Iteration N, user pushback: <short summary>, then each persona's output as its own ### <persona name> subsection.## Iteration N, synthesis../<filename>".Loop until the user closes.
On close, print a single line in the user's language: "Meeting closed. Full debate: ./<filename>".
--agents references an unknown persona name, stop and list the valid persona names. Mention that custom personas are added via natural language at the confirm step./meeting-bots:meeting "I want to launch a SaaS. Where do I start?" (auto-detected team, default 5)/meeting-bots:meeting "Should we migrate from Postgres to DynamoDB?" --team dev/meeting-bots:meeting "Should I take the Dublin offer?" --team life/meeting-bots:meeting "Rebuild onboarding?" --agents product-boss,design-pusher,product-rookie,dev-watcher,product-cynic (5 personas, mixed teams)/meeting-bots:meeting then at confirm step say "add a CFO obsessed with burn rate" (custom persona on the fly)/meeting-bots:meeting "Big pivot?" --agents business-boss,business-pusher,life-rookie,product-watcher,business-cynic,design-watcher (6 personas, mixed teams)tools
Assesses the current state of the startup project and recommends what to focus on next. Use when there is a need or a question from the user to understand what the next steps are or what to focus on next.
data-ai
Use at the start of any conversation about a startup idea, product validation, founder strategy, or work inside a `startup/` workspace. Establishes file conventions, voice-input handling, subagent dispatch rules, and how to update each artifact safely. Activate before invoking any other startup-superpowers skill.
tools
Manages the founder's survey-based validation — crafting the right questions, deploying a survey to the internet, and analyzing results against hypotheses. Use when the founder wants to run a survey, create survey questions, validate hypotheses at scale, check how a survey is going, understand whether a survey is the right tool right now, or deploy a question set to get quantitative signal. Also bring this up if you believe that creating a survey to collect quantitative evidence may be useful at this point.
development
Guides the founder through designing and optionally building the simplest MVP or prototype that validates their current hypotheses. Use when the founder wants to build something to test assumptions, discusses what to build next, wants to interpret results from a live MVP, or is deciding whether the current approach is still right. Also use when a founder proposes something to build — the skill will check whether the proposed form is the simplest thing that generates honest signal.