diff --git a/management-consulting/skills/client-deliverables/SKILL.md b/management-consulting/skills/client-deliverables/SKILL.md
new file mode 100644
index 00000000..39e26c81
--- /dev/null
+++ b/management-consulting/skills/client-deliverables/SKILL.md
@@ -0,0 +1,737 @@
+---
+name: client-deliverables
+description: Create consulting-grade client deliverables (written reports and executive presentations). Use when producing strategic assessments, board decks, due diligence reports, steering committee updates, recommendation documents, PE IC memos, or any formal analysis requiring structured narrative (SCQA/SCR), evidence-based argumentation, data visualization, audience adaptation, and professional formatting. Covers both written and slide-based formats.
+---
+
+# Client Deliverables
+
+Produce formal consulting deliverables that communicate complex analysis with clarity and impact. This covers deliverable creation during and after consulting engagements, including both written reports and executive presentations. For pitch decks and proposals aimed at winning work, see proposal-development. Structure everything for decision-makers: bottom-line up front, evidence-backed findings, actionable recommendations, professional formatting.
+
+## Before You Begin
+
+Deliverables carry the firm's credibility. Every number and finding must be traceable. Before drafting:
+- What is the deliverable's purpose and who is the audience?
+- What decision does this deliverable enable?
+- What format is required (written report, presentation deck, leave-behind, or some combination)?
+- What analysis has been completed and what data is available to support findings?
+- Don't fabricate data points, source citations, benchmark figures, or case study results. When illustrative numbers are needed to demonstrate a format, label them clearly as examples. If specific numbers aren't available, use placeholders and flag them: "This needs [specific data]. Showing a placeholder based on [typical range]."
+
+---
+
+## Part 1: Common Methodology
+
+These principles apply to both written reports and presentations.
+
+### Structured Narrative: SCQA / SCR
+
+The same narrative logic underpins both formats. Reports use SCQA (Situation-Complication-Question-Answer). Presentations use the compressed SCR variant (Situation-Complication-Resolution). The difference is that presentations drop the explicit "Question" because it's implied by the complication, and the spoken format needs momentum.
+
+```
+SITUATION    ->  "This is where we are..."
+   |                (Establish context the reader/audience already agrees with)
+   v
+COMPLICATION ->  "This is the problem..."
+   |                (What's changed, what's at risk, what's broken)
+   v
+QUESTION     ->  "This is what we must answer..."  [Reports]
+   |                (The central question the report addresses)
+   v
+ANSWER /     ->  "This is what we recommend..."
+RESOLUTION          (The recommendation, stated clearly)
+```
+
+SCQA/SCR works because it mirrors how people process information: start with what they know, introduce the tension, then answer it. The reader/audience arrives at the recommendation already understanding why it matters.
+
+### The Pyramid Principle
+
+Every deliverable follows top-down logic, whether it's a 5-page brief or a 50-slide strategy deck.
+
+```
+                    +---------------+
+                    |   Answer      |  <- State this first
+                    +-------+-------+
+               +------------+------------+
+         +-----+-----+ +---+---+ +------+------+
+         | Argument 1| | Arg 2 | | Argument 3  |  <- 2-3 supporting reasons
+         +-----+-----+ +---+---+ +------+------+
+           +---+---+   +--+--+   +----+----+
+           |E1 |E2 |   |E3|E4|   |E5  |E6  |  <- Evidence for each
+           +---+---+   +--+--+   +----+----+
+```
+
+**The Answer** (top of the pyramid): One sentence that is the main point. If the audience remembers nothing else, they remember this.
+
+**Supporting Arguments** (2-3 maximum): The reasons why your answer is true. Each must be mutually exclusive and collectively exhaustive (MECE).
+
+**Evidence** (per argument): Data, examples, case studies that support each argument. Every fact must connect back to the argument above it.
+
+This structure applies at every level: the deliverable as a whole, each section/slide, each paragraph/bullet.
+
+### Action Headlines and Titles
+
+The single most impactful discipline in consulting deliverables. Every section heading (reports) and slide title (presentations) must be a complete sentence stating the takeaway, not a topic label.
+
+Bad: "Market Analysis"
+Good: "The addressable market has contracted 15% since 2023, driven by regulatory changes in three key segments"
+
+Bad: "Revenue Overview"
+Good: "Revenue declined 12% driven by customer churn in the mid-market segment"
+
+If you can't write the action headline, the section or slide doesn't have a point yet.
+
+### Audience Adaptation
+
+| Audience | What They Want | How to Deliver |
+|----------|---------------|----------------|
+| CEO / Board | Decision, strategic implications, risk | Lead with recommendation, quantify impact, address key risks, connect to shareholder value |
+| CFO | Financial proof, ROI, assumptions | Detailed financials, sensitivity analysis, conservative estimates |
+| COO | Implementation feasibility, resources | Operational plan, resource requirements, timeline |
+| CTO | Technical viability, architecture | Technical assessment, scalability, integration requirements |
+| Steering Committee | Progress, decisions needed, blockers | Status against plan, decision items, escalations |
+| Mixed / Large Group | Alignment, clarity, next steps | Simple message, clear visuals, explicit ask |
+
+**Executive audiences**: Lead with the answer and impact. Minimize methodology (move to appendix or backup). Focus on decisions and trade-offs. Use visual summaries over dense text.
+
+**Technical audiences**: Include methodology in detail. Show analytical work and assumptions. Use precise terminology (but still define specialized terms). Include sensitivity analysis.
+
+**Mixed audiences**: Structure with progressive disclosure. Headline finding, then supporting detail, then full data. Put methodology and technical detail at the back.
+
+### Data Storytelling
+
+- **Lead with the most compelling data point**: Don't bury the headline
+- **Annotate charts and exhibits**: Call out the insight, don't make readers find it
+- **Show change, not state**: Trends and deltas are more compelling than snapshots
+- **Use comparison**: "3x the industry average" lands harder than "15%"
+- **Connect to consequences**: Every number should answer "and that means..."
+- **Quantify the cost of inaction**: Makes the complication concrete
+
+### Chart Selection
+
+| Data Relationship | Recommended Chart |
+|---|---|
+| Comparison across categories | Bar chart (horizontal for many categories) |
+| Trends over time | Line chart |
+| Part-to-whole | Stacked bar, waterfall, or pie (sparingly) |
+| Correlation | Scatter plot |
+| Distribution | Histogram or box plot |
+| Geographic | Map or choropleth |
+| Process or flow | Sankey diagram or flowchart |
+| Hierarchical | Treemap or org chart |
+| Sensitivity / driver ranking | Tornado chart |
+| Scenario comparison | Side-by-side bar or table with conditional formatting |
+| Financial bridges (revenue to EBITDA, cost drivers) | Waterfall chart |
+
+**Chart standards** (both formats):
+- Title states the finding, not just the topic
+- Include source notes
+- Highlight the key data point visually (bold, color, annotation)
+- Consistent color schemes throughout the deliverable
+- Remove chartjunk: unnecessary gridlines, 3D effects, decorative elements
+- Every chart should make exactly one point. If it makes two, split it
+
+**Presentation-specific chart rules**:
+- One chart per slide, making one point
+- Annotate the insight directly on the chart
+- Avoid pie charts with more than 4-5 slices
+- Max 5 rows in any table shown during a live presentation. Move detail to backup slides.
+
+### Sensitivity Analysis
+
+When presenting financial projections with uncertainty, use these formats:
+
+**Tornado chart** (for identifying which variables matter most): List variables vertically, show NPV impact range horizontally. Order by magnitude of swing. The top 2-3 bars are where management attention belongs.
+
+```
+Variable              | NPV Impact Range
+Adoption rate         |=====[----BASE----]==========|  +/- $12M
+Benefit timeline      |=======[--BASE--]========|     +/- $8M
+Implementation cost   |========[-BASE-]======|        +/- $5M
+Discount rate         |=========[BASE]=====|          +/- $3M
+```
+
+**Scenario table** (for communicating overall risk profile):
+
+| Scenario | Key Assumptions | NPV | IRR | Payback | Probability |
+|----------|----------------|-----|-----|---------|-------------|
+| Upside | [2 key drivers] | $XX | XX% | X yrs | XX% |
+| Base | [2 key drivers] | $XX | XX% | X yrs | XX% |
+| Downside | [2 key drivers] | $XX | XX% | X yrs | XX% |
+
+Always state the break-even threshold: "The business case remains positive even if benefits are [X]% below plan."
+
+**Structure each scenario with:**
+
+| Element | Base Case | Upside | Downside |
+|---|---|---|---|
+| Key assumption | [Most likely] | [Optimistic] | [Conservative] |
+| Revenue/benefit impact | $X | $Y | $Z |
+| Probability weighting | 50-60% | 20-25% | 20-25% |
+| Trigger indicators | [What you'd see] | [What you'd see] | [What you'd see] |
+
+Include:
+- **Decision triggers**: "If [metric] falls below [threshold] by [date], shift to [alternative plan]"
+- **Sensitivity analysis**: Which 2-3 assumptions most affect the outcome? What happens if each moves +/- 20%?
+- **Break-even analysis**: At what point does the recommendation no longer hold?
+
+### Writing Standards
+
+These apply to both prose in reports and text on slides (adapted for density).
+
+| Element | Standard |
+|---|---|
+| Sentence length | Max 25 words |
+| Paragraph length | Max 4 sentences (reports); bullets preferred (slides) |
+| Headlines/titles | Action-oriented complete sentences, not topic labels |
+| Numbers | Always quantify where possible |
+| Dates | Always specify, avoid "soon", "later", "in the near term" |
+| Names | Use full names for people and organizations |
+| Jargon | Avoid or define all technical terms |
+
+**Evidence standards:**
+
+| Type | Requirement |
+|---|---|
+| Data | Source, date, and methodology noted |
+| Quotes | Named sources, verified |
+| Benchmarks | Comparable sources cited |
+| Expert opinions | Named experts where possible |
+| Case studies | Specific examples with results |
+
+**Voice:**
+- Active voice: "We recommend" not "It is recommended"
+- Be direct: avoid hedge words like "perhaps", "might", "may"
+- "We believe X because Y" is stronger than "X could potentially be considered"
+
+**Before/After: Bad vs. Good Consulting Prose**
+
+Vague and passive:
+> "It is believed that there may be potential opportunities for significant improvement in certain areas of the organization's operational processes, which could potentially lead to enhanced performance outcomes going forward."
+
+Direct and quantified:
+> "Three process changes will cut order fulfillment time from 14 days to 5 days, saving $2.3M annually in working capital costs."
+
+Hedge-laden:
+> "The market appears to be showing some signs of potential softening, which might suggest that a more cautious approach could perhaps be warranted in the near term."
+
+Clear and committed:
+> "The addressable market contracted 12% in Q3. We recommend delaying the product launch to Q2 2027 and reallocating $4M from marketing to R&D."
+
+Buried lead:
+> "After conducting an extensive analysis of the competitive landscape, examining market trends across multiple segments, and reviewing internal capability assessments, our team has concluded that the acquisition of TargetCo represents a compelling strategic opportunity."
+
+Bottom-line up front:
+> "Acquire TargetCo for EUR 85M. It fills our capability gap in APAC distribution and is accretive to EBITDA by Year 2. Three factors support this recommendation."
+
+The pattern: replace throat-clearing with the conclusion. Replace hedges with data. Replace abstractions with specifics.
+
+### Quality Assurance
+
+Before finalizing any deliverable:
+
+- Executive summary / first slide stands alone (readable in 5 minutes, gives the complete picture)
+- Every finding has supporting evidence
+- Every recommendation has rationale
+- All numbers are sourced
+- All terms are defined
+- Formatting is consistent throughout
+- The conclusion matches the evidence
+- The deliverable answers the original question
+- Scenario analysis included for recommendations with significant uncertainty
+- Specific owners and dates for all recommended actions
+- When citing benchmarks or peer comparisons, flag the source explicitly. "Industry benchmarks suggest..." is weaker than "Per [Source/analysis], the benchmark is X." If no published source exists, say "based on our analysis" or "directional estimate based on [basis]." Unsourced benchmarks invite challenge and erode credibility.
+
+---
+
+## Part 2: Written Reports
+
+### Report Types
+
+| Type | Purpose |
+|---|---|
+| Strategic assessment | Evaluate options and recommend direction |
+| Due diligence report | Investigate and validate claims or assumptions |
+| Implementation plan | Define how to execute a strategy |
+| Performance review | Assess results against targets |
+| Recommendations document | Present findings and proposed actions |
+| Status report | Communicate progress and issues |
+| PE investment committee memo | Present investment thesis for fund decision |
+
+### Depth and Length Calibration
+
+Match report depth to audience and purpose. Not every analysis needs 30 pages.
+
+| Output Level | Word Count | When to Use |
+|---|---|---|
+| Executive brief | 500-800 words | Board-level summary, decision memo, time-pressed stakeholders |
+| Working report | 2,000-4,000 words | Standard client deliverable, recommendations with supporting analysis |
+| Deep-dive report | 4,000-8,000 words | Comprehensive strategic assessment, due diligence, regulatory submissions |
+| Full study | 8,000+ words | Multi-workstream transformation reports, market entry studies with appendices |
+
+When in doubt, write shorter. A 3,000-word report that gets read beats a 10,000-word report that doesn't.
+
+### Tone Calibration
+
+- **Voice**: Expert, collaborative, or direct (match the client relationship)
+- **Technical level**: Executive summary, detailed, or technical
+- **Format**: Formal report, executive briefing, or working document
+
+### Narrative Structures
+
+**SCQA (full version for written reports):**
+1. Situation: establish context
+2. Complication: what's changed or at risk
+3. Question: the central question the report addresses
+4. Answer: the recommendation, stated clearly
+
+**Answer-First Structure** (for audiences who want to cut to the chase):
+1. **Executive Summary** ... full message here (someone who reads only this page gets the complete picture)
+2. **The Question** ... what we were asked to address
+3. **The Answer** ... our recommendation in brief
+4. **Supporting Evidence** ... analysis section by section
+5. **Required Actions** ... what needs to happen, by whom, by when
+6. **Appendices** ... supporting detail
+
+### Section Templates
+
+#### Executive Summary
+
+The executive summary is the most important section. It must stand alone.
+
+Structure:
+- **Bottom Line**: One paragraph stating the answer, the impact, and the recommendation
+- **Key Findings**: 3-5 findings, quantified where possible
+- **Recommendations**: Prioritized list
+- **Expected Outcomes**: Impact and timeline for each
+- **Next Steps**: Immediate actions required
+
+Write the executive summary last, after all analysis is complete.
+
+#### Analysis Sections
+
+Each analysis section follows the same pattern:
+- **Headline**: One sentence capturing the key finding (not a topic label)
+- **Supporting Evidence**: Data points with sources and implications
+- **Analysis**: Explanation of what the evidence means
+- **Implications**: What this means for the business
+
+#### Recommendation Sections
+
+Each recommendation needs:
+- **The Recommendation**: Clear statement of what should be done
+- **Rationale**: Why this is the right course of action
+- **Supporting Evidence**: Data that backs this up
+- **Impact**: Projected outcomes with current vs. projected metrics
+- **Risks and Mitigations**: What could go wrong and how to address it
+
+### PE Investment Committee Memo
+
+Investment committee (IC) memos follow a rigid structure because the committee reviews multiple deals per meeting. Deviation from the expected format slows the decision.
+
+```
+INVESTMENT COMMITTEE MEMORANDUM
+
+Company:          [Target Name]
+Sector:           [Industry / Sub-sector]
+Deal Type:        [Buyout / Growth Equity / Add-on / Recapitalization]
+Enterprise Value: [Amount]
+Equity Check:     [Amount]
+Target Close:     [Date]
+Sponsor Coverage: [Deal Team Lead]
+
+1. EXECUTIVE SUMMARY
+   - Investment thesis in 3-4 sentences
+   - Key return drivers
+   - Headline returns: [X.X]x MOIC / [XX]% IRR over [X] year hold
+
+2. COMPANY OVERVIEW
+   - Business description, products/services, end markets
+   - Revenue: $[X]M | EBITDA: $[X]M | EBITDA Margin: [X]%
+   - Revenue mix (by product, geography, customer)
+   - Customer concentration (top 10 customers as % of revenue)
+   - Management team assessment
+
+3. INVESTMENT THESIS
+   - Thesis pillar 1: [Growth lever with quantified impact]
+   - Thesis pillar 2: [Margin lever with quantified impact]
+   - Thesis pillar 3: [Strategic lever with quantified impact]
+
+4. MARKET & COMPETITIVE DYNAMICS
+   - TAM/SAM sizing
+   - Growth drivers and secular trends
+   - Competitive positioning and moat assessment
+
+5. FINANCIAL OVERVIEW & PROJECTIONS
+   - Historical financials (3 years) with key metrics
+   - Management case vs. sponsor case
+   - Revenue bridge and EBITDA bridge
+   - Working capital and capex requirements
+
+6. DEAL STRUCTURE & RETURNS
+   - Sources & uses
+   - Capital structure and leverage ratios
+   - Returns analysis: base / upside / downside
+   - Key assumptions driving each scenario
+
+7. KEY RISKS & MITIGANTS
+   | Risk | Severity | Mitigant |
+   |------|----------|----------|
+   | [Risk 1] | [H/M/L] | [Specific mitigation] |
+
+8. VALUE CREATION PLAN
+   - 100-day plan priorities
+   - Operational initiatives with timeline
+   - M&A / add-on pipeline (if applicable)
+
+9. EXIT CONSIDERATIONS
+   - Likely exit paths (strategic sale, sponsor-to-sponsor, IPO)
+   - Comparable exit multiples
+   - Target exit timeline
+
+10. RECOMMENDATION
+    - Approve / Approve with conditions / Decline
+    - Conditions or open items (if any)
+    - Requested next steps
+```
+
+**IC memo writing standards**: Be factual, not promotional. The committee's job is to find reasons NOT to invest. Anticipate their objections and address them directly. Management cases are always more optimistic than reality; show the sponsor case with conservative assumptions. Every number needs a source.
+
+### Document Structure
+
+```
+[Firm/Company Logo]
+[Report Title]
+[Date]
+[Classification: Confidential / Internal / Public]
+
+Table of Contents
+
+Executive Summary
+
+1. Introduction / Context
+2. Methodology (if applicable)
+3. Findings / Analysis
+4. Recommendations
+5. Implementation Plan
+6. Appendices
+```
+
+Version, author, and reviewer should be noted on the cover page or in document properties.
+
+### Multi-Author Coordination
+
+For reports with multiple contributors (common on large engagements), establish these upfront:
+
+**Before Writing:**
+- **Single outline owner**: One person owns the overall narrative arc and section structure. Committee-written outlines produce committee-quality reports
+- **Section assignments**: Each section has exactly one author. Shared ownership means nobody owns it
+- **Style guide agreement**: Agree on voice (first person plural "we" vs. third person), tense, heading conventions, and evidence citation format
+- **Placeholder convention**: Use `[TBD: description of needed content]` for sections awaiting input. Never leave blank sections
+
+**During Writing:**
+- **Integration checkpoints**: Schedule two review points: (1) after first drafts of all sections, (2) after revisions. Don't wait for final assembly to discover inconsistencies
+- **Cross-reference log**: Track which sections reference data or findings from other sections. When one section changes, flag dependent sections
+- **Terminology register**: Maintain a short list of key terms and how they're used. "Revenue" vs. "net revenue" vs. "ARR" discrepancies across sections destroy credibility
+
+**Version Control and Review Workflow:**
+
+Naming convention: `[Client]_[Report]_v[Major].[Minor]_[Date]_[Author].docx`
+- Major version: structural changes, new sections, post-review rewrites (v1.0, v2.0)
+- Minor version: edits within existing structure (v1.1, v1.2)
+- Example: `Acme_MarketEntry_v2.1_2026-03-15_JSmith.docx`
+
+| Stage | Version | Who Reviews | What They Check |
+|-------|---------|-------------|-----------------|
+| First draft | v0.1 | Author self-review | Structure, completeness, argument logic |
+| Peer review | v0.5 | One colleague | Logic, evidence gaps, readability |
+| Manager review | v1.0 | Engagement manager | Narrative arc, client-readiness, accuracy |
+| Partner review | v1.5 | Partner/director | Strategic positioning, risk, tone |
+| Client draft | v2.0 | Client review | Factual accuracy, alignment with expectations |
+| Final | v3.0 | Final QA | Formatting, cross-references, typos |
+
+**Track changes discipline**: One reviewer at a time. Resolve all comments before passing to the next reviewer. Parallel reviews at the same level produce conflicting edits.
+
+**Working in shared drives**: Lock the file when editing. Use a simple status tracker: "v1.2 with JSmith for manager review, due back Mar 18."
+
+**Final Assembly:**
+- One person does final assembly and voice harmonization. This takes longer than people expect (budget 1-2 days for a full report)
+- Check that the executive summary reflects the actual content, not an earlier draft's conclusions
+- Verify all cross-references and page numbers
+
+### Report-Specific Quality Checklist
+
+In addition to the common checklist:
+- Page numbers present
+- Table of contents is accurate
+- Grammar and spelling are correct
+- Scenario analysis included for recommendations with significant uncertainty
+
+---
+
+## Part 3: Executive Presentations
+
+### Defining the Core Message
+
+Before opening any slide tool, write these three things:
+
+1. **The answer in one sentence**: "We should enter the German market through acquisition of [Target] for EUR 120M"
+2. **The three supporting arguments**: Why now, why this target, why acquisition vs. organic
+3. **The evidence for each**: Market data, target financials, comparable transactions
+
+If you cannot write these clearly, you are not ready to build slides.
+
+### Deck Structure
+
+| Slide Type | Purpose | Key Elements |
+|------------|---------|--------------|
+| Title | Set expectation | Punchy title (max 6 words), subtitle with key message, presenter, date |
+| Executive Summary | Full message for time-pressed readers | 3-5 bullets covering the complete recommendation; bottom line up front |
+| Context/Situation | Establish common ground | Facts the audience agrees with, current state data |
+| Problem/Complication | Create urgency | Impact metric, trend visualization, quantified cost of inaction |
+| Analysis | Show the thinking | Framework visual (2x2, waterfall, etc.), key insight in one sentence |
+| Recommendation | Present the answer | Recommendation in one line; why now, why us, why this; quantified impact |
+| Financial Impact | Prove the value | Benefits, costs, net value; waterfall or bridge chart; key assumptions and sensitivity |
+| Roadmap/Next Steps | Call to action | Phased timeline with actions, owners, dates; immediate first action |
+
+### Slide Anatomy
+
+```
++-------------------------------------------+
+| ACTION TITLE (complete sentence)          |  <- The slide's takeaway
++-------------------------------------------+
+|                                           |
+|   [Exhibit: chart, table, framework]      |  <- Visual evidence
+|                                           |
+|                                           |
+|                                           |
+| Source: [data source, date]               |  <- Attribution
++-------------------------------------------+
+```
+
+The action title is what distinguishes consulting slides from everything else. Write it as a complete sentence stating the takeaway.
+
+The body is exhibit-driven. Charts, tables, and frameworks dominate... not paragraphs or bullets. One focused exhibit is ideal. Two related exhibits side by side works when they jointly support the action title.
+
+**The "So What?" test** for each slide:
+- So what? (Why does the audience care about this?)
+- Says who? (Is this credible? What's the source?)
+- What if? (What are the implications?)
+
+If you can't answer "so what?" in one sentence, cut or restructure the slide.
+
+### Presentation vs. Leave-Behind
+
+Different formats require different density. Decide which you're building before you start.
+
+| Dimension | Presentation Deck | Leave-Behind / Read-Ahead |
+|-----------|-------------------|---------------------------|
+| **Primary audience** | People in the room | People reading alone, later |
+| **Font size** | 30pt minimum | 18pt minimum |
+| **Content density** | One point per slide | Can layer 2-3 points per page |
+| **Exhibits** | One per slide, annotated | Can include supporting detail |
+| **Action titles** | Short, punchy | Can be longer, more descriptive |
+| **Appendix** | Separate backup slides | Can be inline or appended |
+| **Typical length** | 8-12 slides + backup | 15-30 pages |
+| **Goal** | Drive a decision in the room | Survive forwarding to people who weren't there |
+
+A presentation deck that gets forwarded as a read-ahead usually fails at both jobs. If the deck will serve both purposes, add a 1-page executive summary that works standalone, and put supporting detail in clearly labeled appendix sections.
+
+### 10-Slide Report Summary Template
+
+For reports that also need a board or executive presentation, produce a 10-slide summary. This is not "put the report on slides." It's a restructured argument for a spoken format.
+
+| Slide | Content | Notes |
+|---|---|---|
+| 1. Title | Report title, date, classification | Match the report cover |
+| 2. Executive summary | 3-5 bullet recommendation with impact numbers | Someone who sees only this slide gets the full message |
+| 3. Situation | Context the audience agrees with | 2-3 data points, not a wall of text |
+| 4. Complication | What's changed or at risk | Quantify the cost of inaction |
+| 5. Key finding #1 | Strongest analytical finding | One chart or framework, action headline |
+| 6. Key finding #2 | Second finding | One chart or framework, action headline |
+| 7. Key finding #3 | Third finding (if needed) | Merge with #6 if two findings suffice |
+| 8. Recommendation | What to do, quantified impact | Options table if multiple paths |
+| 9. Scenario / sensitivity | Base, upside, downside with key triggers | Tornado chart or scenario table |
+| 10. Next steps | Actions, owners, dates | First action should be achievable this week |
+
+### Board Deck Specifics
+
+Board presentations have distinct dynamics. Directors have fiduciary obligations, limited time, and see dozens of proposals.
+
+**Framing**: Connect every recommendation to shareholder value, risk management, or strategic positioning. Boards think in terms of fiduciary duty, not operational efficiency.
+
+**Governance committee expectations**: If the proposal touches audit, compensation, or risk committees, address their specific mandates. An audit committee wants control frameworks. A risk committee wants quantified exposure. A compensation committee wants alignment between incentives and outcomes.
+
+**What boards want to see**:
+- Investment size relative to total capital budget (context, not just the number)
+- Downside scenario and management's plan for it
+- Competitive implications of acting vs. not acting
+- Management's confidence level and basis for it
+- Clear decision requested: approve, approve with conditions, or defer
+
+**What boards don't want**:
+- Operational detail they can't evaluate (save it for backup)
+- Options without a recommendation (they hired management to decide)
+- Surprises (pre-wire key stakeholders before the meeting)
+
+### Pre-Wiring Key Stakeholders
+
+Pre-wiring means socializing the recommendation with influential stakeholders before the formal meeting. It eliminates surprises, surfaces objections you can address in the deck, and converts potential opponents into allies (or at least non-blockers).
+
+**Who to pre-wire**: The decision-maker, anyone with veto power, known skeptics, and anyone whose public reaction will influence the room.
+
+**How to pre-wire**:
+1. Request 15-20 minutes 1:1, framed as "I want to make sure this lands well... can I walk you through the key points?"
+2. Share the recommendation and 2-3 supporting data points (not the full deck)
+3. Ask for their reaction and concerns. Listen more than you pitch
+4. Incorporate legitimate objections into the deck (add a slide, adjust language, prepare a backup)
+5. If they disagree fundamentally, you know before the meeting and can adjust scope, framing, or the ask
+
+**Timing**: 2-5 days before the meeting. Too early and context shifts. Too late and you can't adjust.
+
+**What pre-wiring is NOT**: Lobbying for a predetermined outcome. If pre-wiring reveals your recommendation is wrong, change the recommendation.
+
+### Backup Slides
+
+Every deck should have backup slides ready for Q&A. Build them before you need them.
+
+**Standard backup categories**:
+- Detailed methodology and assumptions
+- Full financial model with sensitivity tables
+- Competitive benchmarking data
+- Risk register with mitigations
+- Alternative scenarios that were considered and rejected
+- Implementation timeline at workstream level
+
+**Formatting backup slides**: Use the same action-title format as the main deck. Label each clearly (e.g., "BACKUP: Detailed NPV Assumptions"). Number them separately from the main deck (B1, B2, B3) so you can reference them quickly.
+
+### Storytelling Techniques
+
+| Element | Technique | Example |
+|---------|-----------|---------|
+| Start strong | Provocative question or data point | "What if everything you thought about growth was wrong?" |
+| Create tension | Highlight cost of inaction | "Every quarter we wait costs us $X million" |
+| Show the journey | Share a concrete finding | "We met with 50 customers and heard the same thing three times" |
+| Build to climax | Layer insights | "First we found X, then Y, which led us to Z" |
+| End with action | Clear call to decision | "We recommend you approve Phase 1 by Friday" |
+
+### Flex Structure: Reordering and Skipping Slides
+
+No presentation survives first contact with the audience. Build your deck so you can adapt in real time.
+
+**Before the meeting**: Know which slides are load-bearing (must show) and which are supporting (can skip). Mark them in your speaker notes. A typical 12-slide deck has 5-6 must-show slides.
+
+**Reading the room**:
+- If the audience is nodding through context slides, skip ahead: "I see you're aligned on the context... let me jump to the analysis."
+- If they're stuck on a point, pause the planned flow. Going forward when the room is still processing slide 3 means slides 4-12 are wasted.
+- If a question jumps ahead to a later slide, go there. Don't say "I'll get to that." You'll lose them.
+- If energy drops during detailed analysis, jump to the recommendation and work backwards: "Let me show you where we landed, then we can dig into the supporting analysis."
+
+**Structural enablers**:
+- Number your backup slides (B1, B2...) so you can navigate quickly
+- Use section dividers so you can skip entire sections cleanly
+- Keep a mental map of three paths through the deck: full, abbreviated (skip supporting detail), and "cut to the chase" (exec summary + recommendation + next steps)
+
+### Handling Live Slide Edits
+
+Clients will ask you to change slides during the meeting. This is normal in consulting.
+
+**When to edit live**:
+- Wording changes to recommendations that reflect genuine alignment shifts
+- Adding a caveat or condition the room agrees on
+- Updating a number with better data someone provides in the moment
+
+**When NOT to edit live**:
+- Structural changes that require rethinking the argument
+- Requests that are really one person's preference, not the room's consensus
+- Changes that would take more than 60 seconds
+
+**How to handle it**:
+- Acknowledge: "Good point. Let me capture that." Make the edit if quick, or write the change on paper/in notes and confirm: "I'll update the deck and circulate by [time]."
+- If using projected slides, have a second person make edits on a laptop while you keep presenting
+- Always read back the revised language to confirm: "So the recommendation now reads [X]... does that capture it?"
+- Send the updated deck within 24 hours with changes highlighted
+
+### Handling Q&A
+
+**Preparation**: For every presentation, build an anticipation table:
+
+| Anticipated Question | Why It's Hard | Best Response | Fallback |
+|---------------------|---------------|---------------|----------|
+| "Why not option B?" | They may prefer it | Data comparison showing A outperforms | "Happy to model both scenarios" |
+| "What's the downside?" | Acknowledging risk | Quantified risk with mitigation plan | "We've stress-tested three scenarios" |
+
+**Response framework**:
+1. **Listen completely**: Don't interrupt, let them finish, acknowledge the question
+2. **Confirm understanding**: "So what you're asking is..." or "Let me make sure I understand..."
+3. **Answer directly**: Lead with the answer, support with evidence, be concise
+4. **Confirm resolution**: "Does that address your question?"
+
+If you don't know the answer: say so. "I don't have that data with me. I'll follow up by [date]." Credibility is built by honesty, not by bluffing.
+
+### One-Page Recommendation Memo
+
+When a full deck is overkill:
+
+```
+# Memo: [Recommendation Title]
+
+## Recommendation
+[Clear statement of what you recommend]
+
+## Problem
+[What challenge or opportunity this addresses]
+
+## Analysis
+1. [Key finding 1 with evidence]
+2. [Key finding 2 with evidence]
+3. [Key finding 3 with evidence]
+
+## Value
+- [Benefit 1 -- quantified]
+- [Benefit 2 -- quantified]
+
+## Implementation
+- Timeline: [Duration]
+- Key milestones: [Milestones]
+- Investment required: [Amount]
+
+## Risks and Mitigations
+| Risk | Mitigation |
+|------|-----------|
+| [Risk 1] | [Mitigation] |
+| [Risk 2] | [Mitigation] |
+
+## Decision Needed
+[What you need from the decision-maker, by when]
+
+## Next Steps
+1. [Immediate action -- owner -- date]
+2. [Follow-up action -- owner -- date]
+```
+
+### Design Principles
+
+- Use brand colors consistently (client's or firm's, depending on context)
+- Limit to 3-4 colors per slide
+- Use color to highlight, not decorate
+- Ensure high contrast for readability
+- White space is a feature, not wasted space
+- Use consistent fonts and sizes throughout
+- Consider accessibility (color-blind friendly palettes)
+
+### Behavioral Principles
+
+- **Lead with the answer, always.** Executives lose patience with build-up. State the recommendation in the first 30 seconds and earn the right to explain afterward.
+- **Every slide must pass the "so what?" test.** If you cannot articulate why the audience should care in one sentence, cut or restructure it.
+- **Quantify or don't claim it.** Unsupported claims erode credibility. Attach a number, a source, or a date to every assertion.
+- **Design for the skeptic in the room.** Assume at least one audience member will challenge your logic. Build the pyramid so each level withstands scrutiny independently.
+- **Less content, more conviction.** A 7-slide deck delivered with authority beats a 30-slide deck that hedges. Cut ruthlessly and own what remains.
+- **Consider the hybrid audience.** When presenting to both in-room and remote participants, design for the screen first.
+
+---
+
+## PPTX Generation
+
+When generating actual .pptx files (not markdown outlines), read
+[references/pptx-generation.md](references/pptx-generation.md) for consulting-specific slide
+masters, anatomy rules, and layout patterns using pptxgenjs. Default to
+`LAYOUT_WIDE` (13.33" x 7.5") for consulting decks.
diff --git a/management-consulting/skills/client-deliverables/references/pptx-generation.md b/management-consulting/skills/client-deliverables/references/pptx-generation.md
new file mode 100644
index 00000000..b1d8aac4
--- /dev/null
+++ b/management-consulting/skills/client-deliverables/references/pptx-generation.md
@@ -0,0 +1,823 @@
+# Consulting PPTX Generation Guide
+
+Reference for generating consulting-grade .pptx files with pptxgenjs. Principles and adaptable code patterns — not fixed styles. Choose colors, fonts, and density based on client, firm, and purpose.
+
+---
+
+## Layout
+
+Default to widescreen for consulting leave-behinds:
+
+```js
+const pptx = new PptxGenJS();
+pptx.layout = "LAYOUT_WIDE"; // 13.33" x 7.5"
+```
+
+Every content slide has three zones:
+
+| Zone | Height | Purpose |
+|------|--------|---------|
+| Action title | ~1.0" | Sentence stating the slide's takeaway |
+| Body | ~5.0" | Exhibit(s) — charts, tables, frameworks |
+| Footer | ~0.5" | Source attribution + page number |
+
+Choose margins and density based on purpose: dense analytical slides get tighter margins, big-idea slides get generous white space.
+
+---
+
+## Slide Anatomy (Non-Negotiable)
+
+The pattern that distinguishes consulting slides from everything else:
+
+1. **Action title** — A complete sentence stating the takeaway. "Revenue declined 12% driven by customer churn" not "Revenue Overview." This is the most important rule.
+
+2. **Exhibit-driven body** — Visual exhibits (charts, tables, frameworks) dominate, not paragraphs or bullets. One focused exhibit is ideal. Two related exhibits side-by-side (e.g. market size + growth rate) works when they jointly support the action title. The exhibit tells the story; text annotates it.
+
+3. **Source line** — Bottom of slide, small font. Data source, date, caveats.
+
+Apply this to every content slide. Title slides, section dividers, and appendix slides are exceptions.
+
+---
+
+## Slide Masters
+
+Three masters as factory functions. `palette` and `fonts` are parameters — the agent picks values per engagement.
+
+### TITLE_SLIDE
+
+```js
+function addTitleSlide(pptx, { title, subtitle, date, presenter, palette, fonts }) {
+  const slide = pptx.addSlide({ masterName: "TITLE_SLIDE" });
+  slide.background = { color: palette.dark };
+
+  slide.addText(title, {
+    x: 0.8, y: 2.0, w: 11.7, h: 1.5,
+    fontSize: 36, fontFace: fonts.heading,
+    color: palette.light, bold: true,
+    align: "left",
+  });
+
+  slide.addText(subtitle, {
+    x: 0.8, y: 3.6, w: 11.7, h: 0.8,
+    fontSize: 18, fontFace: fonts.body,
+    color: palette.lightMuted,
+    align: "left",
+  });
+
+  slide.addText(`${presenter}  |  ${date}`, {
+    x: 0.8, y: 6.2, w: 11.7, h: 0.4,
+    fontSize: 12, fontFace: fonts.body,
+    color: palette.lightMuted,
+    align: "left",
+  });
+
+  return slide;
+}
+```
+
+### CONTENT_SLIDE
+
+```js
+function addContentSlide(pptx, { actionTitle, source, pageNum, palette, fonts }) {
+  const slide = pptx.addSlide({ masterName: "CONTENT_SLIDE" });
+  slide.background = { color: palette.light };
+
+  // Action title zone
+  slide.addText(actionTitle, {
+    x: 0.6, y: 0.3, w: 12.1, h: 0.7,
+    fontSize: 18, fontFace: fonts.heading,
+    color: palette.dark, bold: true,
+    align: "left", valign: "top",
+  });
+
+  // Thin divider line
+  slide.addShape(pptx.ShapeType.line, {
+    x: 0.6, y: 1.05, w: 12.1, h: 0,
+    line: { color: palette.accent, width: 1.0 },
+  });
+
+  // Footer: source + page number
+  slide.addText(source, {
+    x: 0.6, y: 7.0, w: 10.0, h: 0.3,
+    fontSize: 8, fontFace: fonts.body,
+    color: palette.muted, italic: true,
+    align: "left",
+  });
+  slide.addText(String(pageNum), {
+    x: 11.5, y: 7.0, w: 1.2, h: 0.3,
+    fontSize: 8, fontFace: fonts.body,
+    color: palette.muted,
+    align: "right",
+  });
+
+  return slide; // caller adds exhibit(s) to the body zone (y: 1.2, h: ~5.7)
+}
+```
+
+### SECTION_DIVIDER
+
+```js
+function addSectionDivider(pptx, { sectionNumber, sectionTitle, palette, fonts }) {
+  const slide = pptx.addSlide({ masterName: "SECTION_DIVIDER" });
+  slide.background = { color: palette.dark };
+
+  if (sectionNumber) {
+    slide.addText(String(sectionNumber).padStart(2, "0"), {
+      x: 0.8, y: 2.0, w: 2.0, h: 1.0,
+      fontSize: 48, fontFace: fonts.heading,
+      color: palette.accent, bold: true,
+      align: "left",
+    });
+  }
+
+  slide.addText(sectionTitle, {
+    x: 0.8, y: 3.2, w: 11.7, h: 1.0,
+    fontSize: 28, fontFace: fonts.heading,
+    color: palette.light, bold: true,
+    align: "left",
+  });
+
+  return slide;
+}
+```
+
+---
+
+## Common Consulting Slide Patterns
+
+Each function accepts content + style parameters. No hardcoded colors. All follow the action-title + exhibit anatomy — call `addContentSlide()` first, then add the exhibit to the returned slide.
+
+### Executive Summary
+
+```js
+function addExecSummary(slide, { findings, bottomLine, palette, fonts }) {
+  // 4-5 bullet findings
+  const bulletText = findings.map((f) => ({
+    text: f,
+    options: {
+      fontSize: 14, fontFace: fonts.body, color: palette.dark,
+      bullet: { type: "number" },
+      paraSpaceAfter: 8,
+    },
+  }));
+
+  slide.addText(bulletText, {
+    x: 0.6, y: 1.3, w: 12.1, h: 3.5,
+    valign: "top",
+  });
+
+  // Bottom-line callout box
+  slide.addShape(pptx.ShapeType.rect, {
+    x: 0.6, y: 5.2, w: 12.1, h: 1.2,
+    fill: { color: palette.accentLight },
+    rectRadius: 0.1,
+  });
+  slide.addText(bottomLine, {
+    x: 0.9, y: 5.3, w: 11.5, h: 1.0,
+    fontSize: 14, fontFace: fonts.body, color: palette.dark,
+    bold: true, valign: "middle",
+  });
+}
+```
+
+### Framework / Matrix (2x2)
+
+```js
+function addFrameworkMatrix(slide, { quadrants, axisLabels, palette, fonts }) {
+  // quadrants: [{ label, items, position: "tl"|"tr"|"bl"|"br" }]
+  const positions = {
+    tl: { x: 0.8, y: 1.3 }, tr: { x: 7.0, y: 1.3 },
+    bl: { x: 0.8, y: 4.0 }, br: { x: 7.0, y: 4.0 },
+  };
+  const cellW = 5.8, cellH = 2.5;
+
+  quadrants.forEach((q) => {
+    const pos = positions[q.position];
+    slide.addShape(pptx.ShapeType.rect, {
+      x: pos.x, y: pos.y, w: cellW, h: cellH,
+      fill: { color: palette.light },
+      line: { color: palette.muted, width: 0.5 },
+    });
+    slide.addText(q.label, {
+      x: pos.x + 0.2, y: pos.y + 0.15, w: cellW - 0.4, h: 0.4,
+      fontSize: 13, fontFace: fonts.heading,
+      color: palette.accent, bold: true,
+    });
+    const items = q.items.map((item) => ({
+      text: item,
+      options: { fontSize: 11, fontFace: fonts.body, color: palette.dark, bullet: true },
+    }));
+    slide.addText(items, {
+      x: pos.x + 0.2, y: pos.y + 0.6, w: cellW - 0.4, h: cellH - 0.8,
+      valign: "top",
+    });
+  });
+
+  // Axis labels
+  if (axisLabels) {
+    slide.addText(axisLabels.x, {
+      x: 5.0, y: 6.6, w: 3.3, h: 0.3,
+      fontSize: 10, fontFace: fonts.body, color: palette.muted,
+      align: "center", italic: true,
+    });
+    slide.addText(axisLabels.y, {
+      x: 0.1, y: 3.5, w: 0.5, h: 2.0,
+      fontSize: 10, fontFace: fonts.body, color: palette.muted,
+      align: "center", italic: true, rotate: 270,
+    });
+  }
+}
+```
+
+### Waterfall / Bridge Chart
+
+Reach for this whenever showing "what drove the change."
+
+```js
+function addWaterfallChart(slide, { categories, values, palette }) {
+  // values: array of numbers. First = starting total, last = ending total.
+  // Middle values are increments/decrements.
+  const chartColors = values.map((v, i) =>
+    i === 0 || i === values.length - 1
+      ? palette.dark
+      : v >= 0 ? palette.positive : palette.negative
+  );
+
+  slide.addChart(pptx.ChartType.bar, [
+    { name: "Change", labels: categories, values: values },
+  ], {
+    x: 0.8, y: 1.3, w: 11.7, h: 5.2,
+    showValue: true,
+    valueFontSize: 10,
+    catAxisOrientation: "minMax",
+    valAxisHidden: false,
+    valAxisMajorGridlines: { color: "E0E0E0", width: 0.5 },
+    valAxisMinorGridlines: false,
+    chartColors: chartColors,
+    showLegend: false,
+  });
+}
+```
+
+### Comparison Table
+
+```js
+function addComparisonTable(slide, { headers, rows, palette, fonts }) {
+  const tableRows = [
+    headers.map((h) => ({
+      text: h,
+      options: {
+        fontSize: 11, fontFace: fonts.heading, color: palette.light,
+        bold: true, fill: { color: palette.dark }, align: "center",
+        border: { type: "solid", color: palette.dark, pt: 0.5 },
+      },
+    })),
+    ...rows.map((row, i) =>
+      row.map((cell) => ({
+        text: cell,
+        options: {
+          fontSize: 10, fontFace: fonts.body, color: palette.dark,
+          fill: { color: i % 2 === 0 ? palette.light : palette.altRow },
+          border: { type: "solid", color: "E0E0E0", pt: 0.5 },
+          align: "left", valign: "middle",
+        },
+      }))
+    ),
+  ];
+
+  slide.addTable(tableRows, {
+    x: 0.6, y: 1.3, w: 12.1,
+    colW: Array(headers.length).fill(12.1 / headers.length),
+    rowH: [0.45, ...Array(rows.length).fill(0.4)],
+    autoPage: true,
+    autoPageRepeatHeader: true,
+  });
+}
+```
+
+### Roadmap / Timeline
+
+```js
+function addRoadmap(slide, { phases, palette, fonts }) {
+  // phases: [{ label, duration, milestones: string[] }]
+  const phaseW = 11.7 / phases.length;
+  const startX = 0.8;
+
+  phases.forEach((phase, i) => {
+    const x = startX + i * phaseW;
+
+    // Phase bar
+    slide.addShape(pptx.ShapeType.rect, {
+      x: x + 0.05, y: 1.5, w: phaseW - 0.1, h: 0.7,
+      fill: { color: i % 2 === 0 ? palette.accent : palette.accentLight },
+      rectRadius: 0.05,
+    });
+    slide.addText(phase.label, {
+      x: x + 0.1, y: 1.55, w: phaseW - 0.2, h: 0.6,
+      fontSize: 12, fontFace: fonts.heading, color: palette.light,
+      bold: true, align: "center", valign: "middle",
+    });
+
+    // Duration
+    slide.addText(phase.duration, {
+      x: x + 0.1, y: 2.3, w: phaseW - 0.2, h: 0.3,
+      fontSize: 9, fontFace: fonts.body, color: palette.muted,
+      align: "center",
+    });
+
+    // Milestones
+    const msText = phase.milestones.map((m) => ({
+      text: m,
+      options: {
+        fontSize: 10, fontFace: fonts.body, color: palette.dark,
+        bullet: { code: "2022" }, paraSpaceAfter: 4,
+      },
+    }));
+    slide.addText(msText, {
+      x: x + 0.1, y: 2.7, w: phaseW - 0.2, h: 3.5,
+      valign: "top",
+    });
+  });
+}
+```
+
+### Big Number Callout
+
+```js
+function addBigNumber(slide, { metrics, palette, fonts }) {
+  // metrics: [{ value, label, sublabel? }] — 1 to 3 items
+  const count = metrics.length;
+  const cellW = 11.7 / count;
+  const startX = 0.8;
+
+  metrics.forEach((m, i) => {
+    const x = startX + i * cellW;
+
+    slide.addText(m.value, {
+      x, y: 2.0, w: cellW, h: 1.8,
+      fontSize: 54, fontFace: fonts.heading,
+      color: palette.accent, bold: true,
+      align: "center", valign: "bottom",
+    });
+    slide.addText(m.label, {
+      x, y: 3.9, w: cellW, h: 0.6,
+      fontSize: 16, fontFace: fonts.body,
+      color: palette.dark, bold: true,
+      align: "center", valign: "top",
+    });
+    if (m.sublabel) {
+      slide.addText(m.sublabel, {
+        x, y: 4.5, w: cellW, h: 0.5,
+        fontSize: 11, fontFace: fonts.body,
+        color: palette.muted,
+        align: "center",
+      });
+    }
+  });
+}
+```
+
+### Before / After Split
+
+```js
+function addBeforeAfter(slide, { before, after, palette, fonts }) {
+  // before/after: { title, points: string[] }
+  const colW = 5.7;
+
+  [
+    { data: before, x: 0.6, headerColor: palette.muted },
+    { data: after, x: 6.8, headerColor: palette.accent },
+  ].forEach(({ data, x, headerColor }) => {
+    slide.addShape(pptx.ShapeType.rect, {
+      x, y: 1.3, w: colW, h: 0.6,
+      fill: { color: headerColor },
+    });
+    slide.addText(data.title, {
+      x: x + 0.2, y: 1.35, w: colW - 0.4, h: 0.5,
+      fontSize: 14, fontFace: fonts.heading,
+      color: palette.light, bold: true,
+      align: "center", valign: "middle",
+    });
+
+    const points = data.points.map((p) => ({
+      text: p,
+      options: {
+        fontSize: 12, fontFace: fonts.body, color: palette.dark,
+        bullet: true, paraSpaceAfter: 6,
+      },
+    }));
+    slide.addText(points, {
+      x: x + 0.2, y: 2.1, w: colW - 0.4, h: 4.3,
+      valign: "top",
+    });
+  });
+
+  // Vertical divider
+  slide.addShape(pptx.ShapeType.line, {
+    x: 6.65, y: 1.3, w: 0, h: 5.2,
+    line: { color: palette.muted, width: 0.5, dashType: "dash" },
+  });
+}
+```
+
+### Harvey Ball Assessment
+
+Capability or maturity assessment using filled circles. Common for "current state vs target state" or vendor/option scoring across multiple dimensions.
+
+```js
+function addHarveyBallAssessment(slide, { dimensions, entities, ratings, palette, fonts }) {
+  // dimensions: string[] — row labels (e.g. ["Data Quality", "Governance", "Analytics"])
+  // entities: string[] — column headers (e.g. ["Current", "Target"] or ["Vendor A", "Vendor B"])
+  // ratings: number[][] — values 0-4 per dimension per entity (0=empty, 1=quarter, 2=half, 3=three-quarter, 4=full)
+  const harveyBalls = ["○", "◔", "◐", "◕", "●"];
+  const colCount = 1 + entities.length;
+  const dimColW = 3.5;
+  const entityColW = (12.1 - dimColW) / entities.length;
+  const colWidths = [dimColW, ...Array(entities.length).fill(entityColW)];
+
+  // Header row
+  const headerRow = [
+    {
+      text: "Dimension",
+      options: {
+        fontSize: 11, fontFace: fonts.heading, color: palette.light,
+        bold: true, fill: { color: palette.dark }, align: "left",
+        border: { type: "solid", color: palette.dark, pt: 0.5 },
+      },
+    },
+    ...entities.map((e) => ({
+      text: e,
+      options: {
+        fontSize: 11, fontFace: fonts.heading, color: palette.light,
+        bold: true, fill: { color: palette.dark }, align: "center",
+        border: { type: "solid", color: palette.dark, pt: 0.5 },
+      },
+    })),
+  ];
+
+  // Data rows
+  const dataRows = dimensions.map((dim, i) => [
+    {
+      text: dim,
+      options: {
+        fontSize: 10, fontFace: fonts.body, color: palette.dark,
+        fill: { color: i % 2 === 0 ? palette.light : palette.altRow },
+        border: { type: "solid", color: "E0E0E0", pt: 0.5 },
+        align: "left", valign: "middle",
+      },
+    },
+    ...ratings[i].map((r) => ({
+      text: harveyBalls[r],
+      options: {
+        fontSize: 18, fontFace: fonts.body, color: palette.accent,
+        fill: { color: i % 2 === 0 ? palette.light : palette.altRow },
+        border: { type: "solid", color: "E0E0E0", pt: 0.5 },
+        align: "center", valign: "middle",
+      },
+    })),
+  ]);
+
+  slide.addTable([headerRow, ...dataRows], {
+    x: 0.6, y: 1.3, w: 12.1,
+    colW: colWidths,
+    rowH: [0.45, ...Array(dimensions.length).fill(0.45)],
+    autoPage: true,
+    autoPageRepeatHeader: true,
+  });
+
+  // Legend
+  const legendText = harveyBalls.map((b, i) => `${b} ${["None", "Low", "Moderate", "High", "Full"][i]}`).join("    ");
+  slide.addText(legendText, {
+    x: 0.6, y: 6.5, w: 12.1, h: 0.3,
+    fontSize: 9, fontFace: fonts.body, color: palette.muted,
+    align: "left",
+  });
+}
+```
+
+### RACI Matrix
+
+Responsibility assignment matrix. Bold "A" (Accountable) draws the eye to single-point accountability. Common in operating model and org design work.
+
+```js
+function addRACIMatrix(slide, { activities, roles, assignments, palette, fonts }) {
+  // activities: string[] — row labels (e.g. ["Budget approval", "Vendor selection"])
+  // roles: string[] — column headers (e.g. ["CFO", "VP Ops", "PM", "Legal"])
+  // assignments: string[][] — "R", "A", "C", "I", or "" per activity per role
+  const raciColors = {
+    A: palette.accent,
+    R: palette.dark,
+    C: palette.muted,
+    I: palette.muted,
+  };
+  const raciBold = { A: true, R: false, C: false, I: false };
+
+  const actColW = 3.2;
+  const roleColW = (12.1 - actColW) / roles.length;
+  const colWidths = [actColW, ...Array(roles.length).fill(roleColW)];
+
+  // Header row
+  const headerRow = [
+    {
+      text: "Activity",
+      options: {
+        fontSize: 11, fontFace: fonts.heading, color: palette.light,
+        bold: true, fill: { color: palette.dark }, align: "left",
+        border: { type: "solid", color: palette.dark, pt: 0.5 },
+      },
+    },
+    ...roles.map((r) => ({
+      text: r,
+      options: {
+        fontSize: 10, fontFace: fonts.heading, color: palette.light,
+        bold: true, fill: { color: palette.dark }, align: "center",
+        border: { type: "solid", color: palette.dark, pt: 0.5 },
+      },
+    })),
+  ];
+
+  // Data rows
+  const dataRows = activities.map((act, i) => [
+    {
+      text: act,
+      options: {
+        fontSize: 10, fontFace: fonts.body, color: palette.dark,
+        fill: { color: i % 2 === 0 ? palette.light : palette.altRow },
+        border: { type: "solid", color: "E0E0E0", pt: 0.5 },
+        align: "left", valign: "middle",
+      },
+    },
+    ...assignments[i].map((val) => ({
+      text: val || "",
+      options: {
+        fontSize: 13, fontFace: fonts.heading,
+        color: raciColors[val] || palette.muted,
+        bold: raciBold[val] || false,
+        fill: { color: val === "A" ? palette.accentLight : (i % 2 === 0 ? palette.light : palette.altRow) },
+        border: { type: "solid", color: "E0E0E0", pt: 0.5 },
+        align: "center", valign: "middle",
+      },
+    })),
+  ]);
+
+  slide.addTable([headerRow, ...dataRows], {
+    x: 0.6, y: 1.3, w: 12.1,
+    colW: colWidths,
+    rowH: [0.45, ...Array(activities.length).fill(0.4)],
+    autoPage: true,
+    autoPageRepeatHeader: true,
+  });
+
+  // Legend
+  slide.addText(
+    "R = Responsible  |  A = Accountable  |  C = Consulted  |  I = Informed",
+    {
+      x: 0.6, y: 6.5, w: 12.1, h: 0.3,
+      fontSize: 9, fontFace: fonts.body, color: palette.muted,
+      align: "left",
+    }
+  );
+}
+```
+
+### RAG Status Dashboard
+
+Red/Amber/Green traffic light dashboard for steering committee decks. Shows status across multiple workstreams or dimensions (schedule, budget, scope, quality, resources).
+
+```js
+function addRAGDashboard(slide, { workstreams, dimensions, statuses, comments, palette, fonts }) {
+  // workstreams: string[] — row labels (e.g. ["Data Migration", "Integration", "Testing"])
+  // dimensions: string[] — status dimensions (e.g. ["Schedule", "Budget", "Scope", "Quality"])
+  // statuses: string[][] — "R", "A", "G" per workstream per dimension
+  // comments: string[] — one comment per workstream (optional, pass [] to omit)
+  const ragFills = {
+    R: "CC3333",
+    A: "F5A623",
+    G: "4CAF50",
+  };
+  const ragLabels = { R: "●", A: "●", G: "●" };
+
+  const hasComments = comments && comments.length > 0;
+  const wsColW = 2.8;
+  const dimColW = 1.4;
+  const commentColW = hasComments ? 12.1 - wsColW - (dimColW * dimensions.length) : 0;
+  const colWidths = [wsColW, ...Array(dimensions.length).fill(dimColW), ...(hasComments ? [commentColW] : [])];
+
+  // Header row
+  const headerRow = [
+    {
+      text: "Workstream",
+      options: {
+        fontSize: 10, fontFace: fonts.heading, color: palette.light,
+        bold: true, fill: { color: palette.dark }, align: "left",
+        border: { type: "solid", color: palette.dark, pt: 0.5 },
+      },
+    },
+    ...dimensions.map((d) => ({
+      text: d,
+      options: {
+        fontSize: 9, fontFace: fonts.heading, color: palette.light,
+        bold: true, fill: { color: palette.dark }, align: "center",
+        border: { type: "solid", color: palette.dark, pt: 0.5 },
+      },
+    })),
+    ...(hasComments ? [{
+      text: "Commentary",
+      options: {
+        fontSize: 10, fontFace: fonts.heading, color: palette.light,
+        bold: true, fill: { color: palette.dark }, align: "left",
+        border: { type: "solid", color: palette.dark, pt: 0.5 },
+      },
+    }] : []),
+  ];
+
+  // Data rows
+  const dataRows = workstreams.map((ws, i) => {
+    const rowBg = i % 2 === 0 ? palette.light : palette.altRow;
+    return [
+      {
+        text: ws,
+        options: {
+          fontSize: 10, fontFace: fonts.body, color: palette.dark, bold: true,
+          fill: { color: rowBg },
+          border: { type: "solid", color: "E0E0E0", pt: 0.5 },
+          align: "left", valign: "middle",
+        },
+      },
+      ...statuses[i].map((s) => ({
+        text: ragLabels[s] || "",
+        options: {
+          fontSize: 16, color: ragFills[s] || palette.muted,
+          fill: { color: rowBg },
+          border: { type: "solid", color: "E0E0E0", pt: 0.5 },
+          align: "center", valign: "middle",
+        },
+      })),
+      ...(hasComments ? [{
+        text: comments[i] || "",
+        options: {
+          fontSize: 9, fontFace: fonts.body, color: palette.dark,
+          fill: { color: rowBg },
+          border: { type: "solid", color: "E0E0E0", pt: 0.5 },
+          align: "left", valign: "middle",
+        },
+      }] : []),
+    ];
+  });
+
+  slide.addTable([headerRow, ...dataRows], {
+    x: 0.6, y: 1.3, w: 12.1,
+    colW: colWidths,
+    rowH: [0.45, ...Array(workstreams.length).fill(0.45)],
+    autoPage: true,
+    autoPageRepeatHeader: true,
+  });
+
+  // Legend
+  slide.addText([
+    { text: "●", options: { fontSize: 12, color: ragFills.G } },
+    { text: " On Track    ", options: { fontSize: 9, fontFace: fonts.body, color: palette.muted } },
+    { text: "●", options: { fontSize: 12, color: ragFills.A } },
+    { text: " At Risk    ", options: { fontSize: 9, fontFace: fonts.body, color: palette.muted } },
+    { text: "●", options: { fontSize: 12, color: ragFills.R } },
+    { text: " Off Track", options: { fontSize: 9, fontFace: fonts.body, color: palette.muted } },
+  ], {
+    x: 0.6, y: 6.5, w: 12.1, h: 0.3,
+    align: "left",
+  });
+}
+```
+
+### Gantt Timeline
+
+Phased implementation timeline with workstreams, bars, milestones, and dependency arrows. The standard planning slide in consulting. Builds a grid-based Gantt using shapes — no chart API needed.
+
+```js
+function addGanttTimeline(slide, { periods, workstreams, milestones, palette, fonts }) {
+  // periods: string[] — column headers (e.g. ["Q1 '25", "Q2 '25", "Q3 '25", "Q4 '25", "Q1 '26"])
+  // workstreams: [{ label, startIdx, endIdx, color? }] — bar spans across period indices (0-based)
+  // milestones: [{ label, periodIdx, y? }] — diamond markers at specific periods
+  const gridX = 3.0;
+  const gridY = 1.5;
+  const gridW = 9.5;
+  const gridH = 4.8;
+  const labelW = 2.2;
+  const periodW = gridW / periods.length;
+  const rowH = gridH / Math.max(workstreams.length, 1);
+
+  // Period headers
+  periods.forEach((p, i) => {
+    slide.addText(p, {
+      x: gridX + i * periodW, y: 1.15, w: periodW, h: 0.35,
+      fontSize: 9, fontFace: fonts.heading, color: palette.dark,
+      bold: true, align: "center", valign: "middle",
+    });
+  });
+
+  // Header underline
+  slide.addShape(pptx.ShapeType.line, {
+    x: gridX, y: gridY, w: gridW, h: 0,
+    line: { color: palette.dark, width: 1.0 },
+  });
+
+  // Vertical period dividers (light)
+  periods.forEach((_, i) => {
+    if (i > 0) {
+      slide.addShape(pptx.ShapeType.line, {
+        x: gridX + i * periodW, y: gridY, w: 0, h: gridH,
+        line: { color: "E0E0E0", width: 0.5, dashType: "dash" },
+      });
+    }
+  });
+
+  // Workstream rows
+  workstreams.forEach((ws, i) => {
+    const rowY = gridY + i * rowH;
+    const barY = rowY + rowH * 0.3;
+    const barH = rowH * 0.4;
+
+    // Alternating row background
+    if (i % 2 === 1) {
+      slide.addShape(pptx.ShapeType.rect, {
+        x: gridX, y: rowY, w: gridW, h: rowH,
+        fill: { color: palette.altRow },
+        line: { width: 0 },
+      });
+    }
+
+    // Workstream label
+    slide.addText(ws.label, {
+      x: 0.6, y: rowY, w: labelW, h: rowH,
+      fontSize: 10, fontFace: fonts.body, color: palette.dark,
+      bold: true, align: "left", valign: "middle",
+    });
+
+    // Gantt bar
+    const barStartX = gridX + ws.startIdx * periodW;
+    const barW = (ws.endIdx - ws.startIdx + 1) * periodW - 0.1;
+    slide.addShape(pptx.ShapeType.rect, {
+      x: barStartX + 0.05, y: barY, w: barW, h: barH,
+      fill: { color: ws.color || palette.accent },
+      rectRadius: 0.05,
+    });
+
+    // Bar label (inside bar if wide enough, otherwise skip)
+    if (ws.endIdx - ws.startIdx >= 1) {
+      slide.addText(ws.label, {
+        x: barStartX + 0.1, y: barY, w: barW - 0.1, h: barH,
+        fontSize: 8, fontFace: fonts.body, color: palette.light,
+        align: "left", valign: "middle",
+      });
+    }
+  });
+
+  // Milestones (diamond markers)
+  milestones.forEach((ms) => {
+    const msX = gridX + (ms.periodIdx + 0.5) * periodW;
+    const msY = ms.y || (gridY + gridH + 0.15);
+
+    slide.addText("◆", {
+      x: msX - 0.15, y: msY - 0.15, w: 0.3, h: 0.3,
+      fontSize: 14, color: palette.accent,
+      align: "center", valign: "middle",
+    });
+    slide.addText(ms.label, {
+      x: msX + 0.2, y: msY - 0.12, w: 2.5, h: 0.25,
+      fontSize: 8, fontFace: fonts.body, color: palette.dark,
+      align: "left", valign: "middle",
+    });
+  });
+}
+```
+
+---
+
+## Chart Styling Principles
+
+Not specific colors — principles for professional appearance:
+
+- **Clean backgrounds**: Remove default chart borders and backgrounds. White or transparent.
+- **Subtle gridlines**: Horizontal only (`valAxisMajorGridlines: { color: "E0E0E0" }`). Hide vertical gridlines.
+- **Muted axis labels**: Use the palette's secondary text color, not black. Keep font size small (8-9pt).
+- **Data labels on bars/columns**: More readable than forcing people to trace to the axis. `showValue: true, valueFontSize: 10`.
+- **Limited palette**: 2-3 colors from the chosen palette per chart. More dilutes the message.
+- **No legend for single-series**: `showLegend: false` when there's only one data series.
+- **Number formatting**: Use abbreviated formats for large numbers (e.g. "$1.2M" not "$1,200,000"). Apply `valAxisNumFmt` or format data labels.
+
+---
+
+## Adapting to Context
+
+Choose styling based on the situation:
+
+| Context | Approach |
+|---------|----------|
+| **Client-branded deck** | Ask for or infer brand colors; use as the palette. Match the client's font if known. |
+| **Firm-branded deck** | Use the consulting firm's visual identity if known. |
+| **Neutral / independent** | Pick a palette that fits the topic. |
+| **Projected presentation** | Larger fonts (min 18pt body), fewer elements per slide, high contrast. |
+| **Leave-behind document** | Denser layout allowed, smaller fonts (12-14pt body), more detail per slide. |
+| **Analytical deep-dive** | Dense exhibits, detailed tables, tighter margins. |
+| **Recommendation / big idea** | Generous white space, large type, one message per slide. |
+
+Slide density varies by purpose. An analytical slide can pack data. A recommendation slide should breathe. Don't apply one density everywhere.
diff --git a/management-consulting/skills/project-closeout/SKILL.md b/management-consulting/skills/project-closeout/SKILL.md
new file mode 100644
index 00000000..5bec5ae5
--- /dev/null
+++ b/management-consulting/skills/project-closeout/SKILL.md
@@ -0,0 +1,517 @@
+---
+name: project-closeout
+description: Execute consulting engagement closure including deliverable handover, knowledge transfer, lessons learned, and administrative wrap-up. Use when completing consulting engagements, concluding transformation initiatives, transitioning from project to business-as-usual, or formalizing project wrap-up. Covers closure readiness assessment, client acceptance, knowledge transfer planning, retrospectives, financial reconciliation, and follow-on opportunity identification.
+---
+
+# Project Closeout
+
+Manage the full consulting engagement closeout process: ensuring deliverables are handed over, knowledge is transferred, lessons are captured, and the client is equipped to operate independently. Treat closure as a structured workstream, not an afterthought.
+
+## Before You Begin
+
+Closeout depends on what was delivered and what remains. Confirm before proceeding:
+- What is the engagement size and duration (to calibrate closeout effort)?
+- What deliverables were produced and what is their acceptance status?
+- Is this a successful completion, early termination, or transition to BAU?
+- Don't generate deliverable lists, financial reconciliation figures, or benefits data. Ask what exists and work from what the user provides.
+
+---
+
+## Closeout Effort Estimation
+
+Allocate closeout effort explicitly. Teams consistently underestimate this.
+
+| Engagement Size | Typical Closeout Effort | Duration |
+|---|---|---|
+| Small (< $500K, < 6 months, < 10 people) | 3-5% of total engagement cost | 2-3 weeks |
+| Medium ($500K-$2M, 6-12 months, 10-30 people) | 5-8% of total engagement cost | 4-6 weeks |
+| Large ($2M+, 12+ months, 30+ people) | 8-12% of total engagement cost | 6-10 weeks |
+| Multi-workstream transformation | 10-15% of total engagement cost | 8-12 weeks |
+
+Build closeout into the project plan from the start. Backloading it into the last week guarantees it gets rushed or skipped.
+
+---
+
+## RACI for Closeout Activities
+
+Assign clear ownership before closeout begins. Ambiguity here is how things fall through cracks.
+
+| Activity | Engagement Manager | Workstream Leads | Client Sponsor | PMO |
+|---|---|---|---|---|
+| Closure readiness assessment | A | R | C | I |
+| Deliverable handover | A | R | C | I |
+| Client acceptance sign-off | R | C | A | I |
+| Knowledge transfer sessions | A | R | I | C |
+| Benefits tracking handover | R | C | A | I |
+| Stakeholder transition | R | R | A | I |
+| Lessons learned / retrospective | A | R | C | C |
+| Financial reconciliation | A | I | C | R |
+| Documentation archive | I | R | I | A |
+| Resource release | A | R | I | R |
+
+R = Responsible, A = Accountable, C = Consulted, I = Informed
+
+---
+
+## Step 1: Assess Closure Readiness
+
+Before initiating closure, verify that completion criteria are actually met.
+
+### Closure Type
+
+Determine which type of closure applies:
+
+| Type | Description | Requirements |
+|---|---|---|
+| Successful Completion | All objectives met | Full closure process |
+| Early Termination | Project cancelled | Document rationale, partial handover |
+| On Hold | Suspended temporarily | Document conditions for restart |
+| Rolled into BAU | Integrated into operations | Full handover, no formal end |
+
+### Completion Criteria
+
+Walk through each criterion systematically:
+
+- All deliverables complete and accepted
+- Engagement objectives achieved (with evidence)
+- Budget reconciled
+- Stakeholder sign-off obtained
+- Resources released or redeployed
+- Contracts closed or transitioned
+- Final status report approved
+- All project issues resolved or documented
+- Change requests documented and closed
+- Vendors/contractors notified
+- Equipment/assets returned
+- Access credentials revoked
+- Team feedback collected
+
+If any criterion is unmet, determine whether it blocks closure or can be resolved as part of the closeout process.
+
+---
+
+## Step 2: Handover Deliverables
+
+Transfer all project outputs to the client with proper documentation.
+
+### Deliverables Inventory
+
+For each deliverable, document:
+- Final version number
+- Storage location
+- Handover status (complete/pending)
+- Client acceptance status
+
+### Handover Packages
+
+Prepare two packages:
+
+**User Handover Package**
+- User guide (how to use deliverables)
+- Quick start guide
+- FAQ document
+- Training materials
+
+**Technical Handover Package**
+- Technical documentation and system specs
+- Architecture diagrams
+- API documentation (if applicable)
+- Support contacts and escalation paths
+
+### Client Acceptance
+
+Formalize acceptance with a clear record. Keep it concise: the goal is an unambiguous "yes, we accept."
+
+```
+Project Closure: [Project Name] | Client: [Client Organization] | Date: [Date]
+
+DELIVERABLES ACCEPTED:
+1. [Deliverable] - [Status]
+2. [Deliverable] - [Status]
+
+Client confirms all deliverables received and acceptable.
+Outstanding items (if any) have an agreed resolution path.
+
+Client Representative: _________________ Date: __________
+Consulting Representative: _________________ Date: __________
+```
+
+---
+
+## Step 3: Conduct Knowledge Transfer
+
+The goal is client independence. When the consulting team leaves, the client should be able to operate, maintain, and evolve what was built.
+
+### Knowledge Transfer Methods
+
+| Method | Best For |
+|---|---|
+| Live workshop | Complex processes, interactive Q&A |
+| Recorded video | Procedural knowledge, repeatable tasks |
+| Written documentation | Reference materials, runbooks |
+| Interactive guides | Step-by-step tasks in software |
+| Async Q&A | Distributed teams, follow-up questions |
+
+### Knowledge Transfer Plan
+
+For each knowledge area, define:
+- Topic and scope
+- Transfer method
+- Recipient (by name and role)
+- Scheduled date
+- Completion status
+
+### Session Documentation
+
+For each knowledge transfer session, capture:
+- Duration and presenter
+- Attendees
+- Key points covered
+- Questions addressed (with answers)
+- Whether follow-up is required
+
+### Operations Documentation
+
+Ensure these documents exist and are handed over:
+
+| Document | Purpose |
+|---|---|
+| Run Book | Day-to-day operations procedures |
+| Support Guide | Troubleshooting common issues |
+| Escalation Matrix | Who to contact for what |
+| Contact List | Key contacts with roles |
+
+### Support Transition
+
+Define the post-project support model:
+- **Transition period**: Start and end dates
+- **Hypercare support**: Duration and scope (typically 2-4 weeks)
+- **BAU support**: Ongoing contact details
+- **Escalation path**: How to raise issues after the team has left
+
+---
+
+## Step 4: Benefits Tracking Handover
+
+Benefits don't stop being measured when the consulting team leaves. This is where most engagements fail: the team departs, and nobody owns measurement.
+
+### Benefits Ownership Transfer
+
+For each benefit identified in the business case, document:
+
+| Benefit | Baseline | Target | Current | Owner (Post-Departure) | Measurement Method | Frequency |
+|---|---|---|---|---|---|---|
+| e.g., Process cycle time | 14 days | 5 days | 7 days | VP Operations | System report #X | Monthly |
+| e.g., Cost savings | $0 | $8M/yr | $3M (annualized) | CFO | P&L line item | Quarterly |
+
+### What to Hand Over
+
+- **Measurement methodology**: How each benefit is calculated, including data sources and formulas
+- **Tracking tools/dashboards**: Access, ownership, and maintenance responsibility
+- **Reporting cadence**: Who reports to whom, how often, in what format
+- **Escalation triggers**: At what point does underperformance require intervention (e.g., benefit realization < 70% of target at 6 months)
+- **Sustainability risks**: What could erode benefits over time (staff turnover, process drift, system changes)
+
+### Benefits Realization Timeline
+
+Map expected benefit realization against milestones:
+- **0-3 months post-departure**: Quick wins should be fully realized
+- **3-6 months**: Process improvements showing measurable impact
+- **6-12 months**: Full run-rate benefits expected
+- **12+ months**: Strategic/transformational benefits maturing
+
+Include a scheduled check-in at 3 and 6 months post-departure to review realization against plan.
+
+---
+
+## Step 5: Stakeholder Relationship Transition
+
+Consulting teams build relationships that the client organization needs to sustain. Plan the transition explicitly.
+
+### Relationship Mapping
+
+For each key stakeholder relationship:
+- **Stakeholder**: Name and role
+- **Current consulting contact**: Who has the relationship
+- **Transition to**: Client-side person who will own the relationship going forward
+- **Handover actions**: Introduction meeting, context briefing, shared history notes
+- **Timing**: When the handover conversation happens (not on the last day)
+
+### Stakeholder Communication Plan
+
+| Stakeholder Group | Message | Channel | Timing | Owner |
+|---|---|---|---|---|
+| Executive sponsor | Engagement complete, benefits summary, ongoing support model | 1:1 meeting | 2 weeks before departure | Engagement Manager |
+| Steering committee | Final status, transition plan, open items | Formal presentation | 3-4 weeks before departure | Engagement Manager |
+| Working team leads | KT completion, support contacts, escalation paths | Working session | 1-2 weeks before departure | Workstream Leads |
+| End users | What's changing, where to get help, training resources | Email + town hall | 1 week before departure | Client Change Lead |
+| IT / Operations | Support handover, system access, monitoring | Technical meeting | 2 weeks before departure | Technical Lead |
+| Vendors / Partners | Contract transitions, new contact points | Formal letter + call | 3-4 weeks before departure | PMO |
+
+### Transition Principles
+
+- Start stakeholder communications 4-6 weeks before departure, not the week of
+- The client sponsor should hear the closeout narrative from you first, not discover it in a meeting
+- Introduce client-side successors to key relationships before the consulting team leaves
+- Document informal knowledge: "When you need X, talk to Y" guidance that lives in people's heads
+
+---
+
+## Step 6: Document Lessons Learned
+
+Lessons learned are the most commonly skipped and most valuable part of project closure. Run a proper retrospective.
+
+### Retrospective Formats
+
+Choose a format that fits the team:
+
+**Start / Stop / Continue**
+- Start: Practices to begin on future engagements
+- Stop: Practices to discontinue
+- Continue: Practices that worked well
+
+**4Ls (Liked, Learned, Lacked, Longed For)**
+- Liked: What worked well and should be repeated
+- Learned: New knowledge gained during the engagement
+- Lacked: What was missing (tools, skills, information)
+- Longed For: What we wish we had
+
+**Sailboat Method**
+- Wind (what propelled us forward)
+- Anchor (what slowed us down)
+- Rocks (risks we hit or narrowly avoided)
+- Island (the destination we were aiming for)
+
+### Capture Structure
+
+Document lessons in two categories:
+
+**What Went Well**
+
+For each success factor, capture the area, what specifically worked, and the evidence (a concrete example, not a vague impression).
+
+**What Could Be Improved**
+
+For each challenge, capture what didn't work and a specific recommendation for improvement. "Communication could be better" is not useful. "Weekly status calls should include the IT lead, not just the business sponsor" is.
+
+### Process Improvement Recommendations
+
+Translate lessons into prioritized recommendations:
+- The recommendation itself
+- Priority (high/medium/low)
+- Expected benefit
+- Implementation effort
+
+### Retrospective Session
+
+Run the session with:
+- All team members (consulting and client-side where appropriate)
+- A neutral facilitator if possible
+- Documented key insights with attribution
+- Specific quotes that capture important observations
+- Action items for the practice or firm, not just the project
+
+---
+
+## Step 7: Finalize Administrative Closure
+
+### Financial Closure
+
+Reconcile all financial obligations:
+
+| Item | Details |
+|---|---|
+| Total Budget | Original approved amount |
+| Actual Spend | What was actually spent |
+| Variance | Amount and percentage |
+| Final Invoice | Amount and payment status |
+| Final Expenses | Submission status |
+
+### Resource Release
+
+For each team member, confirm:
+- Assignment end date
+- Release status
+- Next assignment or availability
+- Performance feedback completed
+
+### Contract Closure
+
+For each vendor or subcontractor:
+- Final payment amount and status
+- Contract formally closed
+
+### Documentation Archive
+
+Archive all project documentation with appropriate retention periods. At minimum: project charter, governance docs, final deliverables, lessons learned, financial records, and contracts.
+
+### Team Recognition
+
+Acknowledge individual contributions. This is not a formality. People remember how engagements ended.
+
+### Team Performance Reviews
+
+Distinct from annual performance reviews and more valuable because they capture performance in context. Conduct these before the team disbands, not weeks later when memory fades.
+
+**For each team member, assess**:
+
+| Dimension | Rating (1-5) | Evidence | Development Recommendation |
+|---|---|---|---|
+| Technical quality of work | _ | Specific deliverables or analyses | What to build on or improve |
+| Client relationship management | _ | Interactions observed, client feedback | Growth areas |
+| Team contribution | _ | Collaboration, mentoring, initiative | Next engagement fit |
+| Problem-solving under pressure | _ | How they handled ambiguity, setbacks, tight deadlines | Stretch opportunities |
+| Communication (written and verbal) | _ | Deliverable quality, presentation skill, stakeholder updates | Development suggestions |
+
+**Process**:
+- EM writes the review within one week of engagement end (not three months later as part of an annual cycle)
+- Share the review in a 30-minute 1:1 conversation, not just in writing
+- Include specific examples, not just ratings. "Your analysis of the customer cohort data in Week 4 changed the direction of the engagement" is useful. "Good analytical skills" is not.
+- Ask the team member for their self-assessment first. Divergence between self-assessment and your assessment is the most productive conversation topic.
+- Feed findings into the firm's staffing and development systems so the next engagement manager benefits
+
+**Why this matters**: Consulting team members are evaluated on engagement performance. If you don't do this, they either get no feedback (bad) or get feedback from someone who wasn't there (worse).
+
+---
+
+## Step 8: Final Project Report
+
+Produce a closure report that serves as the definitive record of the engagement.
+
+### Report Structure
+
+```
+Project Closure Report: [Project Name]
+
+Executive Summary
+  [Overview: objectives, outcomes, key metrics, overall assessment]
+
+1. Project Overview
+   - Original objectives
+   - Scope (included and excluded)
+   - Timeline by phase
+
+2. Deliverables
+   - Completed deliverables with status and location
+   - Handover confirmation
+
+3. Financial Summary
+   - Budget vs. actual (total and by category)
+   - Variance explanation
+
+4. Benefits
+   - Benefits achieved to date (quantified)
+   - Expected future benefits (with measurement plan)
+   - Benefits tracking ownership (who measures what, post-departure)
+
+5. Lessons Learned
+   - Success factors
+   - Improvement areas
+   - Specific recommendations for future engagements
+
+6. Team Recognition
+   - Key contributions
+
+7. Appendices
+   - Deliverable inventory
+   - Change log
+   - Final risk register
+   - Stakeholder list
+```
+
+---
+
+## Regulated Industry Considerations
+
+Certain industries impose specific closeout requirements beyond standard practice. Failing to address these creates compliance risk that outlasts the engagement.
+
+### Financial Services
+
+- **Regulatory documentation**: Ensure all compliance-related deliverables meet regulatory standards (OCC, FCA, APRA, etc.) and are archived per retention requirements (typically 7+ years)
+- **Audit trail**: Document all decisions, approvals, and changes with timestamps. Regulators may review these years later
+- **Model risk management**: If the engagement produced quantitative models, ensure SR 11-7 / SS1/23 compliance documentation is complete (model inventory, validation reports, limitation disclosures)
+- **Data handling**: Confirm all client data is returned or destroyed per data handling agreements. Obtain written confirmation
+
+### Healthcare
+
+- **HIPAA / PHI**: Verify all protected health information has been returned or securely destroyed. Document the chain of custody
+- **Clinical documentation**: Any deliverables affecting clinical workflows must be validated against relevant standards (Joint Commission, CMS)
+- **BAA closure**: If a Business Associate Agreement was in place, formally close it and confirm data disposition
+
+### Government / Public Sector
+
+- **Contract closeout requirements**: Follow FAR Part 4.804 (US federal) or equivalent procurement regulations. Government contracts have specific closeout timelines and documentation requirements
+- **Security clearance**: Ensure facility and personnel clearances are properly deactivated or transferred
+- **FOIA considerations**: Assume project documentation may be subject to freedom of information requests. Flag anything that should be marked as proprietary or exempt
+- **Audit readiness**: Government auditors (GAO, IG) may review engagement files years after completion. Archive accordingly
+
+### Cross-Industry
+
+- **Data retention**: Know the retention period before archiving. Financial services and healthcare often require 7-10 years; government contracts may require longer
+- **Third-party attestations**: If the engagement involved SOC 2, ISO 27001, or similar certifications, ensure findings are properly documented and handed to the relevant compliance team
+
+---
+
+## Early Termination / Bad Ending Playbook
+
+Not every engagement ends well. Client dissatisfaction, budget cuts, leadership changes, strategy pivots, or genuine delivery failures can all terminate an engagement early. How you handle the ending determines whether the client relationship (and your reputation) survives.
+
+### Termination Types and Responses
+
+| Scenario | Your Priority | Key Actions |
+|---|---|---|
+| Client pulls budget (external pressure, not dissatisfaction) | Preserve relationship, close cleanly | Express understanding. Deliver whatever is complete in usable form. Offer to resume if funding returns. Don't fight it. |
+| Client is dissatisfied with delivery quality | Damage control, relationship salvage | Acknowledge the concern without being defensive. Offer a concrete remediation plan (at reduced or no cost). Involve your leadership. |
+| Leadership change kills the project | Protect team, maintain firm reputation | Document what was delivered and its value. Brief the new leadership if they'll take the meeting. Accept the decision gracefully. |
+| Scope was wrong from the start | Honest reckoning | Acknowledge the misscoping. Deliver what's useful from work completed. Offer a re-scoped approach if the underlying need still exists. |
+| Mutual agreement to stop | Clean handover | Treat as normal closeout but on compressed timeline. No hard feelings, but document everything. |
+
+### The Early Termination Checklist
+
+Regardless of cause, these actions are non-negotiable:
+
+1. **Agree on the narrative.** Align with the client sponsor on how this will be described internally and externally. "Mutually agreed to pause pending strategic review" is better than conflicting stories.
+2. **Deliver what you have.** Even if incomplete, package current work products in usable form. Don't hold deliverables hostage over unpaid fees (that's what the contract and legal team are for).
+3. **Settle the finances promptly.** Agree on final billing quickly. Protracted fee disputes after a bad ending make everything worse. If there's genuine disagreement, propose a reasonable compromise and move on.
+4. **Conduct an internal post-mortem.** What went wrong? Was it avoidable? Was there a red flag at proposal stage? Feed this back into your qualification process. The most expensive lesson is one you don't learn from.
+5. **Handle the team.** Early termination is demoralizing. Debrief with the team honestly. Reassign people quickly. Don't let them sit on the bench wondering what they did wrong (especially if they didn't do anything wrong).
+6. **Don't burn the bridge.** The person who terminated the engagement may hire you again in a different role, at a different company, five years from now. Leave them with the impression that you handled a difficult situation with professionalism.
+
+### When to Walk Away First
+
+Rarely discussed but sometimes necessary. Situations where the firm should initiate termination:
+
+- Client asks you to produce misleading findings or suppress unfavorable results
+- Client environment is abusive to your team (sustained hostility, unreasonable demands, personal attacks)
+- Scope has expanded beyond contractual terms and the client refuses to adjust
+- You discover information during the engagement that creates a conflict of interest
+- Continued association poses reputational risk to the firm
+
+In these cases, raise the concern with your firm's leadership, document the issue, and follow your firm's protocol for disengagement. Do it promptly and professionally.
+
+## Follow-On Opportunity Identification
+
+While closing the engagement, identify potential follow-on work. This is not about selling; it's about recognizing where the client still has unresolved needs that surfaced during the engagement.
+
+Look for:
+- Problems identified but out of scope for this engagement
+- Capabilities the client still lacks
+- Adjacent areas where similar methodology would apply
+- Implementation support for recommendations not yet actioned
+- Periodic health checks or maturity assessments
+
+Document these with enough context that a business development conversation can happen naturally, not as a sales pitch embedded in a closure meeting.
+
+---
+
+## Key Principles
+
+- Don't skip lessons learned. They're the primary mechanism for organizational learning.
+- Ensure handover is complete before reducing support. Premature withdrawal creates client frustration and damages the relationship.
+- Get formal sign-off on acceptance. Ambiguity about whether the engagement is "done" causes problems months later.
+- Release resources promptly. Holding people on a closed project wastes their time and the firm's money.
+- Follow up on post-project commitments. Nothing erodes trust faster than broken promises after the team leaves.
+- Celebrate team success before closing. The ending colors how people remember the entire engagement.
+- Assign benefits tracking ownership before you leave. Unowned metrics stop being measured.
+- Start stakeholder communications weeks before departure, not days.
+- Conduct a proper retrospective, not just paperwork. A lessons learned document nobody reads is theater.
diff --git a/management-consulting/skills/thought-leadership/SKILL.md b/management-consulting/skills/thought-leadership/SKILL.md
new file mode 100644
index 00000000..f1fe5d06
--- /dev/null
+++ b/management-consulting/skills/thought-leadership/SKILL.md
@@ -0,0 +1,284 @@
+---
+name: thought-leadership
+description: Develop thought leadership content including points of view, white papers, case studies, and industry briefs. Use when building credibility through published content, creating assets for business development, developing reusable knowledge from engagement experience, or positioning a practice as a trusted authority on a topic. Covers the full arc from thesis development through research, structuring, drafting, and quality review.
+---
+
+# Thought Leadership
+
+Create thought leadership content that demonstrates genuine expertise: points of view, white papers, case studies, industry briefs, and research reports. Take clear positions backed by evidence, not generic surveys of a topic.
+
+## Before You Begin
+
+Thought leadership credibility depends on what the firm can actually claim. Before drafting:
+- What engagement experience can the firm reference? What industries, what scale, what results?
+- What is the firm's actual point of view on this topic? Has anything been published before?
+- Who is the target audience and what is the business purpose (lead generation, credibility, recruitment)?
+- Never fabricate first-person experience claims like "across 40+ engagements we've observed..." unless the user provides that data. Instead, use conditional framing: "organizations that do X tend to see Y" or "research and practitioner evidence suggests..." Only claim specific firm experience if the user provides it.
+
+---
+
+## Asset Types
+
+Different content types serve different purposes. Match the asset to the goal.
+
+| Type | Best For | Total Length | Density |
+|---|---|---|---|
+| Point of View | Taking a position on a trend or issue | 800-1,500 words (1-3 pages) | High density. Every sentence earns its place. No throat-clearing. |
+| White Paper | Deep analysis of a topic with recommendations | 3,000-6,000 words (5-15 pages) | Moderate density. Room for evidence and examples, but no padding. |
+| Case Study | Showcasing engagement results | 600-1,200 words (1-3 pages) | Story-driven. Lead with results, then explain how. |
+| Industry Brief | Current state and outlook for an industry | 1,500-3,000 words (3-5 pages) | Data-dense. Charts and tables do heavy lifting. |
+| Research Report | Original research findings | 5,000-10,000 words (10-20 pages) | Methodology-driven. Evidence first, interpretation second. |
+
+---
+
+## Step 1: Define the Asset
+
+Before writing anything, establish what you're building and why.
+
+Capture:
+
+- **Type**: Which asset type above
+- **Topic**: The subject area
+- **Thesis**: The core argument in one sentence. This is the most important element. If you can't state it in one sentence, the thinking isn't sharp enough yet.
+- **Target Audience**: Who will read this (C-suite, functional leaders, industry practitioners)
+- **Business Purpose**: What this achieves (credibility, lead generation, client education, recruitment)
+
+**Strong vs. weak thesis statements:**
+
+The thesis is the single sentence that determines whether the piece is worth reading. Most consulting thought leadership fails here by being either too obvious or too vague.
+
+*Point of View examples:*
+
+- Weak: "Digital transformation requires strong change management." (Everyone knows this. No one would disagree. No reason to read further.)
+- Weak: "The future of work is changing." (True of every era. Says nothing specific.)
+- Strong: "Companies that embed AI into their core operating model within the next 18 months will open a capability gap that laggards cannot close through later adoption." (Specific, time-bound, debatable, has implications.)
+- Strong: "The biggest barrier to supply chain resilience isn't technology or cost; it's that most companies optimize for efficiency and resilience simultaneously, achieving neither." (Names a specific, non-obvious tension.)
+
+*White Paper examples:*
+
+- Weak: "Organizations should consider multiple factors when evaluating cloud migration." (What factors? Why? This is a table of contents, not a thesis.)
+- Strong: "Most cloud migrations deliver 40-60% of projected savings because they replicate on-premises architecture in the cloud rather than redesigning for cloud-native economics." (Quantified, causal, actionable.)
+
+*Case Study examples:*
+
+- Weak: "A major retailer improved its supply chain with our help." (So what? How much? What was different about the approach?)
+- Strong: "By shifting from forecast-driven to demand-sensing replenishment, a $4B retailer cut inventory carrying costs by 23% while improving in-stock rates from 94% to 98.5%." (Specific results, specific method.)
+
+The test: if your thesis could appear in any competitor's publication without anyone noticing, it's not distinctive enough.
+
+---
+
+## Step 2: Build the Evidence Base
+
+Strong thought leadership is research-backed, not opinion-dressed-as-insight. Build three types of evidence:
+
+### Market Intelligence
+
+Gather external data: industry reports, academic research, expert commentary. For each source, capture the key finding and how it supports (or challenges) the thesis.
+
+### Engagement Experience
+
+The most distinctive evidence comes from actual client work. This is what separates consulting thought leadership from journalism or academic research. Identify patterns across engagements: what you've observed, how often, in which industries, and what it means. Always anonymize. The patterns are the insight; the client names are irrelevant.
+
+Frame engagement evidence with specificity: "Across 30+ supply chain transformations over the past three years, we've observed that..." is credible. "In our experience..." is hand-waving.
+
+### Counterarguments
+
+Map the opposing views. For each, assess its validity (strong, moderate, weak) and prepare a response. Thought leadership that ignores counterarguments reads as advocacy, not analysis.
+
+How to handle counterarguments effectively:
+
+- **Strong counterargument**: Acknowledge it directly, concede the valid part, then explain why your thesis still holds ("This is true in stable markets. In volatile environments, the calculus changes because...")
+- **Moderate counterargument**: Name it, explain why it's partially right, and show the conditions under which your position is more useful
+- **Weak counterargument**: Don't spend time demolishing straw men. It signals insecurity. Either skip it or address it in a sentence
+
+Example of counterargument handling (strong):
+
+"The obvious objection: won't faster adoption mean higher failure rates? The data suggests otherwise. Companies that moved early on cloud adoption between 2015-2018 had lower total cost of migration than late movers, primarily because they migrated simpler workloads first and built institutional capability before tackling complex systems. Speed of decision is not speed of execution."
+
+### Data Points
+
+Collect specific statistics with their sources and context. "According to [Source], X% of [initiatives] failed to meet their stated objectives" is useful... specific, sourced, and verifiable. "Digital transformation is hard" is not.
+
+---
+
+## Step 3: Structure the Content
+
+Each asset type has a proven structure. Don't reinvent it. Word count targets are approximate; the point is proportional emphasis, not word counting.
+
+### Point of View Structure (800-1,500 words total)
+
+1. **The Shift** (150-250 words) -- What is changing in the market or industry. Open with the most surprising or counterintuitive data point, not with context-setting.
+2. **Why It Matters** (150-250 words) -- Impact on organizations and leaders. Quantify the stakes.
+3. **The Opportunity** (200-400 words) -- What leading organizations are doing. Use 2-3 specific examples (anonymized client work or named public companies).
+4. **Our Perspective** (200-400 words) -- What we believe should be done and why. This is the thesis section. Take a clear position.
+5. **Getting Started** (100-200 words) -- 3-5 practical first steps, specific enough to act on Monday morning.
+
+### White Paper Structure (3,000-6,000 words total)
+
+1. **Executive Summary** (300-500 words) -- Key findings and recommendations. Must stand alone. A reader who only reads this section should get the thesis, the evidence, and the recommended action.
+2. **The Challenge** (400-800 words) -- Problem definition with data. Quantify the cost of the status quo.
+3. **Current Landscape** (500-1,000 words) -- State of the market. What's been tried, what's worked, what hasn't.
+4. **Analysis** (800-1,500 words) -- Deep dive into the issue. This is where the original thinking lives.
+5. **Framework** (500-1,000 words) -- Proposed approach or model. Must be actionable, not just conceptual.
+6. **Case Examples** (400-800 words) -- 2-3 illustrative examples (anonymized). Focus on the pattern, not the story.
+7. **Recommendations** (300-500 words) -- 5-7 specific, actionable recommendations ranked by impact and feasibility.
+8. **About the Authors** (50-100 words) -- Credibility and contact.
+
+### Case Study Structure (600-1,200 words total)
+
+1. **Client Context** (100-200 words) -- Industry, size, situation (anonymized). Enough for the reader to see themselves.
+2. **The Challenge** (100-200 words) -- Problem the client faced. Quantify the pain.
+3. **Our Approach** (200-400 words) -- Methodology and key activities. What was distinctive about the approach, not a generic process description.
+4. **Results** (100-200 words) -- Quantified outcomes. Lead with the headline number. Include timeline.
+5. **Key Takeaways** (100-200 words) -- 3-4 generalizable lessons. What would you tell someone facing the same situation?
+
+### Industry Brief Structure (1,500-3,000 words total)
+
+1. **Industry Snapshot** (200-400 words) -- Key metrics and trends. Table or chart format is ideal.
+2. **Forces Shaping the Industry** (400-800 words) -- 3-5 drivers and disruptors with evidence for each.
+3. **Implications** (400-800 words) -- What this means for industry participants. Segment by player type if relevant.
+4. **Outlook** (200-400 words) -- Near-term (12 months) and medium-term (3-5 years) forecast with specific predictions.
+5. **Recommended Actions** (200-400 words) -- 5-7 strategic priorities, rank-ordered.
+
+### Research Report Structure (5,000-10,000 words total)
+
+1. **Executive Summary** (500-800 words) -- Headline findings. 5-7 key takeaways, each in one sentence.
+2. **Methodology** (300-500 words) -- How the research was conducted. Sample size, approach, limitations.
+3. **Findings** (2,500-5,000 words) -- Data and analysis, section by section. Lead each section with the finding, then show the evidence.
+4. **Discussion** (800-1,500 words) -- Interpretation and implications. What the findings mean for the thesis.
+5. **Recommendations** (500-800 words) -- What to do with this knowledge.
+6. **Appendices** -- Full data tables, methodology details.
+
+---
+
+## Step 4: Draft the Content
+
+### Opening Hooks
+
+The first 2-3 sentences determine whether anyone reads further. Most consulting thought leadership opens with context-setting ("In today's rapidly evolving business landscape...") which is a reliable way to lose the reader.
+
+Effective opening techniques:
+
+**Lead with a counterintuitive finding:**
+"The companies spending the most on cybersecurity are not the most secure. Our analysis of 200 enterprise security programs found an inverse correlation between security budget growth and breach reduction after the first $10M in annual spend."
+
+**Open with a specific, surprising number:**
+"It takes the average Fortune 500 company 14 months to fill a Chief Digital Officer role. By the time they start, the strategy they were hired to execute is already obsolete."
+
+**Start with what everyone gets wrong:**
+"The conventional wisdom on pricing optimization is backwards. Most companies start by analyzing willingness-to-pay. The companies capturing 15-20% more revenue start by analyzing willingness-to-lose: which customers will actually leave, and at what price point?"
+
+**Name the tension directly:**
+"Every CEO we've spoken to in the past year says they want to move faster. Every operating model we've assessed in the past year is designed to prevent exactly that."
+
+Openings to avoid:
+- "In today's rapidly changing..." (content-free)
+- "It's no secret that..." (then why are you writing about it?)
+- "As organizations increasingly..." (slow, passive, generic)
+- "The world of [X] is undergoing a transformation..." (could open any article about anything)
+- "Now more than ever..." (every era says this; it never adds information)
+
+**The discomfort test**: Take a position the reader might disagree with. If everyone would nod along, the thesis isn't sharp enough. The best thought leadership makes the reader uncomfortable before persuading them. A safe opening that offends no one also interests no one.
+
+### The Consulting Voice
+
+Consulting thought leadership has a distinctive voice that separates it from journalism, academia, and marketing. It says: "We have done this work, repeatedly, and here is what we've learned."
+
+**Rules for the consulting voice:**
+
+1. **Claim the experience directly, but only what's real.** "Across 40+ operating model transformations" or "In our work with financial services clients over the past five years." Don't hedge with "many companies find that..." when you can say "we've seen this pattern in 7 of the last 10 engagements." However, only claim specific engagement counts or first-person experience if the firm can substantiate them. When generating content without verified engagement data, use evidence-based framing instead: "Organizations that successfully navigate this transition typically..." or "Research and practitioner evidence suggests..." Fabricating engagement statistics (e.g., "across 40+ transformations we observed...") for published content is a credibility risk. If the user provides specific firm experience to reference, use it; otherwise, frame insights as industry patterns, not personal claims.
+
+2. **Be specific about scale.** "Most companies" is weak. "In 23 of 30 organizations we assessed" is credible. Numbers don't need to be exact (use "30+" or "roughly two-thirds") but they need to be there. When you don't have the firm's actual numbers, use conditional framing: "Firms that have conducted 20+ transformations in this space report that..." rather than asserting a count as your own.
+
+3. **Name what surprised you.** The most credible thing a consultant can write is "We expected X but found Y." It signals genuine inquiry, not marketing dressed as analysis.
+
+4. **Use "we believe" deliberately.** Reserve it for genuine opinion that goes beyond the data. "We believe the next 18 months will determine market position for a generation" is a belief. "Organizations with flatter structures make faster decisions" is a finding. Don't confuse them.
+
+5. **Avoid consultant cliches.** "Best practice," "world-class," "synergies," "leverage" (as a verb), "holistic," "robust," "unlock value," "drive transformation," "navigate complexity" -- these signal lazy thinking and TED-talk sheen. Say the specific thing. Instead of "best practice," describe what the best performers actually do. Instead of "holistic approach," name the three things you'd integrate. Instead of "unlock value," say what the value is and where it comes from.
+
+6. **Show your work.** Describe the analysis, not just the conclusion. "When we mapped decision latency against organizational layers, the correlation broke at layer 6" is more convincing than "Too many layers slow decisions."
+
+7. **Be willing to say "it depends" and then actually say what it depends on.** Nuance is not weakness. "This works for companies above $500M in revenue with existing digital infrastructure; below that threshold, a different approach is needed" is more useful than a universal recommendation.
+
+### Visual Elements
+
+Recommend visual elements to strengthen the content:
+
+- **Charts and graphs**: Quantify key points. Prefer one clear chart over three cluttered ones.
+- **Frameworks and diagrams**: Visualize concepts and models. Only when the visual adds understanding that text can't.
+- **Pull quotes**: Highlight key insights for scanning. Use the single most provocative sentence from each major section.
+- **Callout boxes**: Provide practical tips or supplementary detail.
+
+---
+
+## Client Approval for Content Referencing Engagement Work
+
+Any thought leadership that draws on client engagement experience (even anonymized) needs a clear approval process. Getting this wrong creates legal exposure and destroys client trust.
+
+**Approval tiers**:
+
+| Content Type | Approval Required | Process |
+|---|---|---|
+| Anonymized pattern ("Across 30+ transformations, we observed...") | Internal review only | Engagement manager confirms no identifying details. Legal/risk reviews if the pattern is industry-specific enough to narrow identification. |
+| Anonymized case study (specific client situation, disguised) | Client approval required | Send the draft to the client sponsor. Allow 2 weeks for review. Accept redactions without argument. |
+| Named case study (client identified) | Written client approval required | Formal approval from client's communications/legal team, not just the sponsor's verbal OK. Include final publication form for sign-off. |
+| Quoting client personnel | Written approval from the individual and their communications team | Provide exact quote in context. Allow the individual to revise. Some organizations prohibit employee quotes entirely. |
+
+**Practical guidance**:
+- Build approval into the timeline. Don't finish the piece and then discover the client needs 4 weeks for legal review.
+- When in doubt, over-anonymize. Change the industry, geography, company size, or time period. The insight is in the pattern, not the specifics.
+- Some clients have blanket policies prohibiting any reference to the engagement, including anonymized ones. Check the engagement contract for publication restrictions.
+- If a client declines, accept it. Pushing back damages the relationship more than the content is worth.
+
+## Practice-Level Coordination
+
+Multiple partners publishing on the same topic without coordination creates a risk of contradictory viewpoints appearing under the firm's name. This is embarrassing at best and brand-damaging at worst.
+
+**Coordination mechanisms**:
+
+- **Topic registry**: Maintain a simple list of who is publishing what, when, and the core thesis. Review quarterly at practice meetings. Two partners can disagree, but they should know they're doing it.
+- **Thesis alignment check**: Before a piece enters drafting, circulate the one-sentence thesis to practice leadership. Flag conflicts with existing published positions. Genuine intellectual disagreement is fine if handled deliberately (e.g., "a counterpoint" framing). Accidental contradiction is not.
+- **Retired positions**: When the firm's view on a topic evolves, explicitly retire the old position. Remove or update outdated content. A client who reads your 2024 white paper and your 2026 white paper should see evolution, not confusion.
+- **Cross-practice coordination**: When a topic spans practices (e.g., "AI in financial services" touches both the AI practice and the FS practice), assign a lead practice and require the other to review before publication.
+
+This doesn't need to be bureaucratic. A shared spreadsheet and a quarterly 30-minute review is enough for most firms. The goal is awareness, not approval by committee.
+
+## Step 5: Review and Quality Check
+
+### Content Quality
+
+- Thesis is clear and defensible
+- Evidence supports the argument
+- Counterarguments are addressed (not ignored or strawmanned)
+- Recommendations are actionable (could be started this quarter, not "adopt a culture of...")
+- Examples are anonymized appropriately
+- Data is current and properly sourced
+- No proprietary client information disclosed
+- The piece says something a competitor would not or could not say
+
+### Writing Quality
+
+- Opening hooks the reader within the first two sentences
+- Structure is logical and easy to follow
+- Every paragraph earns its place (cut anything that's "nice context" but doesn't advance the argument)
+- Technical terms are defined on first use
+- Transitions are smooth
+- Conclusion reinforces the key message and ends with a clear call to action
+
+### The "So What?" Test
+
+Read each section and ask: "So what?" If the answer isn't obvious, the section is missing its synthesis. Every section should end with a sentence that states why the preceding analysis matters for the reader's decisions.
+
+---
+
+## Key Principles
+
+- Strong thought leadership takes a clear position. Wishy-washy conclusions signal weak thinking.
+- Use engagement experience as evidence but always anonymize client details.
+- Quality over quantity. One excellent piece beats five mediocre ones.
+- Timeliness matters. Connect to current industry conversations.
+- Involve practitioners. The best insights come from people doing the work.
+- Test the thesis with clients before publishing. Their reaction is the best validation.
+- Update or retire assets when the market shifts. Stale thought leadership undermines credibility.
+- The best thought leadership makes the reader feel slightly uncomfortable. If everyone already agrees with you, you haven't said anything worth reading.
diff --git a/management-consulting/skills/workshop-facilitation/SKILL.md b/management-consulting/skills/workshop-facilitation/SKILL.md
new file mode 100644
index 00000000..5e1b242c
--- /dev/null
+++ b/management-consulting/skills/workshop-facilitation/SKILL.md
@@ -0,0 +1,437 @@
+---
+name: workshop-facilitation
+description: Design and facilitate consulting workshops including strategy offsites, design thinking sessions, innovation sprints, and discovery workshops. Use when planning client-facing facilitated sessions, conducting stakeholder alignment workshops, running prioritization exercises, or designing working sessions for strategy development. Covers agenda design, facilitation guides, pre-work, and follow-through.
+---
+
+# Workshop Facilitation
+
+Design, plan, and run effective strategy workshops, design thinking sessions, and innovation sprints. This covers the design and facilitation of structured working sessions at any point in an engagement. For the broader engagement launch process (kickoff, discovery, stakeholder mapping), see engagement-setup. The full lifecycle covered here: objective-setting, participant planning, pre-work design, methodology selection, agenda design, facilitation techniques, and post-workshop follow-through.
+
+## Before You Begin
+
+Workshop design must fit the actual context. Confirm before designing:
+- What is the workshop's objective and what decisions or outputs are expected?
+- Who are the participants (seniority mix, number of people, in-person vs. virtual)?
+- How much time is available and what format constraints exist?
+- Don't generate participant names, organizational dynamics, or pre-existing tensions. Ask who will be in the room and what the group dynamics look like.
+
+---
+
+## Workshop Planning
+
+### Define Objectives
+
+Before designing anything, answer these questions:
+
+1. **Why is this workshop needed?** — What decision, alignment, or output does it serve?
+2. **What does success look like?** — Concrete deliverables, not "productive discussion"
+3. **Who needs to be in the room?** — And who explicitly does not
+4. **What format fits the constraints?** — In-person, virtual, hybrid, duration
+
+### Participant Planning
+
+Map your participants before designing the agenda. The design should accommodate who's actually in the room.
+
+| Dimension | Why It Matters |
+|-----------|---------------|
+| Decision makers | They must approve outcomes — design for their decision points |
+| Influencers | They shape discussion — give them structured airtime |
+| Subject matter experts | They provide input — design activities that extract their knowledge |
+| Skeptics | They'll challenge ideas — plan for productive challenge, not shutdown |
+| Introverts | They won't volunteer — design silent-first activities |
+| Remote participants | They're disadvantaged by default — over-design for their inclusion |
+
+### Managing the CEO / Most Senior Leader
+
+The CEO (or most senior person in the room) requires deliberate role management. Their default behavior shapes the entire session.
+
+**When they should speak:**
+- Opening: setting context, signaling importance, defining the decision they need from the group
+- Closing: confirming decisions, signaling commitment, assigning accountability
+- When explicitly invited to share a perspective the group needs
+
+**When they should NOT speak:**
+- During ideation and brainstorming (kills divergent thinking)
+- During initial sharing rounds (anchors everyone to their position)
+- When evaluating options (others will self-censor around their preference)
+
+**How to manage it:**
+- Brief the CEO before the session: "Your silence during brainstorming is a gift to the group. You'll have dedicated time to react and decide."
+- Use "juniors first" sharing order during evaluations
+- Use anonymous voting before revealing preferences
+- If the CEO jumps in too early: "Let's capture that. I'd like to hear from the rest of the group first, then we'll come back to synthesize."
+- Give the CEO a specific role (e.g., "guardian of the customer perspective") to channel their energy productively
+
+### Pre-Work Design
+
+Well-designed pre-work shifts cognitive load out of the workshop and into individual preparation time. It makes workshop time dramatically more productive.
+
+**Types of pre-work and when to use them:**
+
+| Type | Purpose | Best For | Timing |
+|------|---------|----------|--------|
+| Reading pack | Shared context and baseline knowledge | Strategy offsites, design reviews | Send 5-7 days before; keep under 20 pages |
+| Survey / questionnaire | Surface perspectives before the room, identify alignment gaps | Alignment workshops, retrospectives | Send 7-10 days before; allow 3-5 days to complete |
+| Individual reflection prompts | Force thinking before groupthink takes over | Innovation sessions, strategy decisions | Send 3-5 days before; 3-5 focused questions max |
+| Data analysis or homework | Produce artifacts the workshop will build on | Working sessions, design sprints | Send 5-7 days before; assign specific outputs |
+| Stakeholder interviews | Gather input from people not in the room | Discovery workshops, strategy alignment | Complete 1-2 weeks before |
+
+**Using pre-work outputs in the session:**
+- Open with a summary of pre-work findings (5-10 min) — "Here's what we heard"
+- Use survey results to frame the agenda: "70% of you said X, but 30% disagree — that's what we're here to resolve"
+- Have participants share their individual reflections in pairs before group discussion
+- Never ignore pre-work. If people did it and you don't reference it, they won't do it next time
+
+**Pre-work completion reality:** Expect 60-70% completion. Design the session so it works without pre-work but is better with it. Have a 5-minute "catch-up" option for those who didn't do it.
+
+### Format Considerations
+
+| Format | Best For | Watch Out For |
+|--------|----------|---------------|
+| In-person | Deep collaboration, trust-building, complex decisions | Travel cost, scheduling difficulty |
+| Virtual | Global teams, speed, accessibility | Fatigue after 90 min, harder to read the room |
+| Hybrid | Mixed locations, real-time interaction | Remote participants becoming second-class citizens |
+| Async-first | Reflection time, global time zones, pre-work | Loses energy and spontaneity |
+
+For virtual and hybrid sessions: test all technology beforehand, have dedicated tech support, and build in 50% more breaks than you think you need.
+
+---
+
+## Workshop Methodologies
+
+Select based on what you're trying to achieve, not what sounds impressive.
+
+### Design Thinking
+
+Best for: User-centered innovation, new product concepts, service design
+
+```
+EMPATHIZE → DEFINE → IDEATE → PROTOTYPE → TEST
+    │           │         │         │         │
+ [User       [Point of   [Brain-    [Build    [Learn
+  Research]  View]      storm]     It]       & Iterate]
+```
+
+Half-day minimum. Full day preferred. Requires real user data or customer insights as input — don't run design thinking on assumptions.
+
+### Design Sprint (Google Ventures model)
+
+Best for: Fast decision-making, validating ideas quickly, team alignment on direction
+
+```
+DAY 1: Map      DAY 2: Sketch   DAY 3: Decide  DAY 4: Prototype  DAY 5: Test
+[Understand]    [Concepts]      [Choose]       [Build]           [Validate]
+```
+
+Compressed variants (3-day, 2-day) work but sacrifice depth. The 5-day version produces real user-tested prototypes. Requires a dedicated sprint team and a clear decider.
+
+### Strategy Offsite (1-Day)
+
+Best for: Annual planning, strategic direction, competitive positioning
+
+```
+CONTEXT → ANALYSIS → OPTIONS → DECISION → COMMITMENT
+  │          │          │          │           │
+[Where    [Where     [Where    [Where     [How
+ we are]   we are]    we can    we will]    we get
+            (deep)    go]        (choose)    there]
+```
+
+Full day minimum. The most common failure mode is spending all day on context and analysis, then rushing decisions in the last hour. Protect decision time.
+
+### Strategy Offsite (2-Day)
+
+Best for: Comprehensive strategy development, complex multi-option decisions, building deep alignment
+
+The 2-day format is substantially more effective than a single day for complex strategic decisions. Overnight processing produces materially better Day 2 thinking.
+
+**Day 1: Diverge (Context + Options)**
+
+```
+09:00  Opening & Objectives                              [30 min]
+09:30  External Context (market, competitive, customer)   [90 min]
+11:00  Break                                              [15 min]
+11:15  Internal Context (performance, capabilities, gaps) [75 min]
+12:30  Lunch                                              [60 min]
+13:30  Strategic Options Generation                       [90 min]
+15:00  Break                                              [15 min]
+15:15  Options Deep Dive (breakout groups)                [90 min]
+16:45  Day 1 Synthesis & Overnight Reflection             [30 min]
+17:15  Close (dinner optional but valuable)
+```
+
+**Day 2: Converge (Evaluation + Commitment)**
+
+```
+09:00  Overnight Reflections (round-robin, 2 min each)    [30 min]
+09:30  Options Evaluation Against Criteria                 [90 min]
+11:00  Break                                               [15 min]
+11:15  Decision Session (structured debate + vote)         [75 min]
+12:30  Lunch                                               [45 min]
+13:15  Execution Planning (initiatives, owners, timeline)  [90 min]
+14:45  Break                                               [15 min]
+15:00  Commitment & Accountability                         [60 min]
+16:00  Close                                               [15 min]
+```
+
+**Multi-day design principles:**
+- **End Day 1 with divergence, not convergence.** Let people sleep on unresolved options. Overnight processing is real and valuable. Don't force premature closure.
+- **Day 2 energy management.** Day 2 starts slower. The overnight reflection round serves double duty: it surfaces new thinking AND it warms the group back up. Don't skip it.
+- **Dinner on Day 1 is a design element, not a social nicety.** Informal conversation over dinner resolves tensions and builds alignment that structured sessions can't. Seat people strategically (mix functions, pair skeptics with advocates).
+- **Protect Day 2 decision time.** The temptation is to rehash Day 1 analysis. Set a hard rule: "Day 2 is about choosing and committing, not re-analyzing."
+- **Synthesis between days.** The facilitation team should spend 30-60 minutes after Day 1 close synthesizing themes, identifying unresolved tensions, and adjusting the Day 2 agenda accordingly.
+
+### Innovation Workshop
+
+Best for: Generating new ideas, breakthrough thinking, challenging assumptions
+
+```
+WARM-UP → FRAME → GENERATE → EVALUATE → PRIORITIZE → PLAN
+   │         │         │          │           │         │
+[Get      [Define   [Many      [Screen    [Select    [Next
+ creative]  the      ideas]      ideas]     best]      actions]
+            challenge]
+```
+
+Half day to full day. Quantity of ideas matters early; quality filtering comes later. Warm-up exercises are not optional — they shift people out of operational thinking.
+
+### Discovery Workshop
+
+Best for: Understanding current state at project kickoff, surfacing stakeholder perspectives
+
+**Suggested flow (half day):**
+1. **Business Context** (60 min) — Company overview, strategic priorities, current challenges
+2. **Stakeholder Perspectives** (60 min) — Round-robin sharing, theme identification, priority ranking
+3. **Journey Mapping** (60 min) — Map key processes, identify pain points and gaps, spot quick wins
+4. **Opportunity Framing** (60 min) — Problem statement development, success criteria, next steps
+
+Key outputs: current state assessment, challenge prioritization, opportunity shortlist, project charter draft.
+
+### Strategy Alignment Workshop
+
+Best for: Getting leadership aligned on strategic direction when there are competing views
+
+**Suggested flow (full day):**
+
+Morning — Current State (3 hours):
+1. **External Reality** (60 min) — Market trends, competitive forces, customer insights
+2. **Internal Reality** (60 min) — Performance review, capability assessment, digital maturity
+3. **Strategic Choices** (60 min) — Options review, trade-off decisions, preliminary direction
+
+Afternoon — Future State (3 hours):
+4. **Strategic Direction** (60 min) — Strategic narrative, strategic pillars, success definition
+5. **Execution Priorities** (60 min) — Key initiatives, resource allocation, timeline
+6. **Commitment** (60 min) — Role assignments, governance, next steps
+
+Key outputs: agreed strategic direction, strategic pillars, initiative priorities, action assignments.
+
+---
+
+## Agenda Design
+
+### Timing Principles
+
+- **Never exceed 90 minutes** without a break for in-person sessions
+- **Never exceed 60 minutes** without a break for virtual sessions
+- **Allocate 60% to activities**, 20% to transitions and breaks, 20% to opening/closing/synthesis
+- **Front-load divergent thinking** (morning energy is better for creative work)
+- **Schedule decisions after breaks** (fresh minds make better choices)
+- **Build in buffer** — every activity takes 10-15% longer than planned
+
+### Standard Agenda Template
+
+```
+08:30  Registration & Coffee
+09:00  Opening & Objectives          [Facilitator]     [30 min]
+09:30  Context Setting               [Presenter]       [30 min]
+10:00  Activity 1                    [Facilitator]     [60 min]
+11:00  Break                                           [15 min]
+11:15  Activity 2                    [Facilitator]     [90 min]
+12:45  Lunch                                           [45 min]
+13:30  Activity 3                    [Facilitator]     [90 min]
+15:00  Break                                           [15 min]
+15:15  Synthesis & Decisions         [Facilitator]     [60 min]
+16:15  Next Steps & Close            [Facilitator]     [30 min]
+```
+
+### Activity Design Template
+
+For each activity, define:
+- **Purpose**: Why this activity exists (ties back to a workshop objective)
+- **Method**: How it works step by step
+- **Inputs**: What participants need to have or know before starting
+- **Outputs**: What tangible thing is produced
+- **Time**: Duration with step-by-step breakdown
+- **Facilitation notes**: Common failure modes, what to watch for
+
+---
+
+## Facilitation Techniques
+
+### Opening
+
+Set the tone in the first 5 minutes. Cover:
+- Why we're here (purpose, not logistics)
+- What we'll produce by the end (specific deliverables)
+- Ground rules (be present, build on ideas, respect time, all voices matter)
+- For virtual/hybrid: quick tech check, camera expectations
+
+### Managing Group Dynamics
+
+| Challenge | Response |
+|-----------|----------|
+| Dominant participant | "Let's hear from someone who hasn't spoken yet." Or use structured rounds. |
+| Quiet group | Silent writing before discussion. Go around the room explicitly. |
+| Conflict between participants | Acknowledge both views. "You're both raising important points. Let's capture both and evaluate them against our criteria." |
+| Off-topic tangent | "Great point — I'm going to capture that on the parking lot so we don't lose it. Let's stay focused on [current topic]." |
+| Energy drop | Switch format. Stand up. Do a quick poll. Take an unscheduled break. |
+| Time pressure | "We need to move forward. Let's capture remaining thoughts on sticky notes and focus on decisions." |
+| HiPPO effect (highest-paid person dominates) | Use anonymous voting. Have juniors share before seniors. Pre-collect input. Brief the senior leader beforehand on their role. |
+
+### Decision-Making Methods
+
+| Method | When to Use | How It Works |
+|--------|-------------|--------------|
+| Dot voting | Ranking many options quickly | Each person gets 3-5 dots, places them on preferred options |
+| Thumbs up/down/sideways | Quick alignment check | Thumbs up = agree, down = disagree, sideways = concerns |
+| Multi-voting + discussion | Complex decisions with trade-offs | Vote first, then discuss the top 3-5 options |
+| Gradients of agreement | When consensus matters | 1-5 scale from "fully support" to "can't live with it" |
+| Decision rights matrix (RACI) | When authority is unclear | Clarify who decides, who's consulted, who's informed |
+
+### Transitions
+
+Script your transitions. The story arc of a workshop breaks when transitions are sloppy.
+
+- Between activities: "Here's what we just accomplished [summary]. Now we're going to build on that by [next activity purpose]."
+- At midpoint: "We're halfway through. So far we've [summary of outputs]. Here's what we need to accomplish in the second half."
+- Before decisions: "We've done the analysis. Now it's time to make choices. Here's what we're deciding and how."
+
+### Closing
+
+Never let a workshop trail off. Structured close:
+1. **Summary of outputs** — what we produced
+2. **Decisions made** — what was decided, by whom
+3. **Action items** — specific actions, owners, due dates (not vague commitments)
+4. **Feedback** — quick round or one-word checkout
+5. **Clear end** — thank participants, state next communication
+
+---
+
+## Hybrid Workshop Design
+
+Hybrid is the hardest format to facilitate well. Remote participants are disadvantaged by default — the facilitator must actively compensate.
+
+**Non-negotiable practices:**
+- Camera on for all participants (room camera showing full room, individual cameras for remote)
+- Dedicated "remote advocate" in the room who monitors chat and speaks on behalf of remote participants
+- Digital whiteboard as the primary workspace (not a physical whiteboard that remote participants can't see)
+- All materials shared digitally before the session
+- Explicit turn-taking that includes remote voices ("Before we continue, let me check in with our remote participants")
+- Polls and voting through digital tools (not hand-raising that remote can't see)
+
+---
+
+## Post-Workshop Follow-Through
+
+The real workshop happens after. Outcomes without follow-through are theater.
+
+### Immediate (same day)
+- Send thank-you to participants
+- Share key takeaways and photos/screenshots of outputs
+- Confirm action items with owners
+
+### Within one week
+- Distribute full workshop summary (decisions, action items, key outputs)
+- Share all materials and digital artifacts
+- Send recording if virtual
+- Schedule follow-up meetings for action items
+
+### Within two weeks
+- Track action item progress
+- Gather feedback on workshop effectiveness
+- Document lessons learned for future workshops
+
+### Workshop Summary Template
+
+```
+# Workshop Summary: [Name]
+Date: [Date]
+
+## Participants
+[Names and roles]
+
+## Objectives and Whether Achieved
+[Objective — achieved/partially/not achieved]
+
+## Key Outputs
+[Deliverables produced]
+
+## Decisions Made
+[Decision — rationale — decision maker]
+
+## Action Items
+| Action | Owner | Due Date | Status |
+|--------|-------|----------|--------|
+
+## Parking Lot (items deferred)
+[Topics captured but not addressed]
+
+## Next Steps
+[Next milestone, date, owner]
+```
+
+---
+
+## Workshop Risk Register
+
+Plan for what goes wrong. The facilitator who says "that won't happen" hasn't run enough workshops.
+
+### Common Risks and Responses
+
+| Risk | Impact | Response |
+|------|--------|----------|
+| Scoring/voting produces a tie | Decision stalls, group loses momentum | Pre-define the tiebreaker before voting starts. Options: decision-maker breaks the tie, weighted criteria re-score on the tied items only, or "which option do we regret NOT pursuing?" reframe |
+| Hostile or disruptive participant | Derails discussion, intimidates others | Name the behavior privately at a break: "I need your expertise, but the way you're pushing back is shutting others down." If it continues, redirect: "Let's capture that as a dissenting view and move to the next topic." Do not engage in a public battle |
+| Senior sponsor ignores the pre-brief | CEO speaks first, anchors the room, kills divergent thinking | Gently interrupt early: "Thank you — I'd love to come back to that after we hear from the group." At the next break, re-brief: "The session will be more productive if we hear other voices first. You'll have dedicated time to react." |
+| One breakout group produces nothing useful | Uneven outputs undermine synthesis | Assign a process observer to each breakout. Check in at the midpoint. If a group is stuck, give them a concrete prompt or redistribute members |
+| Pre-work completion is near zero | Session starts from cold, agenda timing breaks | Have a 10-minute "crash course" version of the essential context. Adjust the agenda: shorten activities that depend on pre-work, extend context-setting. Never shame people for not doing it |
+| Key decision-maker leaves early | Decisions can't be ratified | Get their input on decision items first. Front-load their participation. If they leave before decisions, get explicit delegation: "Who has your authority to decide on items 3 and 4?" |
+
+### Technology Failure Backup
+
+Technology will fail. Have a plan that doesn't require it.
+
+| Technology | Failure Mode | Backup |
+|------------|-------------|--------|
+| Projector / screen | Won't connect, bulb dies | Print key slides (6-up on paper). Facilitate from a whiteboard. The slides are your notes, not the session |
+| Digital whiteboard (Miro, Mural) | Platform down, participants can't access | Physical sticky notes and a wall. Photograph results. Carry a pack of sticky notes and markers to every session |
+| Video conferencing (hybrid) | Audio/video drops for remote participants | Dial-in phone number as backup. Assign an in-room buddy to text updates. If remote connection is fully lost, pause, solve, or reschedule the remote portion |
+| Polling / voting tool | Tool crashes mid-vote | Paper ballots or hand-raising. For anonymous voting: have people write on cards, collect face-down |
+| Wi-Fi | Network down | Mobile hotspot. Pre-download all materials. Any activity requiring real-time internet access should have an offline alternative |
+
+**General rule**: If a single technology failure can derail your entire session, your session design is fragile. Every digital activity should have a 30-second analog fallback you've already thought through.
+
+### Cultural Facilitation Differences
+
+Facilitation norms vary across cultures. These are tendencies, not rules, but ignoring them produces bad sessions.
+
+| Dimension | Western / Low-Context Tendency | East Asian / High-Context Tendency | Adaptation |
+|-----------|-------------------------------|-----------------------------------|------------|
+| Disagreement | Direct, in the room | Indirect, often after the session | In high-context cultures, build in 1:1 channels (breaks, written input) for dissent. Don't interpret silence as agreement |
+| Speaking order | Whoever has something to say | Deference to seniority | Use explicit rounds ordered by seniority (junior-first or senior-first depending on goal) rather than open floor |
+| Decision-making | Vote and move on | Consensus-building, may need multiple sessions | Budget more time for convergence. A "decision" in the room may need offline confirmation |
+| Brainstorming | Verbal, spontaneous | Written, considered | Default to silent-first activities globally (they work everywhere). Never rely solely on "shout it out" brainstorming |
+| Time | Agenda is a commitment | Agenda is a guide | In relationship-oriented cultures, protect relationship-building time (longer breaks, meals) and flex the agenda |
+
+**Bottom line**: When in doubt, use structured, written-first activities with explicit turn-taking. They work across all cultural contexts. Open-floor, verbal-first formats are the ones most likely to fail cross-culturally.
+
+---
+
+## Behavioral Principles
+
+- **Energy management is facilitation.** Monitor group energy. Switch formats, take breaks, or introduce movement when energy dips. A tired group produces nothing useful.
+- **Silence is productive.** Allow 10-15 seconds of silence after questions. Resist the urge to fill every pause. The best insights often come after the obvious answers have been exhausted.
+- **Design for introverts first.** Silent writing before group sharing ensures all voices are captured, not just the loudest. "Think, write, share" is almost always better than "who wants to go first?"
+- **Follow-through is the deliverable.** Prioritize actionable commitments over polished in-session outputs. A workshop that produces beautiful artifacts but no follow-up actions was a waste of everyone's time.
+- **Timebox ruthlessly.** Workshops that run over lose energy and credibility. End on time. If you're running behind, cut content — never cut the closing or decision-making.
+- **Have backup activities ready.** If an activity falls flat or finishes early, you need alternatives. Preparation separates good facilitators from great ones.