AI Board Lite

View saved version →

---
name: actionables
description: Turns a meeting transcript into decisions, action items with an owner, a due date and the quote behind each one, and per-person follow-up drafts. Marks owners and dates nobody said as missing, and drafts follow-ups without sending them. Use when the user shares a transcript and asks "what are the action items", "what did we agree", "wat zijn de actionables", "wat waren mijn acties".
---

# Actionables

Nobody leaves a meeting knowing who owes what. That is the problem this solves.
The classic way to get it wrong is to invent owners and dates the room never
said. So every action item traces back to a line in the transcript. Ownership
that was not said out loud becomes `UNASSIGNED`. It is never inferred from
whoever spoke last. The same goes for dates. You draft follow-ups. You never
send them.

## Ground rules

- Work only from the transcript the user provides. Nothing else counts as a
  source.
- Every decision and every action item carries the quote it came from.
- No stated owner means `UNASSIGNED`. No stated date means "no date agreed".
  Never infer either.
- Answer in the language the user writes in. Draft each follow-up in the
  language of the person it is for, if the transcript makes that clear.
  The example below is in English; translate its headings too.

## When to use

The user shares a meeting transcript, or points at one, and asks "what are the
action items", "what did we agree", "who owes what", "wat zijn de actionables",
"wat waren mijn acties".

## Steps

1. **Get the text.** Accept a pasted transcript, or a `.txt`, `.vtt`, `.srt`,
   `.md` or `.docx` file. Read the file with whatever this environment offers.
   For `.docx`, a converter such as `markitdown` works if it is installed. If
   there is no way to read the file, ask the user to paste the text or export
   it as `.txt`. Audio is out of scope: ask for the transcript the meeting
   platform produced.
2. **Find out who the user is** in the transcript, if it is not obvious. Ask
   once. Their own items get pulled out at the end.
3. **Read for four things:** decisions taken, action items, open questions and
   things explicitly deferred. Extract every action item as owner, task, due
   date and source quote.
4. **Check speaker labels.** If the transcript has no speaker names, say so at
   the top: owners can then only come from what was said ("Marieke, can you…"),
   never from who was talking.
5. **Draft one follow-up per person**, containing only their own items, short
   enough to send as a chat message. Present them in the chat for the user to
   copy.
6. **Offer to keep it for next time.** If this environment can write files,
   offer to save the result as `Meetings/<YYYY-MM-DD> · <meeting name>.md` in a
   folder the user chooses. Explain the reason in one sentence: next time,
   meeting prep can read this note instead of the user pasting it again. Do
   not write anything without the user saying yes.

## Output format

```markdown
## Decisions (2)
- The pilot runs in Service, not Sales. · "let's do service, that's where the volume is"
- Budget waits until the pilot shows numbers. · "no budget before we see data"

## Action items (5)
| # | Owner | Action | Due | Source |
|---|---|---|---|---|
| 1 | You | Confirm the pilot team to everyone | 2026-08-07 | "I'll confirm it Friday" |
| 2 | Marieke | Budget frame for the pilot | 2026-08-14 | "give me two weeks" |
| 3 | UNASSIGNED | Review data access before go-live | no date agreed | nobody claimed this |

**Yours: 1 item, due Friday 2026-08-07.**

## Open questions
- Who signs off on go-live? Raised, not answered.

## Follow-up drafts · copy and send yourself
**To Marieke:** Hi Marieke, from today's meeting: the budget frame for the
Service pilot. You said two weeks, so 14 August. Let me know if that moves.
```

## Limits

- Text in, text out. No audio transcription.
- This skill never sends email, chat messages or invites. If the user asks
  whether the follow-ups went out, the honest answer is that only they know.
- A transcript without speaker labels gives weaker owners. Flag it, do not
  guess.
- Relative dates ("next Friday") are resolved against the meeting date. If the
  meeting date is unknown, ask for it or keep the words as spoken.

View saved version →

---
name: analyze-spreadsheet
description: Reads an Excel or CSV file and explains what the numbers say in plain language. Finds the biggest movements, variances against budget or last period, outliers and formula or data problems, each with its sheet and cell reference. Flags gaps instead of filling them. Use for "what does this spreadsheet tell me", "explain these numbers", "wat zie je in deze excel", "waar zitten de afwijkingen".
---

