skills-marketplace/plugins/cascade-knowledge-base/skills/ckb-meeting-notes/SKILL.md
Michał Kopeć c9f6186b4b Restructure plugins into doc-help, common, cascade-knowledge-base bundles
Consolidates ghost-writer/resolve-todos/tldr-this into doc-help,
hr-manager/interview into common, and the ckb-*/meeting-notes/meeting-prep/quiz
skills into cascade-knowledge-base (renaming the latter three to ckb-meeting-notes,
ckb-meeting-prep, ckb-quiz for naming consistency). Updates marketplace.json and
README.md to match the new plugin set.
2026-07-16 16:44:54 +02:00

9 KiB

name description
ckb-meeting-notes Run an interview with the participant to collect the information from the meeting and prepare meeting notes in a dedicated form

Meeting notes skill

Purpose

Collect meeting information through a structured interview and produce a clean, consistent meeting note saved to meeting-notes/.

Works for any meeting type — client calls, internal sessions, kickoffs, status updates, discovery sessions — whether the user attended or facilitated.

How to run this skill

Step 1 — Setup: audience and timing

Ask these two questions before the braindump. Ask them one at a time.

  1. "Who will read this note — is it for your own reference, for your internal team, or going to the client?"
  2. "When did the meeting take place?"

Use the answers to set two flags that affect everything that follows:

Audience flag:

  • Personal/internal — include internal deliberations, rough impressions, opinions. Tone can be direct.
  • Client-facing — omit internal deliberations and opinions. Tone should be neutral and polished. During gap-filling, probe more thoroughly for completeness since the note will be seen externally.

Time flag:

  • Same day — normal depth expectations.
  • More than one day ago — adjust gap-filling. Do not push hard for exact details that may no longer be remembered. Add a line to the note frontmatter: recorded: [date recorded] and note in the Summary that notes were captured retrospectively.

Step 2 — Free-form input

Ask the user to provide a free-form brain dump of the meeting:

"Tell me about the meeting — anything you remember. Date, who was there, what was discussed, what was decided, what needs to happen next. Don't worry about structure, just say what comes to mind."

Step 3 — Confirm understanding and fill gaps

Paraphrase first. Before asking anything, reflect back your understanding of the braindump in two or three sentences: "Let me make sure I have this right: [paraphrase]. Is that a fair summary?" Do not move on until the user confirms or corrects it.

Identify gaps. From the braindump, note what is missing across these eight areas — but do not list them to the user:

  • Date, time or meeting title
  • Attendees not named or roles unclear
  • Purpose not stated
  • Discussion points too thin to reconstruct context
  • Decisions not captured
  • Actions without owners or due dates
  • Open questions not recorded
  • Next meeting not mentioned

Fill gaps one at a time using interview techniques. Do not ask all gaps at once. Work through them individually:

  • Prioritise by importance: decisions and actions first (highest risk if lost), then discussion context, then logistics such as date and time.
  • For thin areas, start open before going specific: "Can you tell me more about what was discussed on [topic]?" before asking "Was a decision made?"
  • After each answer, paraphrase to confirm before moving to the next gap: "So the outcome there was X — is that right?"
  • If an answer is unclear, follow up once to clarify, then return to the next gap. Do not chain more than two follow-ups before moving on.
  • Embrace pauses. After an answer, wait briefly — the user may add something before you ask the next question.
  • If a tangent surfaces unexpected context, note it and let it run briefly before returning: "That is useful — let me come back to where we were."
  • If the time flag is more than one day ago, accept thinner answers without pushing. Note any section where detail may be incomplete.

Close before writing. When all gaps are addressed, briefly summarise the complete picture: "Here is what I will write up: [three or four key points]. Before I do — is there anything you would like to add that I have not asked about?" Wait for the answer, then write the note.

Step 4 — Choose format and write the note

Choose the format based on meeting complexity:

Use the short format if the meeting was:

  • 30 minutes or shorter, with three or fewer attendees, and two or fewer distinct discussion topics.

Use the full format for everything else, and always for kickoffs, discovery sessions, and strategy meetings regardless of length.

Write the note and save it immediately to:

meeting-notes/YYYY-MM-DD-kebab-title.md

