跳到正文
cccskills
免费在 GitHub 公开中文介绍

follow-up-from-granola

从 Granola 会议记录中提取由你负责的承诺、负责人、期限和依据,并转成代码修改、工单或回复草稿。每项工作都附有对应的会议记录出处。

原文查看原文说明

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/Paradev星标 15,720(GitHub 15,720 + cccskills 0)

实测评分 未实测

查看安装方法

适用场景

  • 会后整理自己负责的事项
  • 落实会议商定的代码修改
  • 将承诺事项创建为工单
  • 根据会议内容起草回复

中文介绍

功能

此技能会读取 Granola 会议记录,将由你负责的承诺转成具体行动。它整理事项、负责人、期限以及对应的会议原文,并在当前工作环境允许的范围内推进。代码修改可以整理成供审查的版本;工单可通过已连接的任务管理工具创建;消息或回复则会保存为草稿。每项结果都会标明所依据的会议和相关内容。

适用场景

定期会议、计划会议或客户沟通结束后,如果想推进自己承接的后续事项,可以使用此技能。它会阅读完整讨论,而不只看行动事项部分。负责人不明确时,可以查看会议转录;其他人负责的事项会单独列出。

使用示例

  • “请推进我在昨天会议中负责的事项。”
  • “请实现我们在会上商定的修改。”
  • “请把我在会上承诺的后续工作建成工单。”

注意事项

此技能使用 Granola 集成工具。创建工单需要连接任务管理工具,能执行的操作也取决于当前工作环境。承诺内容含糊或工作成本较高时会先询问。除非你明确要求发送,回复只会保存为草稿;无法确认负责人的事项会标为未分配。

本介绍由 AI(OpenAI Codex)根据公开的 SKILL.md 撰写。准确的规格请查看下方原文。

文档检查

AI 根据 SKILL.md 的内容检查了需要注意的操作和使用前提。评分只依据实际运行的结果(实测对比)。

安全性发送数据、删除文件、执行命令等是否有说明
B部分不足会修改代码和创建工单;含糊或成本高的事项会先确认。
安装难易度所需工具和 API 密钥是否少且有说明
B部分不足需要 Granola 集成;创建工单还需连接任务管理工具。

不计入评分。 由 AI(OpenAI Codex)于 2026年10月29日 评估。仅供参考,安装前请同时查看原文。

如果您认为评估有误,请申请复核

请写明哪一项有误以及原因。无需登录。我们会对照 SKILL.md 重新评估,并在此处更新结果。

此表单受 reCAPTCHA 保护,适用 Google 的隐私权政策和服务条款。

包含的文件(1)

  • SKILL.md3.0 KB

SKILL.md(原文)

安装前可以查看交给 AI 代理的指令内容。

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.

评价

还没有评价。欢迎分享你的使用感受。

评论

无需登录即可发表。欢迎分享使用感受、提问,或说明在哪些环境下无法运行。

还没有评论。来写第一条吧。

提交后会立即公开。请勿填写邮箱、电话等个人信息。URL 最多 2 个。

0 / 1000 字

此表单受 reCAPTCHA 保护,适用 Google 的隐私权政策和服务条款。

同一仓库的技能

10x

免费有简介

检查 Superset 的使用情况,找出适合当前工作方式但尚未使用的功能,给出建议并介绍选项;用户选定后,可协助设置定时运行、并行工作区或共享任务等功能。

  • 查找尚未使用的 Superset 功能
  • 设置定时运行的智能体
  • 在多个工作区并行处理任务
ParadevAI/Paradev1.6万2026年10月29日 更新

automate

免费有简介

把重复任务配置为 Superset 自动化,整理智能体指令、定时或事件触发条件及运行工作区。经明确确认后创建设置,检查已保存的条件,并查看首次运行结果以调整指令。

  • 按日或按周运行任务
  • GitHub 新建拉取请求时启动任务
  • 收到 Slack 指定表情反应时触发
ParadevAI/Paradev1.6万2026年10月29日 更新

browser

免费有简介

通过 Superset 工作区的浏览器查看网页、点击、输入并检查截图或控制台信息,可用于预览运行中的网页应用、检查界面操作和表单流程。

  • 预览本地网页应用
  • 截取页面图像
  • 查看控制台错误
ParadevAI/Paradev1.6万2026年10月29日 更新

依据 Stripe 官方文档和 API 参数定义实现支付、订阅、发票及 Webhook 集成,涵盖产品选择、沙盒测试和事件处理,并通过 Webhook 判断支付与订阅状态。

  • 选择定期扣费产品
  • 实现 Checkout 或发票处理
  • 排查行为异常的 Stripe 集成
ParadevAI/Paradev1.6万2026年10月29日 更新

cdp-verification

免费有简介

通过 Chrome DevTools Protocol 操作正在运行的 Electron 桌面应用,复现界面问题并验证修改。按实际操作流程检查页面跳转,记录截图,并对照路由、滚动位置、焦点元素和保存状态等信息。

  • 在运行中的应用里复现界面问题
  • 检查修复后的页面行为
  • 验证包含页面跳转的操作流程
ParadevAI/Paradev1.6万2026年10月29日 更新

ci-triage

免费有简介

分析 GitHub Actions 失败日志,定位最早的有效错误,区分代码缺陷、环境问题、间歇性失败和原有故障,并对照基准分支说明失败与 PR 的关系及后续处理建议。

  • 调查 PR 检查失败原因
  • 区分不稳定测试与代码缺陷
  • 确认基准分支是否已有故障
ParadevAI/Paradev1.6万2026年10月29日 更新

查看 ParadevAI 的全部技能

报告此技能的问题