# Analyze Spreadsheet

A spreadsheet answers a question nobody wrote down. This skill writes the
question down, answers it in three sentences, and shows the cells that prove
each sentence. Anyone should be able to check every claim by clicking the
cell it points to.

## Ground rules

- Every number in the answer is read from the file and carries its sheet and
  cell or range, for example `P&L!D14` or `Sales!B2:B13`.
- If you calculate something (a difference, a growth rate, a total), say how,
  and show the inputs with their cell references.
- Never fill a gap. Empty cells, `#REF!`, `#DIV/0!` and text in a number column
  are findings, not things to fix silently.
- Answer in the language the user writes in.
  The example below is in English; translate its headings too.

## When to use

The user shares an `.xlsx`, `.xls` or `.csv` and asks "what does this tell me",
"explain these numbers", "where are the variances", "wat zie je in deze excel",
"waar zitten de afwijkingen", "klopt dit".

## Steps

1. **Open the file** with whatever this environment offers (Python with
   `openpyxl` or `pandas`, or a built-in reader). Read formulas as well as
   values where possible. If the file cannot be read here, ask the user to
   export the relevant sheet as CSV or paste it.
2. **Map the file first:** sheets, what each one holds, the period it covers,
   units and currency. Report anything ambiguous (thousands or units? which
   year?) and ask before you interpret.
3. **Ask what the user wants to know** if the request is open. Default: what
   changed, what is off plan, and what looks wrong.
4. **Find the movements:** the largest changes against the previous period and
   against budget or forecast if the file has one, in absolute and relative
   terms.
5. **Check the data:** formula errors, hard-coded numbers inside formula
   ranges, totals that do not add up, duplicates, missing months.
6. **Write the answer:** three sentences of conclusion first, then the
   evidence table, then the data problems, then the questions the numbers
   raise but cannot answer.

## Output format

```markdown
## In three sentences
Revenue is on budget for the year, but only because of one large order in
March. Personnel costs are 9 percent over budget since June. The forecast tab
still uses last year's prices.

## Evidence
| Finding | Value | Where | How |
|---|---|---|---|
| March revenue spike | €612k vs €240k average | `P&L!D5` vs `P&L!B5:M5` | average of the other 11 months |
| Personnel over budget | +€84k Jun–Sep | `P&L!H9:K9` vs `Budget!H9:K9` | sum of monthly differences |

## Data problems
- `Forecast!C4:C15` are typed numbers inside a column of formulas.
- `P&L!N12` is `#REF!`: the full-year total for marketing is missing.

## Questions the file cannot answer
- Is the March order a one-off, or a new contract?
```

## Limits

- The analysis covers what is in the file. Context that is not in it (a
  one-off order, a price change) is asked, not assumed.
- Very large files may need to be narrowed to the relevant sheets first.
- This skill reads and explains. It changes the file only if the user asks
  for a corrected copy, and then it saves a new file and leaves the original
  untouched.

View saved version →

---
name: build-deck
description: Turns notes, a brief or a document into a board-ready presentation. Builds the storyline first (one message per slide, headline titles), then produces a .pptx when the environment can create files, or a slide-by-slide outline to paste. Use for "make a deck from this", "turn these notes into slides", "maak een presentatie hiervan", "zet dit in een powerpoint".
---

# Build Deck

Executives do not read slides, they read slide titles. So a deck is a
storyline first and a file second. Every slide makes one point, and its title
says that point as a full sentence. "Q3 revenue" is a label. "Q3 revenue grew
on two customers, not on the market" is a title.

## Ground rules

- Use only the material the user provides. Every number on a slide comes from
  that material, quoted exactly. A number you cannot source does not go on a
  slide.
- One message per slide. If a slide needs two titles, it is two slides.
- No filler slides: no "Agenda" for fewer than eight slides, no "Thank you",
  no "Questions?".
- Answer in the language the user writes in, and build the deck in that
  language unless they ask otherwise.

## When to use

The user shares notes, a memo, a report, figures or a rough outline and asks
for a presentation: "make a deck from this", "turn these notes into slides",
"I need five slides for the board", "maak een presentatie hiervan", "zet dit in
een powerpoint".

## Steps

1. **Pin down three things** if they are not clear from the request: who the
   audience is, what decision or reaction the deck should get, and how many
   slides there is room for. Ask once, in one message. If the user wants you
   to just go ahead, assume a board audience and at most eight slides, and say
   so.
2. **Write the storyline as titles only.** Open with the answer (the
   recommendation or the main finding), then the supporting points, then the
   ask. Read the titles in order: on their own they must tell the whole story.
3. **Show the storyline to the user** as a numbered list of titles before
   building anything. Adjust if they want changes.
4. **Fill each slide** with only what proves its title: three bullets at most,
   one chart or one table at most, the source of every number in small text at
   the bottom.
5. **Build the file.** If this environment can run Python with `python-pptx`
   (or another way to write `.pptx`), create the deck: a title slide, the
   content slides, a clean layout with plenty of white space, readable font
   sizes (titles 28pt or larger, body 16pt or larger) and the source line on
   every slide that carries a number. Save it only after the user agreed to the
   storyline, and tell them where it is. If files cannot be created here,
   deliver the full outline per slide in a form they can paste into
   PowerPoint, Keynote or Google Slides.
6. **End with a short checklist** of what the user still has to add or check:
   missing numbers, a chart they need to supply, a claim that needs a source.

## Output format

```markdown
## Storyline (6 slides)
1. Move the pilot to Service: it has the volume and a willing team
2. Service handles twice the tickets Sales does, on the same headcount
3. The team lead has already volunteered two people
4. Risk: data access is not settled, and nobody owns it yet
5. Cost stays inside this year's budget frame
6. Decision today: approve Service as the pilot department

