facilitation-design
Facilitation Design
Core principle: A well-designed session makes the group smarter than any individual in it. Bad meetings let the loudest voice win. Good facilitation structures participation so that the best thinking surfaces, regardless of who holds it.
When to Use This Skill
- A group needs to make a decision, generate ideas, or align on direction
- A meeting keeps happening but produces no outcomes
- Power dynamics or personality differences are suppressing useful input
- A workshop or offsite needs a structured agenda with clear deliverables
- A retrospective or review session needs to surface honest feedback
Core Methodology
Step 1: Define the Session Outcome
State what must be true at the end of the session that is not true now. Be specific:
- Bad: "Align on the roadmap" (vague — how will you know alignment happened?)
- Good: "Produce a ranked list of Q3 priorities with owner assignments that all leads have explicitly approved"
If the outcome can't be stated concretely, the session isn't ready to run. Clarify the outcome before designing the agenda.
Classify the session type based on the primary outcome:
- Divergent — generate options, surface perspectives, brainstorm (output: a long list)
- Convergent — narrow options, decide, commit (output: a decision or ranked list)
- Alignment — share context, build shared understanding (output: documented shared mental model)
- Retrospective — reflect on what happened, extract lessons (output: action items)
Step 2: Analyze the Participants
Map who will be in the room:
- Expertise distribution — who knows what? Where are knowledge gaps?
- Power dynamics — who has formal authority? Who has informal influence? Who tends to dominate?
- Stakes — who cares most about the outcome? Who might disengage?
- Communication styles — introvert/extrovert mix, remote vs. in-person participants
This analysis determines the participation architecture in Step 3. High power asymmetry demands more anonymous or written input. Introvert-heavy groups need individual thinking time before discussion.
If stakeholder-power-mapping has already been run, use its output directly.
Step 3: Design the Activity Sequence
Follow the diverge → cluster → converge arc. Every effective session moves through these phases, even if some are brief:
-
Opening (5-10 min) — state the outcome, explain the process, set ground rules. Remove ambiguity about what the group is doing and why.
-
Diverge (15-30 min) — generate input broadly. Use techniques that prevent anchoring:
- Silent writing first — everyone writes ideas individually before any discussion (prevents the first speaker from anchoring the group)
- Round-robin — each person shares one idea in turn (prevents dominant voices from monopolizing)
- 1-2-4-All — think alone, pair, quad, then full group (scales participation)
-
Cluster (10-15 min) — group related ideas into themes. Affinity mapping works: move items into groups, name the groups, identify gaps.
-
Converge (15-30 min) — narrow to decisions or priorities. Use:
- Dot voting — each person gets N votes to distribute (fast, democratic)
- Effort/impact matrix — plot options on two axes to surface quick wins and strategic bets
- Gradients of agreement — 5-point scale from "fully support" to "block" (more nuanced than yes/no)
-
Close (5-10 min) — state what was decided, who owns what, and the next checkpoint. Confirm understanding explicitly — don't assume silence means agreement.
Timeboxing rule: Allocate time by value of the outcome, not by volume of agenda items. The convergence phase is where decisions happen — give it at least 30% of total time.
Step 4: Choose the Decision Protocol
Decide before the session how the group will make decisions. Announce it at the start:
- Consensus — everyone agrees. Use only for small groups (< 7) with high trust and low time pressure.
- Consent — no one has a principled objection. Faster than consensus; good for operational decisions.
- Majority vote — quick but can alienate minorities. Use for low-stakes or reversible decisions.
- Authority with input — one person decides after hearing the group. Best when accountability is clear and speed matters. Name the decider explicitly.
Mismatched expectations about the decision protocol cause more meeting dysfunction than any other single factor.
Step 5: Engineer Psychological Safety
Design structural safeguards against groupthink and self-censorship:
- Anonymous input — use written submissions, anonymous polls, or digital tools for sensitive topics
- Structured turns — prevent "popcorn" discussion where only the confident speak
- Devil's advocate role — assign someone to argue the opposing position (rotated, not permanent)
- Pre-work — distribute context materials beforehand so the session isn't dominated by whoever prepared most
- Explicit permission to disagree — the facilitator models this: "What's the strongest argument against what we just decided?"
Output Format
🎯 Session Goal
- Outcome: [what must be true at the end that isn't true now]
- Session type: [Divergent / Convergent / Alignment / Retrospective]
- Duration: [total time]
- Decision protocol: [Consensus / Consent / Vote / Authority with input — name decider if applicable]
👥 Participant Profile
| Role | Name/Count | Expertise | Power Level | Key Concern |
|---|---|---|---|---|
| [role] | [who] | [what they know] | High / Medium / Low | [what they care about] |
📋 Agenda
| Time | Phase | Activity | Method | Output |
|---|---|---|---|---|
| 0:00-0:10 | Opening | State outcome, ground rules | Facilitator-led | Shared understanding of purpose |
| 0:10-0:30 | Diverge | [activity] | [silent write / round-robin / 1-2-4-All] | [list of ideas/inputs] |
| 0:30-0:45 | Cluster | [activity] | [affinity mapping] | [themed groups] |
| 0:45-1:10 | Converge | [activity] | [dot vote / matrix / gradients] | [ranked list / decision] |
| 1:10-1:20 | Close | Confirm decisions, assign owners | Facilitator-led | [action items with owners and dates] |
🧠 Facilitation Notes
- Opening prompt: "[exact words to open the session]"
- Transition cues: "[how to move from diverge to cluster, cluster to converge]"
- If energy drops: [contingency — change format, take a break, switch to pairs]
- If conflict arises: [contingency — name the disagreement explicitly, use the decision protocol]
- If time runs short: [what to cut, what to protect]
✅ Follow-Up
- Decisions made: [list]
- Action items: [owner + action + deadline]
- Next checkpoint: [when and how to review progress]
Thinking Triggers
- "If I removed this agenda item, would the session still achieve its outcome?"
- "Who in the room has relevant knowledge but is unlikely to speak up without structure?"
- "Am I giving enough time to convergence, or is the agenda all divergence?"
- "What's the decision protocol — and does everyone know it before the session starts?"
- "If the loudest person in the room is wrong, will this design surface that?"
Common Traps
No clear outcome: "Let's discuss X" is not a session goal. If you can't state what's different after the meeting, cancel the meeting.
Skipping divergence: Jumping straight to convergence means you're choosing among whatever the first speaker suggested. Always generate before you evaluate.
Consensus theater: The group appears to agree but individuals privately disagree. Use explicit commitment checks — "thumbs up / sideways / down" — not "any objections? No? Great."
Facilitator as participant: The person running the process should not also be advocating for a position. If the facilitator has a stake, assign a separate facilitator or declare the conflict upfront.
Ignoring remote participants: In hybrid sessions, remote attendees lose to in-room dynamics. Equalize by using digital-first input methods (chat, shared docs) even when some people are co-located.
More from andurilcode/craftwork
deep-document-processor
>
4summarizer
Apply this skill whenever the user asks to summarize, condense, distill, or compress any content — a document, article, meeting notes, conversation, codebase, book, research paper, video transcript, or any other source material. Triggers on phrases like 'summarize this', 'give me the TL;DR', 'condense this', 'what are the key points?', 'distill this down', 'brief me on this', 'what's the gist?', 'BLUF this', 'executive summary', 'compress this for me', or any request to reduce content while preserving its essential value. Also trigger when the user pastes a long text and implicitly wants it shortened, when they share a link and ask 'what does this say?', or when they ask for meeting notes or action items from a transcript. This skill does NOT apply to 'explain X to me' (use topic-explainer) or 'write a summary section for my doc' (use technical-writing). This skill is for when source material exists and needs to be compressed.
3inversion-premortem
Apply inversion and pre-mortem thinking whenever the user asks to evaluate a plan, strategy, architecture, feature, or decision before execution — or when they want to stress-test something that already exists. Triggers on phrases like "is this a good idea?", "what could go wrong?", "review this plan", "should we do this?", "are we missing anything?", "stress-test this", "what are the risks?", or any request to validate a decision or design. Use this skill proactively — if the user is about to commit to something, this skill should be consulted even if they don't ask for it explicitly.
3llms-txt-generator
Generate llms.txt-style context documents — token-budgeted, section-per-concept Markdown optimized for LLM and RAG consumption. Use this skill whenever someone asks to generate an llms.txt, create LLM-friendly documentation, produce a context document for a library or codebase, build a RAG-ready reference, make docs 'agent-readable', create a developer quick-reference, or says anything like 'generate context for X', 'make an llms.txt for this repo', 'create a reference doc for NotebookLM', 'turn these docs into something an LLM can use', 'context document', 'developer cheatsheet from docs'. Also trigger when someone provides a GitHub repo URL and asks for documentation synthesis, or when working inside a codebase and asked to produce a self-contained reference of how it works. This is the context engineer's doc generation tool — it turns sprawling documentation into precise, structured, token-efficient context.
3context-compressor
>
3probabilistic-thinking
Apply probabilistic and Bayesian thinking whenever the user needs to reason under uncertainty, compare risks, prioritize between options, update beliefs based on new evidence, or make decisions without complete information. Triggers on phrases like "what are the odds?", "how likely is this?", "should I be worried about X?", "which risk is bigger?", "does this data change anything?", "is this a signal or noise?", "what's the probability?", "how confident are we?", or any situation where decisions are being made based on incomplete or ambiguous evidence. Also trigger when someone is treating uncertain outcomes as certainties, or when probability language is being used loosely ("probably", "unlikely", "very likely") without quantification. Don't leave uncertainty unexamined.
3