Skip to content
cccskills
FreePublished on GitHubEnglish overview

follow-up-from-granola

Turn Granola meeting notes into concrete follow-up work by identifying the user's commitments, owners, deadlines, and supporting passages. Make code changes, create tickets through connected tools, or draft replies, with each action traced to its source.

OriginalShow the original description

Turn a meeting into work — read its Granola notes, extract the commitments that belong to this user, and carry each one out or draft it (a code change, a ticket, a reply) with a trace back to the note. Use when the user says "do the follow-ups from", "implement what we agreed", "make tickets from", or points at a meeting after a sync, planning session, or customer call.

ParadevAI/Paradev15,720 stars(GitHub 15,720 + cccskills 0)

Run score Not tested

See how to install

Good for

  • Identify personal commitments after a meeting
  • Implement code changes agreed in a meeting
  • Create tickets from meeting commitments
  • Draft replies based on meeting notes

Overview

What it does

This skill reads Granola meeting notes and turns the user’s commitments into concrete actions. It records each action, its owner and deadline, and the passage that supports it, then carries the work as far as the available workspace allows. Code changes can be prepared for review, tickets can be filed through a connected issue tracker, and messages or replies can be drafted. Each result points back to the meeting and relevant passage.

When it helps

Use it after a recurring meeting, planning session, or customer call when you want to move your own follow-up work forward. The skill reads the full discussion, not only the action-item section. If ownership is unclear, it can check the transcript; other people’s items are listed separately.

Example requests

  • “Take care of the tasks assigned to me in yesterday’s meeting.”
  • “Implement the change we agreed on in that meeting.”
  • “Create tickets for the follow-up items I took on.”

Notes

The skill uses Granola’s integration tools. Creating tickets requires a connected issue tracker, and available actions depend on the workspace. It asks for clarification for ambiguous or costly commitments. Replies stay as drafts unless you explicitly ask to send them; items without a clear owner remain unassigned.

This overview was written by AI (OpenAI Codex) from the public SKILL.md. Check the original below for the exact behavior.

Document check

AI checked the SKILL.md for operations that need care and for setup requirements. The score comes only from actually running the skill (hands-on test).

SafetyAre sending data, deleting files, and running commands disclosed?
BPartly lackingIt changes code and files tickets, with confirmation for ambiguous or costly items.
Easy setupDoes it need few tools or API keys, and are they documented?
BPartly lackingGranola integration is needed; ticket creation also requires a connected tracker.

Not counted in the score. Rated by AI (OpenAI Codex) as of Oct 29, 2026. Treat it as a guide and read the original before installing.

Disagree? Request a re-evaluation

Tell us which point is wrong and why. No login needed. We will check it against the SKILL.md, redo the evaluation, and show the result here.

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

Files included (1)

  • SKILL.md3.0 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

Turn the meeting into work

A meeting produces commitments, and most of them evaporate because nobody turned them into tasks. The job is to read the notes, find the commitments that are this user's to act on, and take each one as far as the workspace allows — without inventing work the meeting did not ask for.

1. Read the whole meeting before extracting anything

Fetch the meeting with get_meetings. If the user gave a title or a date, find it with list_meetings first and confirm it is the right instance — a recurring meeting has many. Read the notes end to end: action items sit in a section, but commitments also hide in the discussion ("I'll take a look at that", "we should ship that first").

2. Extract commitments, and attribute each one

For each commitment record what, who owns it, by when, and the sentence in the notes it comes from. Keep only what the notes support. When ownership is unclear, check get_meeting_transcript for who actually said it; if it is still unclear, list it as unassigned rather than handing it to the user.

3. Sort by what the workspace can do

  • A code change the user owns — make it in the workspace and open it for review, citing the meeting.
  • A ticket or issue — file it through whichever tracker plugin is connected, with the note's wording and the meeting in the body.
  • A message or reply — draft it. Never send on the user's behalf unless they asked for exactly that.
  • Someone else's item — list it under "not yours" so the user can nudge them; do not act on it.

Ask before acting only when a commitment is ambiguous or expensive. A clear "fix the flaky test" in the notes does not need a second confirmation.

4. Report with the trace

Finish with one line per commitment: what you did with it (changed, filed, drafted, skipped and why) and the meeting and line it came from. The user should be able to check every item against the notes.

Anti-patterns

  • Doing the generated "next steps" verbatim. Summaries guess at action items; verify each against the discussion before treating it as a commitment.
  • Turning every mention into a task. "Someone should look at that eventually" is not a commitment; a name and a timeframe are.
  • Acting on other people's items. A meeting assigns work to many people; the user asked for their follow-ups.
  • Losing the trace. A ticket that does not say which meeting asked for it gets re-litigated at the next one.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

10x

FreeSummary

Review how you use Superset and identify unused features that fit your workflow. Get a short list of suggestions, learn about each option, and set up selected features such as scheduled agents, parallel workspaces, or shared tasks.

  • Find unused Superset features worth exploring
  • Set up scheduled agent tasks
  • Start parallel work in separate workspaces
ParadevAI/Paradev15.7KUpdated Oct 29, 2026

automate

FreeSummary

Set up recurring tasks in Superset with an agent prompt, a schedule or event trigger, and a chosen execution workspace. After explicit confirmation, create the automation, check its saved settings, and review a real first run.

  • Scheduling a daily or weekly agent task
  • Starting agent work when a GitHub pull request opens
  • Triggering tasks from selected Slack reactions
ParadevAI/Paradev15.7KUpdated Oct 29, 2026

browser

FreeSummary

Browse pages, click controls, fill fields, and inspect screenshots or console messages through Superset's browser pane. Use it to preview a running web app, check interface behavior, and work through browser tasks in a visible session.

  • Preview a locally running web app
  • Capture screenshots of a page
  • Inspect console errors
ParadevAI/Paradev15.7KUpdated Oct 29, 2026

Build Stripe payments, subscriptions, and invoicing using verified documentation and API parameter definitions. The skill guides product selection, sandbox testing, and webhook handling, where server notifications determine payment and subscription state.

  • Choose Stripe products for payments or recurring billing
  • Implement Checkout or invoice flows
  • Investigate Stripe code that compiles but behaves incorrectly
ParadevAI/Paradev15.7KUpdated Oct 29, 2026

cdp-verification

FreeSummary

Verify a UI change or reproduce a bug in the running desktop app using the Chrome DevTools Protocol (CDP), a browser debugging interface. Follow the real user journey and compare screenshots with measurements such as route, scroll position, and persisted state.

  • Reproducing a UI bug in the running app
  • Verifying a UI change end to end
  • Checking behavior after a route or workspace switch
ParadevAI/Paradev15.7KUpdated Oct 29, 2026

ci-triage

FreeSummary

Diagnose failed GitHub Actions runs by finding the first meaningful error, separating code problems from infrastructure issues and intermittent failures, and comparing the base branch. Get a focused report explaining the PR’s involvement and recommended next steps.

  • Investigating failed PR checks
  • Separating intermittent test failures from code defects
  • Checking whether the base branch already fails
ParadevAI/Paradev15.7KUpdated Oct 29, 2026

See all skills by ParadevAI

Report a problem with this skill