## Slide 2
**Title:** Service handles twice the tickets Sales does, on the same headcount
- Service: 4,180 tickets in Q2 · Sales: 2,060
- Both teams: 11 FTE
- Source: ticket export Q2, tab "Totals"

## Still to do
- Slide 5 needs the budget figure; the notes only say "within budget".
```

## Limits

- The deck is only as good as the material. Missing numbers are flagged, never
  filled in.
- Visual design is clean and simple, not a brand template. If the user has a
  template, ask for it and build on that.
- Charts are built from the numbers provided. A chart the user only described
  is listed under "still to do".

View saved version →

---
name: build-spreadsheet
description: Builds a working Excel file from a description: a budget, a forecast, a tracker or a simple model, with real formulas instead of typed results, clearly marked input cells and a short explanation of how it works. Use for "make me a spreadsheet for", "build a budget template", "maak een excel voor", "bouw een begroting".
---

# Build Spreadsheet

A spreadsheet someone else has to maintain is only useful if they can see
how it works. So inputs live in one place and look like inputs, every result
is a formula, and nothing important is hidden in a typed number.

## Ground rules

- Every calculated cell is a formula. Never type a result.
- Inputs are separated from calculations and visibly marked (for example a
  light fill and an "Inputs" heading). Assumptions get a label and a unit.
- Use only numbers the user gives. Where a number is missing, leave the input
  cell empty or put in a clearly labelled placeholder, and list it at the end.
- Answer in the language the user writes in, and label the sheet in that
  language unless they ask otherwise.

## When to use

The user describes a sheet they need: "make me a spreadsheet for our hiring
plan", "build a budget template for next year", "I need a tracker for these
projects", "maak een excel voor de begroting", "bouw een cashflowoverzicht".

## Steps

1. **Clarify the shape** if it is not clear: what goes in, what must come out,
   the period (months, quarters, years) and who will maintain it. Ask once,
   in one message.
2. **Propose the structure** before building: the sheets, the input block, the
   main calculations and the output. Keep it as small as the job allows.
3. **Build the file.** If this environment can run Python with `openpyxl` (or
   another way to write `.xlsx`), create the workbook with:
   - an Inputs block or sheet, marked and labelled with units;
   - calculations as formulas referencing the inputs, never constants;
   - totals and checks (for example a cell that shows whether two totals
     agree);
   - number formats, frozen header rows and readable column widths.
   Save it only after the user agreed to the structure, and tell them where it
   is. If files cannot be created here, give the layout as a table with the
   formula for every calculated cell, so they can build it by hand.
4. **Check your own work:** recalculate if possible, confirm there are no
   formula errors, and test one result by hand.
5. **Explain it in five lines or fewer:** where the inputs are, what the main
   output is, and what to change next month.

## Output format

```markdown
## Structure
- **Inputs** (sheet 1): headcount plan per month, salary per role, start dates
- **Costs** (sheet 2): monthly cost per role = salary / 12 × FTE active that month
- **Summary** (sheet 3): cost per quarter, total for the year, check against budget

