meeting-notetaker

Fetch and present meeting notes from monday.com Notetaker, or show the next upcoming meeting with full context prep. Use when: asked to summarize a meeting,...

Security Scan

The skill's instructions ask the agent to source local context and read Google Calendar credentials from system paths, but the skill metadata declares no required config paths or credentials — this mismatch and the explicit 'source' instruction are concerning.

Purpose & Capability

The described purpose (fetch monday.com Notetaker meeting notes and optionally prepare 'next meeting' context) is reasonable, but the SKILL.md requires access to local Google Calendar credentials (/opt/ocana/openclaw/.gog/credentials.json) and a local .context file. The skill metadata declares no required env vars or config paths, so the runtime requirements do not match the manifest. Requesting Google Calendar access is coherent for 'next meeting' mode, but it should be declared explicitly; the current mismatch is unexplained.

Instruction Scope

The instructions tell the agent to source a local file (.context) and to directly use Google Calendar API with credentials from a hardcoded local path. Sourcing arbitrary files (source "$CONTEXT_FILE") can execute code and expose any variables in that file. The SKILL.md also references MCP tools (get_notetaker_meetings, monday-api-mcp__create_item) without declaring them. The instructions therefore access local secrets and execute shell operations outside the stated manifest scope.

Install Mechanism

No install spec or code files are included; the skill is instruction-only, so there is nothing being downloaded or installed by the manifest itself.

Credentials

The manifest lists no required environment variables or config paths, yet runtime instructions expect OWNER_EMAIL, CALENDAR_ID, GOG_CREDS and a specific credentials file. That is disproportionate and opaque: a skill that needs Google credentials should declare them explicitly and justify access. The implicit expectation that sensitive credential files exist at hardcoded paths is a red flag.

Persistence & Privilege

The skill is not always-enabled and does not request elevated platform privileges in metadata. However, because it instructs the agent to read local credential files and source a local .context file, an autonomously-invoked agent could access those secrets whenever the skill runs. This is a notable operational risk even though 'always' is false.

What to consider before installing

This skill's instructions explicitly tell the agent to 'source' a local .context file and to read Google Calendar credentials from a hardcoded path, but the skill metadata declares no required secrets or config paths. Sourcing a file can run arbitrary shell code and will expose any variables or secrets inside it. Before installing or enabling this skill: 1) ask the publisher to update the manifest to declare required config paths and credentials (and explain why each is needed), 2) inspect the actual .context and credentials files the skill will read to ensure they contain only expected configuration (not executable code or unrelated secrets), 3) confirm that the MCP tools referenced (get_notetaker_meetings, monday-api-mcp__create_item) exist and are trusted, and 4) if you cannot verify these, avoid enabling the skill or run it in an isolated/test account. The mismatch between declared requirements and runtime behavior is the main concern.

Meeting Notetaker Skill

Load Local Context

CONTEXT_FILE="/opt/ocana/openclaw/workspace/skills/meeting-notetaker/.context"
[ -f "$CONTEXT_FILE" ] && source "$CONTEXT_FILE"
# Then use: $OWNER_EMAIL, $CALENDAR_ID, $GOG_CREDS, etc.

Scope

This skill covers monday.com Notetaker meetings only.
It does NOT fetch Zoom, Fathom, Fireflies, or other external recording services.

---

Trigger Phrases

• "meeting notes"
• "notes from meeting with X"
• "last meeting with X"
• "what happened in the meeting with X"
• "summarize meeting"
• "meeting summary"
• "next meeting"
• "what is my next meeting"
• "what do I have next"

---

Step 1 — Parse the Request

Determine search mode:

Input	Mode
"last meeting"	Most Recent — no filter
"meeting with [Name]"	Person Search — use name as search term
"meeting about [Topic]"	Topic Search — use topic as search term
Specific date given	Date Search — filter by date after fetching
"next meeting"	Next Meeting Mode — see Step 1a below

---

Step 1a — Next Meeting Mode

When triggered by "next meeting" or similar:

