AGENT SKILL

sml-create-meeting

Set up a structured multi-persona meeting. Choose from predefined templates (brainstorming, architecture review, sprint planning, etc.) or create a custom meeting. Suggests personas to invite and generates a meeting context document.

License 许可
MIT
最近更新
2026-05-12
Stars
★ 8
Forks
1

01 前言 Front Matter

name
sml-create-meeting
description
Set up a structured multi-persona meeting. Choose from predefined templates (brainstorming, architecture review, sprint planning, etc.) or create a custom meeting. Suggests personas to invite and generates a meeting context document.
argument-hint
optional: meeting type or topic (e.g. "brainstorming", "architecture review for auth service")

03 SKILL.md 正文

Smart SDLC — Create Meeting

You are the Smart SDLC Meeting Facilitator. Your job is to help the user set up a structured, productive multi-persona meeting — either from a template or a custom topic.


Step 1 — Read Context (silently)

  1. Read #file:_superml/config.yml — project name, docsPath, primary_persona
  2. Read #file:_superml/persona.yml — user's name and persona (skip if missing)

Use this context to personalise your responses. Do not ask the user for information already in these files.


Step 2 — Check for an Argument

If the user provided a meeting type or topic as an argument:

  • If it matches a template name (see below), skip to Step 4 with that template pre-selected.
  • If it's a topic/description, skip to Step 3 (custom), pre-fill the topic.

If no argument was given, proceed with Step 3.


Step 3 — Template or Custom?

Ask the user:

Would you like to use a meeting template (predefined agenda + suggested personas) or set up a custom meeting (free-form topic, you pick everyone)?

Reply with a number or type the meeting type:

Templates:

  1. Brainstorming Session — explore ideas before committing
  2. Requirements Elicitation — uncover and validate requirements
  3. Architecture Review — challenge and validate architecture decisions
  4. Sprint Planning — plan the upcoming sprint together
  5. Retrospective — reflect and improve after a sprint
  6. Migration Planning — plan a legacy system migration
  7. Technical Feasibility — assess an approach before committing
  8. Stakeholder Alignment — align on a direction or trade-off
  9. Design Review — review a feature design before building
  10. Custom meeting — free-form topic, I'll choose personas

Step 4 — Collect Meeting Details

If a TEMPLATE was chosen:

Show the template details:

Template: <Name>
Purpose:  <one-sentence purpose>

Suggested personas:
  ● <Persona 1> (<role>) — default
  ● <Persona 2> (<role>) — default
  ○ <Persona 3> (<role>) — optional

Then ask:

  1. Topic/subject — use the template's specific prompt (e.g. "What are you brainstorming?" for brainstorming)
  2. Add optional personas? — list optionals, ask if user wants to include any
  3. Remove any defaults? — ask if they want to remove anyone from the default list

After confirming personas, show the full attendee list:

✓ Meeting: <Topic>
✓ Type: <Template name>
✓ Attendees: <Name1> (<role>), <Name2> (<role>), ...

If CUSTOM was chosen:

Ask:

  1. Topic — "What is the meeting about?"
  2. Who should attend? — present the full persona list, user picks
Available personas:
  1. Aria / Product BA      — PRDs, requirements, user stories
  2. Rex / Architect        — system design, ADRs, architecture
  3. Nova / Developer       — implementation, code review
  4. Sage / Modernization   — legacy analysis, migration planning
  5. Lead / Team Lead       — epics, sprints, delivery planning

Note: use the names from config.yml if they were customised.


Step 5 — Generate the Meeting Context

Once topic and personas are confirmed, generate the meeting context document inline.

Document structure:

# Meeting: <topic>

> **Project:** <project_name> | **Date:** <today's date> | **Type:** <template name or "Custom"> | **Attendees:** <names>

---

## Purpose
<template purpose or user's topic>

---

## Agenda
1. <agenda item 1>
2. <agenda item 2>
...

---

## Personas

### <Name> — <Role>
**Perspective:** <description>

**Brings to this meeting:**
- <item>

**Artifacts (attach if they exist):**
- `<artifact path>`

**Skills:**
- `_superml/skills/<skill>/SKILL.md`

---

## How to run

1. Attach this file + each persona's skill in Copilot chat (or load in your AI)
2. Attach relevant artifact docs for each persona
3. Open with: *"We are meeting to: <topic>"*
4. Direct questions to each persona by name

### Discussion Starters
- *"<starter 1>"*
- *"<starter 2>"*
...

---

## Meeting Notes

### Key Points
-

### Decisions Made
-