## Key formulas
| Cell | Formula | Meaning |
|---|---|---|
| `Costs!C5` | `=Inputs!$D5/12*Inputs!F5` | cost of role 1 in January |
| `Summary!B4` | `=SUM(Costs!C5:E20)` | total cost Q1 |

## Still to fill in
- Salary for the data engineer role (`Inputs!D9`) is empty.
```

## Limits

- Simple to medium models. A full three-statement financial model is out of
  scope for one conversation; build it in parts.
- Macros and VBA are not written. Everything works with standard formulas.
- The file uses a plain, clean layout, not a corporate template, unless the
  user provides one.

View saved version →

---
name: compare-decks
description: Compares two versions of the same presentation on message and numbers, not formatting, and reports changed figures, dropped claims, new claims and softened language with slide numbers. Use when the user shares two decks and asks "what changed", "compare these two presentations", "vergelijk deze twee decks".
---

# Compare Decks

Two versions of the same story. The question is always "what did we quietly
stop saying?". Compare message and numbers, not formatting. A changed font is
noise. A dropped claim or a hedged promise is the finding.

## Ground rules

- Quote numbers exactly as they appear in the deck, with the slide number.
  Anything you cannot read stays "unknown".
- Text only. Say so in every comparison you write: charts and images are not
  compared.
- Never edit, rebuild or send a deck. This skill produces one comparison.
- Answer in the language the user writes in.
  The example below is in English; translate its headings too.

## When to use

The user shares two `.pptx` or `.pdf` versions of the same deck and asks "what
changed", "compare these two presentations", "does the pitch still say the
same thing", "vergelijk deze twee decks", "wat is er veranderd tussen v3 en v4".

## Steps

1. **Get both files and settle which is older.** Use the modification dates or
   ask the user. Never decide it from the filename alone.
2. **Extract the text per slide.** Use whatever this environment offers:
   `markitdown` (its output marks each slide with `<!-- Slide number: N -->`),
   `python-pptx`, or a PDF text reader. If none of these is available, say so
   and ask the user to export both decks as PDF or paste the slide text. Do not
   guess at the content of a deck you could not read.
3. **Align the slides** by heading first and slide number second. Decks gain
   and lose slides, so position alone will mislead you.
4. **Extract per slide** the claim, the numbers, the ask and anything that is
   missing compared with the other version.
5. **Group the findings** as changed numbers, dropped claims, new claims and
   softened language (for example "we will" becoming "we aim to").
6. **Write the verdict first:** one or two sentences on how the story changed.
   Then the evidence, then three recommendations.
7. **Offer to save** the comparison as a markdown note if this environment can
   write files. Do not write anything without the user saying yes.

## Output format

```markdown
## Verdict
More cautious and less concrete: three of the five hard numbers became ranges
and the 2027 revenue commitment is gone.

## Numbers that changed
| Slide | Metric | Old | New | Reading |
|---|---|---|---|---|
| 4 | Pipeline | €2.4M | "€2M+" | Precision gone, direction holds |
| 7 | Go-live | Q1 2027 | "H1 2027" | Slipped a quarter, not called out |

## Claims
- **Dropped** · slide 9: "fully self-serve onboarding". Deliberate, or lost in an edit?
- **New** · slide 11: a partner logo with no signed agreement mentioned anywhere.
- **Softened** · slide 2: "we replace" became "we support".

## 3 recommendations
1. Decide whether the 2027 number was withdrawn on purpose. If not, restore it.
2. Verify the partner on slide 11 before this goes out.
3. Pick one style: exact numbers or ranges. The mix reads as hedging.

