本文へ移動
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,724(GitHub 15,724 + cccskills 0)

実行スコア 未検証

インストール方法を見る

こんなときに便利

  • 会議後に自分の担当作業を拾いたいとき
  • 会議で合意したコード修正を進めたいとき
  • 会議の約束をチケットにしたいとき
  • 会議内容を踏まえた返信の下書き

日本語での紹介

できること

Granolaの会議メモを読み、利用者が引き受けた作業を具体的な行動につなげます。作業内容、担当者、期限、根拠となる発言を整理し、作業環境で可能な範囲まで進めます。コード修正はレビューに出せる形にし、チケットは接続済みの課題管理ツールで作成します。メッセージや返信は下書きにまとめ、各項目の実施結果に会議と該当箇所を添えます。

こんなときに便利

定例会議や計画会議、顧客との打ち合わせ後に、自分の担当分を進めたいときに向いています。メモの行動項目だけでなく議論全体を読み、担当が曖昧な場合は文字起こしも確認します。他の人の担当分は分けて示します。

使い方の例

  • 「昨日の会議から、私が担当する作業を進めて」
  • 「この会議で合意した修正を実装して」
  • 「会議で引き受けた作業をチケットにして」

注意点

Granolaの連携ツールを利用し、チケット作成には課題管理ツールの接続が必要です。実行できる内容は作業環境に左右されます。曖昧な約束や費用のかかる作業は確認を求めます。返信は明示的な送信依頼がない限り下書きにとどめ、担当者を特定できない作業は未割り当てとして扱います。

この紹介文は、公開されている SKILL.md をもとに AI(OpenAI Codex)が作成しました。正確な仕様は下の原文を確認してください。

資料チェック

SKILL.md の記述から、注意が要る操作と導入の前提を AI が確認しました。点数は実際に動かした結果(実行検証)だけで付けています。

安全面送信・削除・コマンド実行などの扱いが明示されているか
B一部不足コード変更・チケット作成を行い、曖昧・高コスト時は確認するが範囲に制限あり。
導入のしやすさ必要なツールや API キーが少ないか、書かれているか
B一部不足Granola連携が必要で、チケット作成には課題管理ツール接続も必要。

点数には入れていません。 2026年10月29日 時点で AI(OpenAI Codex)が判定しました。目安なので、入れる前に原文も確認してください。

評価が違うと思ったら、見直しを依頼する

どの項目が、なぜ違うと思うかを書いてください。ログインは不要です。内容を SKILL.md と照らし合わせて評価を作り直し、この欄に反映します。

このフォームは reCAPTCHA で保護されており、Google のプライバシーポリシーと利用規約が適用されます。

含まれるファイル(1)

  • SKILL.md3.0 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

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のPR作成をきっかけに実行
  • Slackの指定リアクションで実行
ParadevAI/Paradev1.6万2026年10月29日 更新

browser

無料概要あり

Superset内のブラウザでページ閲覧・クリック・入力を行い、画面やコンソールを確認します。開発中のWebアプリの動作確認やフォーム操作を支援します。

  • ローカルのWebアプリを確認したいとき
  • ページのスクリーンショット撮影
  • コンソールエラーの確認
ParadevAI/Paradev1.6万2026年10月29日 更新

build-a-stripe-integration

無料概要あり

Stripeの決済・定期課金・請求書連携を、公式資料とAPIの引数定義を確認しながら実装します。製品選びからテスト環境での検証、Webhook処理の設計まで扱います。

  • 決済や定期課金の製品を選びたいとき
  • Checkoutや請求書処理を実装したいとき
  • 動作が不正なStripe連携を調べたいとき
ParadevAI/Paradev1.6万2026年10月29日 更新

cdp-verification

無料概要あり

実際に起動しているデスクトップアプリをChrome DevTools Protocolで操作し、画面遷移や状態を記録しながらUI変更や不具合を確認します。

  • UIの不具合を実アプリで再現したいとき
  • 修正後の画面動作を確認したいとき
  • 画面遷移を含めて検証したいとき
ParadevAI/Paradev1.6万2026年10月29日 更新

ci-triage

無料概要あり

GitHub Actionsの失敗ログから最初の原因を探し、コードの不具合・環境要因・断続的な失敗・既存障害を切り分け、PRとの関係と次の対応を整理します。

  • PRのチェック失敗を調べたいとき
  • 不安定なテストと不具合の切り分け
  • 比較元ブランチの既存障害の確認
ParadevAI/Paradev1.6万2026年10月29日 更新

ParadevAI のスキルをすべて見る

このスキルの問題を報告する