Where YYYY-MM-DD is the meeting date and kebab-title is a short slug derived from the meeting title or purpose (e.g. 2026-06-09-saffron-kickoff, 2026-06-10-internal-sprint-review).

Do not wait for the user to confirm before saving. Save immediately and tell the user the file path.


Note formats

Short format

For brief, simple meetings.

---
date: YYYY-MM-DD
time: HH:MM (timezone)
title: Meeting title
type: [status | internal | other]
audience: [personal | internal | client]
recorded: YYYY-MM-DD  ← include only if captured retrospectively
---

# Meeting title

## Summary

Two to three sentences. What happened, what the outcome was, and any relevant direction.

## Decisions

- Decision stated as a fact

(If none: "No decisions were made.")

## Actions

| Action | Owner | Due |
|---|---|---|
| Action description | Name | Date or TBC |

(If none: "No actions assigned.")

Full format

For complex, multi-topic or externally shared meetings.

---
date: YYYY-MM-DD
time: HH:MM (timezone)
title: Meeting title
type: [kickoff | status | discovery | internal | other]
audience: [personal | internal | client]
recorded: YYYY-MM-DD  ← include only if captured retrospectively
---

# Meeting title

## Attendees

| Name | Organisation | Role |
|---|---|---|
| Name | Org | Role |

## Purpose

One sentence stating why this meeting was held and what it needed to produce.

## Summary

Two to three sentences. What happened, what the overall outcome was, and the mood or direction if relevant. Short enough to read in 15 seconds.

## Key points

- Main topic or discussion point, with enough detail to reconstruct context
- Another topic — include who said what only if attribution matters
- Continue for all substantive discussion points

## Decisions

- What was agreed — state as a fact, not as "it was decided that"
- Another decision

(If no decisions were made, write: "No decisions were made in this session." — and flag this in the proactive note below the saved file.)

## Actions

| Action | Owner | Due |
|---|---|---|
| Action description | Name | Date or TBC |

(If no actions were captured, write: "No actions assigned.")

## Open questions

- Question raised but not resolved, with context if needed
- Another open question

(If none, omit this section.)

## Next meeting

Date, time and purpose if agreed. If not agreed, write: "Not scheduled — see actions for follow-up."

Writing style

Follow the project writing style defined in CLAUDE.md:

  • British English spelling throughout (organisation, colour, behaviour)
  • Clear, concise prose. No filler.
  • Sentence case headings
  • One idea per paragraph or bullet
  • No banned vocabulary: testament, pivotal, underscore, seamless, robust, dynamic, comprehensive, crucial, enhance, foster, bolstered, garner, delve, tapestry
  • No bullet points with bolded lead phrases (Term: explanation) — write prose or plain bullets
  • No em dashes — use hyphens
  • Specificity: replace every vague claim with a concrete fact, name or number. If you cannot be specific, do not make the claim.
  • If audience flag is client-facing: remove internal opinions, deliberations and rough impressions before saving.

Proactive rules

Apply these automatically after saving the file — add a short plain-text note below the save confirmation:

  1. No decisions captured — flag it: "No decisions were recorded. If decisions were made verbally, consider adding them to the file before sharing."

  2. Actions captured — suggest follow-up: "Actions were assigned. Consider scheduling a brief follow-up or adding these to your action tracker to ensure they are not lost."

  3. Thin sections — if Key points has fewer than two substantive bullets, or Summary is a single vague sentence, prompt: "The [section name] section seems thin. Do you want to add more detail before the note is shared?"

  4. No next meeting — prompt: "No next meeting was recorded. If one was discussed, add it to the file."

  5. Actions without due dates — flag each one: "The following actions have no due date: [list]. Consider adding dates before sharing."

  6. Wiki check — scan the note for anything that belongs in the wiki and flag it explicitly:

    • New people mentioned who do not yet have entity pages
    • Decisions that change project scope, timeline or approach
    • Factual claims about the project (dates, numbers, technical facts, named dependencies) that should update an existing concept or entity page Format the flag as: "Wiki: [one line per item — what it is and which page it likely belongs to]."

File location

All meeting notes are saved to:

meeting-notes/YYYY-MM-DD-kebab-title.md

The meeting-notes/ folder is tracked in git. Notes intended only for personal use should be kept in tmp/ instead and will not be committed.