## Limits of this comparison
Text only. Charts and images were not compared, so a chart whose shape changed
does not show up here.
```

## Limits

- **Text only.** Charts and images come through as placeholders at best, so a
  changed chart is invisible. State this in every comparison.
- Speaker notes and animations are not reliably extracted.
- Scanned or image-only PDFs have no text to compare. Say so and stop.

View saved version →

---
name: decision-memo
description: Writes a one-page decision memo from the material the user provides: the decision in one sentence, the options with honest trade-offs, a recommendation with its reasoning, the risks and the exact ask. Use for "write a decision memo", "help me decide between", "zet dit op een rij voor een besluit", "schrijf een besluitnotitie".
---

# Decision Memo

A decision memo exists so that a busy person can decide in five minutes and
defend the decision in six months. That means the decision is stated in the
first line, the options are real options (including doing nothing), and the
trade-offs are written down honestly, including the ones against the
recommendation.

## Ground rules

- One page. If it does not fit, the decision is not yet sharp enough.
- Every fact comes from the material the user provides. Opinions and
  estimates are labelled as such.
- Always include "do nothing" or "wait" as an option, with its real cost.
- Write the strongest argument against the recommendation, not a straw man.
- Answer in the language the user writes in.
  The example below is in English; translate its headings too.

## When to use

The user faces a choice and shares notes, numbers, emails or a rough
description: "write a decision memo", "help me decide between A and B", "I need
to put this to the board", "zet dit op een rij voor een besluit", "schrijf een
besluitnotitie".

## Steps

1. **State the decision** in one sentence, as a question with a yes/no or an
   A/B answer. Confirm it with the user if the material is vague.
2. **Collect the options**, two to four, always including doing nothing.
3. **For each option**, write what it costs, what it gets, what it risks and
   what must be true for it to work. Use the user's numbers; mark estimates.
4. **Recommend one option** and give the reasoning in three sentences or fewer.
   Then write the strongest case against it.
5. **Write the ask:** what exactly the reader must decide, by when, and what
   happens next if they say yes.
6. **List open facts**: what you would want to know before deciding, and who
   could provide it.
7. **Offer to keep the decision.** If this environment can write files, offer
   to save the memo as `Decisions/<YYYY-MM-DD> · <decision>.md`, and add the
   outcome once it is decided. A decision log is what makes "why did we choose
   this?" answerable in six months. Do not write anything without the user
   saying yes.

## Output format

```markdown
# Decision: run the pilot in Service or in Sales?

**Ask:** approve Service as the pilot department by 15 August.

## Options
| | Service | Sales | Wait until Q1 |
|---|---|---|---|
| Gets | Highest ticket volume, willing team lead | Visible to the board | More time to settle data access |
| Costs | Within this year's frame | Same | Another quarter without results |
| Risks | Data access not yet owned | Team has no capacity until October | The budget frame lapses at year end |
| Must be true | Someone owns data access by go-live | Capacity frees up | Budget can be carried over (unknown) |

## Recommendation
Service. It has the volume to show results within the quarter and a team that
asked for it. The open data-access question is solvable before go-live.

**Strongest case against:** if data access slips, the pilot starts late in the
department where delay is most visible to customers.

