meeting-notes
The meeting-notes skill structures raw meeting transcripts or bullet points into a standardized template with five sections: attendees and metadata, agenda, discussion summary, decisions with rationale, and action items with assigned owners and deadlines. Use it when a user requests meeting notes, call summaries, 1:1 discussion capture, standup documentation, or post-mortem notes, or when they paste unorganized discussion content needing cleanup and organization.
git clone --depth 1 https://github.com/shiwenwen/hope-agent /tmp/meeting-notes && cp -r /tmp/meeting-notes/skills/meeting-notes ~/.claude/skills/meeting-notesSKILL.md
# Meeting Notes
## When to Use
Trigger phrases: "take meeting notes", "summarize this meeting", "1:1 notes", "standup notes", "post-mortem notes", "会议纪要", "记录会议".
Also trigger when the user pastes raw transcript / bullet points and asks for cleanup.
## The Template
Always produce notes with these five sections, in this order. Skip a section only if the user explicitly says it doesn't apply.
```markdown
# <Meeting Title> — <YYYY-MM-DD>
**Attendees:** <name1>, <name2>, ...
**Duration:** <Nm>
**Recording:** <link or "n/a">
## Agenda
1. <topic>
2. <topic>
## Discussion
### <Topic 1>
- <key point>
- <key point with context>
### <Topic 2>
...
## Decisions
- ✅ <decision 1> — rationale: <why>
- ✅ <decision 2> — rationale: <why>
## Action Items
| # | Action | Owner | Deadline | Status |
|---|--------|-------|----------|--------|
| 1 | <action verb + outcome> | <person> | <YYYY-MM-DD> | <Open/Done/Blocked> |
| 2 | ... | ... | ... | ... |
## Open Questions
- <question that didn't get an answer>
- <question that needs follow-up>
```
## Workflow
1. **Gather input** — if the user only sketched bullet points, ask for missing essentials via `ask_user_question`:
- Meeting title and date (default to today if not given)
- Attendees (at least names)
- Whether decisions / action items already exist or you should infer them
2. **Extract** — read the transcript / bullets carefully. For each line, classify:
- Background context → Discussion
- "We agreed", "We'll go with", "Decided to" → Decisions
- "<X> will <verb>", "Action: ...", "Owner: ..." → Action Items
- "?", "TBD", "needs follow-up" → Open Questions
3. **Action Item Discipline (the high-value part)**:
- Every action MUST have an owner (a real name, not "team")
- Every action MUST have a deadline (a specific date, not "soon" or "next week")
- If owner or deadline is missing, surface it explicitly with ⚠️ before the row, e.g.: `⚠️ Owner not assigned: <action>` — let the user resolve
- Action verb first ("Draft …", "Review …", "Ship …"), not vague ("Look into …")
4. **Decision Discipline**: each decision should be one sentence with a brief "why" so future readers can reconstruct context.
5. **Save (optional)** — if the user wants to remember decisions / action items for future sessions, offer to save key items via `save_memory` (scope: "session" or "project"). Don't auto-save without confirming.
## Style Rules
- Past tense for Discussion ("we discussed …"), present tense for Decisions ("we go with …"), imperative for Action Items ("Draft proposal …")
- Don't editorialize — just record what was said, decided, or assigned
- One bullet = one fact. No multi-clause sentences with embedded sub-points
- Keep technical jargon if it's the team's vocabulary; don't over-explain
- For multi-language meetings, default to the user's preferred language; mark code-switches with `[en]` / `[zh]` if helpful
## Common Pitfalls
| Mistake | Fix |
|---|---|
| Vague action: "Look into auth" | "Draft auth migration plan with timing estimates" |
| No owner: "Team will review" | Surface as `⚠️` and ask who owns it |
| No deadline: "By next week" | Pin to a specific date (`YYYY-MM-DD`); ask if unclear |
| Mixing decisions with discussion | Decisions get the ✅ section; everything else stays in Discussion |
| Listing everything said | Compress — one bullet per substantive point, not per sentence |
## Example
Input:
```
hi all - q3 planning. we need to ship feature X by oct. alice will write the spec
- kevin: should we cut feature Y? yes everyone agrees
- bob will run user research starting next mon
- still unclear who owns infra migration
```
Output:
```markdown
# Q3 Planning — 2026-04-25
**Attendees:** Alice, Kevin, Bob
**Duration:** 30m
**Recording:** n/a
## Agenda
1. Feature X timeline
2. Feature Y status
3. Open ownership questions
## Discussion
### Feature X
- Targeting October ship date
### Feature Y
- Considered cutting from Q3 to focus on X
## Decisions
- ✅ Ship Feature X by October — rationale: aligned with Q3 OKRs
- ✅ Cut Feature Y from Q3 — rationale: capacity constrained
## Action Items
| # | Action | Owner | Deadline | Status |
|---|--------|-------|----------|--------|
| 1 | Draft Feature X spec | Alice | 2026-05-02 | Open |
| 2 | Run user research wave | Bob | 2026-04-28 | Open |
## Open Questions
- ⚠️ Owner not assigned: Infrastructure migration
```>
Use when the user asks to draft, polish, translate, or reply to an email. Produces a clean draft with subject line, greeting, body, and sign-off, plus a pre-send self-check.
Use when the user mentions 飞书 / Feishu / Lark workspace operations: docx (云文档) read/write, bitable (多维表格) records / views / dashboards, drive (云盘) upload/download, wiki (知识库) link resolution, approval (审批) instance create/cancel/query, calendar (日历) event create/list/update + attendees, contact (联系人) user/department lookup, hire (招聘) job/talent/application listing. Trigger on phrases like 'OKR 周报', '把这份文档发到飞书云盘', '给团队拉个评审会议', '查 [姓名] 的联系方式', '撤销那条审批', '/wiki 链接', or any request that mentions a feishu / lark URL / token (doxcn.../bascn.../wikcn.../boxcn.../om_...).
Hope Agent browser automation — the standard `status → tabs → snapshot → act` loop, stale-ref recovery rules, and what to do when login / 2FA / captcha / camera-prompt / dialog blocks progress. Load this skill whenever you reach for the `browser` tool. Trigger on: user asks the agent to open / control / click / scrape / log into / verify something in a web app ('open X and click Y', '打开 X 然后点击 Y', 'log into my Gmail', 'scrape this page', 'fill out the form on X'); user reports a flow that requires real browser context (cookies, JS-rendered content, OAuth).
Discover and install third-party skills from external registries when the user needs a capability that no currently-active skill covers. Trigger when: (1) the user explicitly asks 'find a skill for X', 'is there a skill that does X', 'install a skill to X', (2) the user requests a well-known integration (Slack, Notion, Trello, GitHub, Hue, Sonos, iMessage, weather, TTS, transcription …) that isn't in the active skill catalog, (3) you are about to hand-write ad-hoc shell / API code for a domain that almost certainly has a published skill. Do NOT trigger if an active skill already covers the need — scan the visible skill catalog first.
Self-service diagnostics — query Hope Agent's local SQLite databases (logs / sessions / async jobs) directly via the `exec` tool to investigate problems, analyze usage, and locate root causes. Trigger on: user reports something broken / failing / slow / stuck / not responding ('X 不工作', 'X 报错', 'X 卡住', '为什么 X 失败', 'why did X fail', 'show me the logs', 'check what happened'); ad-hoc data analysis ('this week's token usage', '最近调用最多的工具', 'how many subagent runs failed', 'tool error rate', 'find sessions where X happened'); verifying a fix ('did the error stop after I changed Y'). Use BEFORE asking the user to paste log snippets — the data is on disk, query it directly. Read-only — SELECT only, never UPDATE/DELETE/INSERT/DROP.
Hope Agent native macOS desktop control — the standard `mac_control` status / diagnostics / apps / dock / spaces / snapshot / visual / windows / menu / clipboard / dialog loop, target-first action rules, no-blind-coordinate policy, and recovery for stale AX/window/menu/dialog state. Load whenever using `mac_control`, or when the user asks to control local Mac apps, Dock, Spaces, click/type/menu/window/dialog/clipboard, automate Finder/TextEdit/System Settings, visually locate UI, or says 控制 Mac, macOS 自动化, 点按钮, 打开应用, Dock, Space, 关闭窗口, 菜单点击, 视觉定位.
Self-understanding and issue reporting for Hope Agent itself. Use when the user asks how Hope Agent works internally, asks about its own source code/docs/runtime behavior, reports a bug/failure/slowness/crash, asks to diagnose logs, or asks to create/submit a GitHub issue for a bug, feature request, or improvement (including when there is no bug). Chinese triggers: 自查, 了解自己, 自我诊断, 排查 Hope Agent, 提交 issue, 需求 issue, 功能改进.