meeting-notes
Turn raw notes or a transcript into a clean summary with decisions and action items.
git clone --depth 1 https://github.com/holaboss-ai/holaOS /tmp/meeting-notes && cp -r /tmp/meeting-notes/apps/desktop/electron/default-skills/meeting-notes ~/.claude/skills/meeting-notesSKILL.md
# Meeting Notes Turn the mess of a meeting — half-sentences, tangents, crosstalk — into a record someone who wasn't there can act on. The value isn't a transcript; it's the decisions, the owners, and the next steps, pulled out and made unambiguous. ## When to use this skill Use Meeting Notes on raw notes, a rough transcript, or a recording summary to produce a structured recap: what was decided, who owns what, and what's still open. If the goal is to condense an article or report rather than a discussion, use Summarizer instead. ## What a good recap captures - **Decisions** — what the group actually agreed, stated plainly. Distinguish a decision from a suggestion that went nowhere. - **Action items** — each with an owner and, where stated, a due date. An action with no owner is a wish; assign it or flag it as unassigned. - **Open questions** — things raised but not resolved, so they don't quietly vanish. - **Context** — just enough of the "why" that a decision doesn't read as arbitrary later. ## Principles - **Signal over transcript.** Don't replay the conversation — extract what matters and drop the rest. - **Attribute carefully.** Only assign an owner or a decision if the input actually supports it. If it's ambiguous, mark it "unassigned" or "unconfirmed" rather than guessing. - **Never invent.** If a date, owner, or decision wasn't stated, say so. Fabricated specifics are worse than an honest gap. - **Neutral voice.** Record what was said, not your opinion of it. ## How to work 1. Read the full input and separate discussion from outcomes. 2. Pull out decisions, then action items (owner + due date where given), then open questions. 3. Write a two-to-three sentence summary at the top so a skimmer gets the gist. 4. Re-check every owner, date, and decision against the source; flag anything you had to infer. ## Output format Lead with a short **Summary**, then **Decisions**, **Action items** (as a checklist with owners), and **Open questions**. Omit any section that genuinely has nothing in it rather than padding it.
Build a new holaOS app using @holaboss/app-builder-sdk (5 backend primitives + optional shadcn dashboard UI). The canonical path for vibe-coded apps — integration modules AND dashboard apps both live here.
Use when working in the embedded browser and you want the cheapest reliable interaction loop.
Use when validating or debugging a workflow in the embedded browser and you need a reproducible, evidence-first loop.
Build the visual layer of a holaOS dashboard app — TanStack Start + @holaboss/ui + workspace tokens. Use when an app has SDK primitives wired (via app-builder-sdk) AND needs a `src/client/` UI surface. NOT for marketing pages, NOT for snapshot HTML reports.
Provision a production-ready teammate only after its stable responsibilities, prerequisites, and reusable operating guidance are understood.
Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, artifacts, posters, or applications. Generates creative, polished code that avoids generic AI aesthetics.
This skill is for interface design — dashboards, admin panels, apps, tools, and interactive products. NOT for marketing design (landing pages, marketing sites, campaigns).
Add or update workspace MCP servers using holaOS mcp_registry syntax.