## Open facts
- Can the budget frame carry over to next year? Finance.
```

## Limits

- The memo frames the decision; it does not make it.
- When the material does not support a recommendation, the memo says so and
  lists what is missing instead of picking one.

View saved version →

---
name: meeting-prep
description: Builds a delta brief for an upcoming meeting from the notes, emails and documents the user provides. Reconstructs what was agreed last time, what changed since, who owes what, and three talking points, each line with its source. Use when the user asks "prep me for X", "where did we leave X last time", "bereid me voor op X".
---

# Meeting Prep

The real question is never "what is this meeting about". It is "what did we
agree last time, and what quietly changed since". This is a delta brief, not a
summary. Two ways to get it wrong: padding it with context the user already
has, and stating a prior agreement you cannot point to a source for.

## Ground rules

- Work only from what the user provides in this conversation: previous meeting
  notes, transcripts, email threads, decks, documents. Nothing else counts as a
  source.
- Every claim about "last time" cites the document it came from. No source, no
  line.
- Silence means "not recorded", not "nothing happened". Say which one it is.
- Answer in the language the user writes in.
  The example below is in English; translate its headings too.

## When to use

The user has a meeting coming up and asks "prep me for the board call", "where
did we leave X last time", "what do I need to know before Thursday", "bereid me
voor op X", "hoe stond het er vorige keer voor".

## Steps

1. **Pin down the meeting:** topic, who is in the room, when. Ask for whatever
   is unclear. Guessed attendees produce a wrong brief.
2. **Gather the material.** If the user keeps meeting notes in a folder (for
   example a `Meetings/` folder saved in earlier sessions) and this
   environment can read it, ask to search it on the topic and the people.
   Otherwise ask the user for the notes or transcript of the previous meeting,
   plus anything since: email threads, updated decks, status reports. If they have nothing on record, say so in the first line of the
   brief and work from what they can tell you.
3. **Reconstruct "last time":** decisions taken, commitments made, who owed
   what. Cite the source for each line.
4. **Work out the delta:** commitments that were met, missed or never started,
   numbers that moved, new documents or facts touching the topic. Compare dates
   against today to show how long each open item has been open.
5. **List open items by owner**, with the promised date and how overdue each
   one is.
6. **Write three talking points.** A talking point is a position with a reason,
   not a topic.
7. **Offer to keep it for next time.** If this environment can write files,
   offer to save the brief as `Meetings/<YYYY-MM-DD> · <topic> prep.md`, with
   headings that can take the real minutes afterwards, so the next prep starts
   from it. Do not write anything without the user saying yes.

## Output format

```markdown
# 2026-08-03 · AI strategy (prep)

**Last time:** 2026-06-14, same group. Source: notes from 14 June.

## Agreed then
- Pilot in one department first, broad rollout after. *(decision, notes 14 June)*
- Budget parked until the pilot shows numbers. *(open, no owner recorded)*

## Changed since
- The pilot never started: no mention in any email since, 7 weeks gone.
- New: the Q3 budget deck sets a precedent for pilot spend. *(budget deck, slide 6)*

## Who owes what
| Item | Owner | Promised | Status |
|---|---|---|---|
| Choose the pilot department | You | 2026-06-14 | 50 days open |
| Budget frame | Finance | no date | never assigned |

## 3 talking points
1. The pilot is the decision. Seven weeks without choosing cost a quarter.
2. Don't reopen scope: that is how June ended without an owner.
3. Leave with a name and a date, or the next meeting is this meeting.
```

## Limits

- The brief is only as good as the material provided. It does not search mail,
  calendars or drives on its own unless the user has connected them in this
  environment and asks for it.
- A prior meeting exists only if it was written down. An empty result is
  reported as "not recorded", never as "nothing happened".
- This skill prepares. It does not send agendas or invites.

View saved version →

---
name: review-deck
description: Reviews a presentation the way a board member reads it. Checks whether the titles alone tell the story, whether every number is sourced and consistent across slides, and what a critical reader will ask. Returns a verdict, slide-by-slide fixes and the questions to prepare for. Use for "review this deck", "is this ready for the board", "check mijn presentatie", "wat ontbreekt er aan dit deck".
---

# Review Deck

A deck fails in the room for three reasons: the story only works if someone
talks over it, a number on slide 3 does not match slide 9, or the obvious
question has no answer. This review finds those three before the meeting does.

## Ground rules

- Review only the deck the user shares, and quote slide numbers for every
  finding.
- Quote numbers exactly as they appear. Never correct a number yourself: point
  at the conflict and ask which one is right.
- Be direct. A review that hedges every point is useless the night before a
  board meeting.
- Answer in the language the user writes in.
  The example below is in English; translate its headings too.

## When to use

The user shares a `.pptx` or `.pdf` and asks "review this deck", "is this ready
for the board", "what will they ask", "check mijn presentatie", "wat ontbreekt
er aan dit deck".

## Steps

1. **Ask who the audience is** and what the deck should achieve, if that is
   not clear. A deck for approval is judged differently from a deck for
   information.
2. **Extract the text per slide** with whatever this environment offers
   (`markitdown`, `python-pptx`, a PDF reader). If you cannot read the file,
   ask for a PDF export or the slide text. Never review a deck you could not
   read.
3. **Read the titles only, in order.** Write down the story they tell. If it
   has gaps or the main point only appears on slide 7, that is finding one.
4. **Check every number:** is it sourced, and does the same metric have the
   same value everywhere it appears? List every conflict with both slide
   numbers.
5. **Check every slide for one message.** Flag slides that make two points,
   slides with a label instead of a title, and slides that prove nothing.
6. **Write the five questions** a critical board member will ask, each with
   the slide it comes from and whether the deck currently answers it.
7. **Give the verdict first**, then the fixes in order of importance.

## Output format

```markdown
## Verdict
Not ready yet. The recommendation is sound but sits on slide 8, and revenue
appears with two different values.

