# Meeting Orchestrator Final Spec

## Purpose

Provide a native OpenClaw skill that can:

1. Start a multi-role meeting.
2. Let AI suggest the right participants.
3. Ask the user to confirm or adjust the participant list.
4. Run the meeting with one standalone message per speaker turn.
5. Allow human intervention during the run.
6. Run a single-role analysis such as `real_powell` on demand.

## Workflow overview

### Step 1: Topic intake

The user gives the topic and optional background context.

### Step 2: AI role suggestion

The skill suggests a participant list based on the topic and context.

### Step 3: Human confirmation

The user confirms or edits the suggested participant list.

### Step 4: Startup brief

The skill shows:
- topic
- context summary
- suggested roles
- max rounds
- a note that the user can still adjust before execution

### Step 5: Meeting execution

For each round:
- PM decides the next step
- exactly one role speaks in one standalone message
- the response is appended to the shared scratchpad
- the user may interrupt or add context

### Step 6: Final report

When the PM ends the meeting, output:
- the final report
- the participant list
- the transcript

## Topic and background handling

The skill should support large background inputs in four ways:

- direct paste into the context field
- reading from a file or document outside the meeting body
- sectioned background text
- AI summarization before the meeting begins

Large inputs should not force the user into a tiny single-field workflow.
They should be accepted, summarized, or staged before the meeting starts.

## Message style rules

- One role turn = one message.
- One PM decision summary = one message, if shown.
- One user intervention = one message.
- One final report = one message.

## Default participant heuristic

Use these first when available:
- `real_powell`
- `gstack_commercial`
- `gstack_technical`
- `gstack_ux`

If the topic is more technical, include technical review roles.
If the topic is more strategic, include strategy-focused roles.
If the topic is more product-facing, include commercial and UX roles.

## Single-role analysis mode

Use a single role when the user wants one focused opinion.

Common example:
- `real_powell` for strategic integration and hard judgment

## Non-goals

- Do not call the original meeting CLI.
- Do not force all discussion into a single giant response.
- Do not skip the human confirmation step when the topic is ambiguous.