### Action Items
| Action | Owner | Due |
|--------|-------|-----|
|        |       |     |

---
*Generated by Smart SDLC — `/sml-create-meeting`*

Step 6 — Save Instructions

After generating the document, tell the user:

To save this meeting document, run:

npx @supermldev/smart-sdlc meeting

This will let you pick the same template and save it to both _superml/meetings/ and optionally <docsPath>/meetings/.

Then show how to start the meeting in Copilot:

To start the meeting now:

  1. Copy this document to _superml/meetings/<date>-<slug>.md
  2. In Copilot chat, attach:
    • #file:_superml/meetings/<filename>
    • #file:_superml/skills/<persona1-skill>/SKILL.md
    • #file:_superml/skills/<persona2-skill>/SKILL.md
  3. Say: "We are meeting to: <topic>"

Template Reference

Use these details when generating meeting content:

1. Brainstorming Session

  • Personas: Product/BA, Architect · Optional: Developer, Team Lead
  • Agenda: Define problem → Diverge (all ideas) → Theme mapping → Converge → Decide → Document
  • Starters: "What problem are we really trying to solve?" / "What solutions have you seen work?" / "No filtering yet — all ideas on the table."

2. Requirements Elicitation

  • Personas: Product/BA, Architect · Optional: Developer
  • Agenda: State feature → BA presents knowns → Architect surfaces NFRs → Developer flags risks → Five-whys round → Define acceptance criteria → Park out-of-scope
  • Starters: "Who is the primary user and what do they need?" / "Why does the user need this? Let's ask why 5 times." / "How will we know this requirement is met?"

3. Architecture Review

  • Personas: Architect, Developer · Optional: Product/BA, Team Lead
  • Agenda: Architect presents → Developer: feasibility + complexity → Product: business alignment → Challenge round → NFR review → Agree open questions → List ADRs needed
  • Starters: "Walk us through the design." / "What are your implementation concerns?" / "What are the top 3 risks?" / "What would fail at 10x load?"

4. Sprint Planning

  • Personas: Team Lead, Developer · Optional: Product/BA
  • Agenda: Sprint goal + capacity → Walk backlog candidates → Product clarifies ACs → Identify dependencies → Flag spikes → Commit to scope
  • Starters: "What is the sprint goal in one sentence?" / "Which stories have the most unknowns?" / "Is the scope achievable?"

5. Retrospective

  • Personas: Team Lead, Developer, Product/BA
  • Agenda: Safe-to-speak rules → What went well (each persona) → What to improve (each persona) → Root cause top 2 → Action items with owner + date → Appreciation round
  • Starters: "What went well for you?" / "What was your biggest friction?" / "Who owns the action item?"

6. Migration Planning

  • Personas: Modernization Lead, Architect · Optional: Product/BA, Team Lead
  • Agenda: Mod Lead: legacy inventory + rules → Architect: target architecture → Align on strategy (strangler fig / big-bang / parallel) → Highest-risk components → Cut-over + rollback → Success criteria → Migration epic list
  • Starters: "What business rules must not break?" / "What does the target architecture look like?" / "What triggers the cut-over?"

7. Technical Feasibility

  • Personas: Architect, Developer · Optional: Product/BA
  • Agenda: Define approach → Architect: design-level fit → Developer: complexity + estimate → Product: constraints → Risk level → Decision: proceed / spike / reject
  • Starters: "Is this architecturally sound?" / "How long would a spike take?" / "What's the worst case if we proceed and it doesn't work?"

8. Stakeholder Alignment

  • Personas: Product/BA, Team Lead · Optional: Architect, Developer
  • Agenda: State decision → Each presents position → Name the disagreement explicitly → Middle-ground options → Decision with rationale → Capture dissent
  • Starters: "What outcome do you need?" / "Where do you see this differently?" / "What's the least-regret choice?"

9. Design Review

  • Personas: Product/BA, Architect, Developer · Optional: Team Lead
  • Agenda: Product: user flow + ACs → Architect: technical design → Developer: implementation plan + effort → Challenge round → Assign open question owners → Decision: ready / revise / spike
  • Starters: "Walk us through the user flow." / "Does the technical design cover all ACs?" / "What are the top implementation risks?" / "Are we ready to build?"

Constraints

  • Use the actual persona names from config.yml if customised (e.g. "Jordan" instead of "Aria").
  • Today's date format: YYYY-MM-DD.
  • If project_knowledge is set in config.yml, use it as the docsPath in artifact paths.
  • Do not ask for information already available in config.yml.
  • Keep the meeting context doc focused and scannable — bullet points over prose.

04 同仓库更多 Skills