## Fix first
1. **Move the recommendation to slide 1.** Right now the board reads seven
   slides before learning what you want.
2. **Revenue conflict:** slide 3 says €4.1M, slide 9 says €3.9M. Which one is
   right, and is one of them a forecast?

## Slide by slide
| Slide | Title today | Problem | Fix |
|---|---|---|---|
| 2 | "Market" | Label, not a message | "Our segment grew; our share did not" |
| 5 | (two charts) | Two points on one slide | Split into 5a and 5b |

## Questions to prepare for
1. What happens if the pilot misses its date? *(slide 6, not answered)*
2. Why Service and not Sales? *(slide 4, answered)*

## Limits of this review
Text only. Charts and images were not checked.
```

## Limits

- Text only. A chart that contradicts its own title is not caught. Say so in
  every review.
- This skill reviews. It does not rewrite or rebuild the deck unless the user
  asks for that afterwards.

View saved version →

---
name: stakeholder-update
description: Turns notes, figures and project status into a short update for a board, investors, a team or a client: headline first, a status per topic with a clear on track / at risk / off track label, the numbers that moved, what is needed from the reader, and nothing else. Use for "write the monthly update", "draft an investor update", "schrijf de maandupdate", "maak een update voor de RvC".
---

# Stakeholder Update

Readers of an update want three things: is it going well, what changed, and
do they need to do something. Everything else is noise. So the update opens
with the answer, labels every topic honestly, and puts the ask where it
cannot be missed.

## Ground rules

- Use only the notes, figures and status the user provides. Every number keeps
  its source and its period.
- A topic is "on track", "at risk" or "off track". Pick the honest one; if the
  material does not say, ask instead of choosing the comfortable label.
- Bad news goes in the update, early and plainly, with what is being done
  about it.
- Answer in the language the user writes in, and write the update in the
  language of its readers if the user names them.
  The example below is in English; translate its headings too.

## When to use

The user has to report to someone and shares notes, numbers or a previous
update: "write the monthly update", "draft the investor update", "update for
the board", "schrijf de maandupdate", "maak een update voor de RvC", "zet dit
om in een update voor het team".

## Steps

1. **Pin down the reader and the period.** A board, investors, a team and a
   client each need a different level of detail. Ask once if unclear.
2. **If there is a previous update**, compare against it: what was promised
   then, and did it happen?
3. **Write the headline**: one or two sentences on how the period went.
4. **Write each topic** in two or three lines with its status label, the
   number that moved (with period and source) and what happens next.
5. **Write the ask**: what the reader needs to decide, provide or know, with a
   date. If there is no ask, say "No action needed".
6. **Keep it short.** Aim for something readable in two minutes. Offer a
   longer appendix only if the user wants one.
7. **Offer to keep it for next time.** If this environment can write files,
   offer to save the update as `Updates/<YYYY-MM> · <reader>.md`. Next month,
   that file is the "previous update" from step 2, so promises get checked
   instead of forgotten. Do not write anything without the user saying yes.

## Output format

```markdown
**Update August · AI pilot**

**Headline:** The pilot is approved and staffed; data access is the one open
risk before go-live in October.

| Topic | Status | What moved | Next |
|---|---|---|---|
| Pilot scope | On track | Service confirmed as pilot department (MT, 3 Aug) | Kick-off 1 Sep |
| Budget | On track | Frame of €48k agreed (Finance, 14 Aug) | First invoice Sep |
| Data access | At risk | Still no owner, raised twice | Owner needed by 15 Sep |

**Ask:** name an owner for data access before 15 September.

**Promised last month:** choose the pilot department. Done.
```

## Limits

- The update reports what the material says. Progress that is not in the
  notes is not claimed.
- It drafts. The user reviews and sends it; nothing is sent from here.