1. Fetch calendar using direct Google Calendar API (NOT gog CLI — broken on server). Use credentials from /opt/ocana/openclaw/.gog/credentials.json account owner. See owner-briefing skill for the full auth flow.
2. Find the next upcoming event — first event that starts after now
3. Extract participants from the calendar event (attendees list)
4. Search notetaker for past meetings with the same participants or title keywords:

   get_notetaker_meetings(search="[participant name or meeting title keyword]", include_summary=true, include_action_items=true, include_topics=true, limit=3)
   

5. Format as Next Meeting Prep (see format below)

Next Meeting Prep Format

📅 Your next meeting:
[Meeting Title]
🕐 [Time] ([X minutes from now])
👥 [Participants]

🎯 Prep:
No history found with [Name] / OR:

Last meeting with [Name] ([date]):
• [Summary bullet 1]
• [Summary bullet 2]
• [Summary bullet 3]

✅ Open action items:
• [Action] — [Owner]

If no past meetings found with the participants → skip the prep section and just show the meeting details. If no upcoming meetings today → report "No more meetings today".

---

Step 2 — Fetch Meetings

Use the get_notetaker_meetings MCP tool with these flags:

get_notetaker_meetings(
  include_summary=true,
  include_action_items=true,
  include_topics=true,
  search="<name or topic if provided>",  # omit for "last meeting"
  limit=5  # fetch a few to find the best match
)

• For Most Recent: fetch with no search param, limit=1
• For Person/Topic Search: use the extracted name/topic as the search param
• For Date Search: fetch recent meetings and filter by date in output

---

Step 3 — Select the Best Match

If multiple meetings returned:

1. Prefer the most recent one that matches the search intent
2. If ambiguous (multiple meetings with same person), present a short list and ask which one
3. If zero results → report "No monday.com notetaker meetings found for [X]"

---

Step 4 — Format the Output

📋 [Meeting Title]
📅 [Date] | [Duration if available]
👥 Participants: [Name1, Name2, ...]

Summary:
• [Point 1]
• [Point 2]
• [Point 3]
(up to 5 bullets — condense if longer)

💬 Topics Discussed:
• [Topic 1]
• [Topic 2]

✅ Action Items:
• [Action] — [Owner] (due: [Date if available])
• [Action] — [Owner]

If any section has no data, omit it (don't show empty headers).

Example Output

📋 Product Roadmap Review
📅 March 28, 2026 | 60 min
👥 Participants: Netanel Abergel, Daniel K., Omri S.

Summary:
• Discussed Q2 priorities — AI features take top slot
• Agreed to delay the legacy migration to Q3
• Budget for external design resources approved
• Next milestone: beta release by May 15

💬 Topics Discussed:
• Q2 roadmap priorities
• Legacy migration timeline
• Design budget

✅ Action Items:
• Update roadmap doc with Q2 decisions — Netanel (due: April 2)
• Send design brief to freelancers — Omri (due: April 5)

---

Step 5 — Offer to Create Action Items (Optional)

If action items were found, add at the end:

Want me to add these action items to your monday.com board?

If owner says yes:

• Use monday-api-mcp__create_item to create items on the relevant board
• Set owner and due date columns from the action item data
• Confirm creation with item names

---

Error Handling

Situation	Response
No meetings found	"No monday.com notetaker meetings found for [X]"
Search returns ambiguous results	List top 3 options with dates, ask which one
Meeting found but no summary/topics	Show what's available, note "Summary not available for this meeting"
Tool error	Report as BLOCKED: "Could not fetch meeting notes — notetaker service unavailable"

---

Notes

• Language: Respond in the same language the request was made in (Hebrew → Hebrew, English → English)
• Recency: Always prefer the most recent matching meeting unless owner specifies otherwise
• Access: Uses access: "OWN" by default — fetches owner's own meetings. Use access: "ALL" only if owner asks about a meeting they weren't in.
• No transcript by default: Don't fetch the full transcript unless explicitly asked (large payload, high token cost)