daily-meeting-update

daily-meeting-updateスキルの概要

daily-meeting-updateスキルは、生の作業履歴をそのまま使えるスタンドアップ更新に整えるための会議準備ワークフローです。昨日何が変わったか、今日何を進めるか、何がブロッカーか、会議で口頭で取り上げるべき論点は何か――そうした日次ミーティングの実務的な問いに、開発者がすばやく・構造的に答えられるよう設計されています。

daily-meeting-updateが実際にやること

一般的な「スタンドアップ文面を書いて」というプロンプトとは違い、daily-meeting-updateはまず既存のツールから根拠となる情報を集められるか確認し、そのうえで短いインタビューを行い、最後にMarkdown形式でまとめます。価値の中心は単なる要約ではなく、作業ログのような活動データと、人が補うべき文脈をつなげるところにあります。

このスキルが向いている人

このdaily-meeting-update skillが特に合うのは、次のような人です。

• GitHub、Git、Jira、またはClaude Codeセッションを軸に仕事をしている
• 毎朝その場しのぎで考えるのではなく、再現性のあるスタンドアップ手順がほしい
• 体裁の整った更新はほしいが、何を含めるかの主導権は自分で持ちたい
• 話すべき論点やブロッカーを、聞かれないと思い出しにくいことが多い

実際に解決する仕事

多くのユーザーが必要としているのは「AIに文章を書かせること」ではありません。昨日の作業を正確に復元し、重要な点を見つけて、チャットに貼れる・会議でそのまま話せる短い更新に整えることです。daily-meeting-update for Meeting Prepが特に強いのは、作業がコミット、PR、チケット、コーディングセッションにまたがって散らばっているケースです。

単なるプロンプトとの主な違い

いちばん大きい違いは、ワークフローの作り込みにあります。

• 連携が使える前提で進めず、利用可否を先に確認する
• 質問の前に文脈を取りにいく
• 4項目固定のインタビューを行う
• 機械的に検出できる作業と、ユーザーが補うニュアンスを組み合わせる

このため、記憶だけに頼るブラインドなプロンプトよりも、出力の信頼性が高くなりやすいです。

このスキルが向かないケース

次のような場合は、daily-meeting-updateは見送ったほうがよいでしょう。

• インタビュー工程そのものを入れたくない
• 作業の多くが開発ツールの外にあり、Git/Jira/履歴から根拠を取りにくい
• 1行だけの簡単なステータス更新があれば十分
• 個人の日次更新ではなく、チーム全体のレポートがほしい

daily-meeting-updateスキルの使い方

daily-meeting-updateの導入情報

上流リポジトリはsoftaworks/agent-toolkitで、対象ディレクトリはskills/daily-meeting-updateです。環境がGitHubホストのスキルに対応しているなら、よくある導入方法は次のとおりです。

npx skills add softaworks/agent-toolkit --skill daily-meeting-update

利用しているエージェント基盤で取り込み方法が異なる場合は、リポジトリの該当パスからスキルを追加したうえで、本番の会議で使う前にソースファイルを確認してください。

最初に読むべきファイル

手早くdaily-meeting-update guideをつかむなら、次の順で読むのがおすすめです。

1. skills/daily-meeting-update/SKILL.md — 実際のワークフローとトリガー時の挙動
2. skills/daily-meeting-update/README.md — 連携機能と利用例の説明がより明確
3. skills/daily-meeting-update/scripts/claude_digest.py — Claude Codeセッション履歴をどう検出・要約しているかが分かる

この順番が大事なのは、「履歴連携」と言っても実際に何を指すのかが、スクリプトを見ると具体的に理解できるからです。

daily-meeting-updateのワークフローはどう動くか

このスキルは、3つのフェーズで動きます。

1. 連携を検出して候補提示
   • Claude Code history
   • GitHub CLI
   • Git repository context
   • Jira CLI
2. インタビュー
   • yesterday
   • today
   • blockers
   • discussion topics
3. 更新文を生成
   • 取得した活動情報とあなたの回答を組み合わせる
   • 共有しやすいMarkdown形式のスタンドアップ更新に整える

運用上の重要点として、このスキルはインタビューの前にデータを引く設計です。だからこそ、質問もより具体的になります。

このスキルに渡すとよい入力

daily-meeting-update usageの精度を上げるには、次の情報を最初に渡すのが効果的です。

• 「昨日」が曖昧になりうる場合の会議日、または相対的な期間指定
• どのrepo / projectに焦点を当てるか
• GitHub / Jira / historyソースを使うかどうかの確認
• コミットやチケットに出ない、ツール外の作業内容
• 「口頭スタンドアップ」「Slack投稿」「簡潔なマネージャー向け更新」など、受け手に関する制約

この文脈がないと、技術的には正しくても、実務上は情報が足りない更新になりがちです。

このスキルに合うトリガーフレーズ

このスキルは、次のような依頼で起動する想定です。

• “help me with my daily”
• “prepare my standup update”
• “generate a scrum update”
• “what’s my status for today’s meeting?”

より良い結果を狙うなら、トリガーフレーズだけで終わらせず、何をどう出したいかまで具体化するのがおすすめです。

ざっくりした依頼を強いプロンプトに変える

Weak:

Help me with my daily.

Better:

Prepare my daily standup update for today. Use GitHub and Claude Code history if available, focus on repo my-app, keep it under 6 bullets, and make blockers explicit.

Best:

Prepare my daily standup update for today. Pull GitHub activity and Claude Code history if available, but ask before using Jira. Focus on work from yesterday in my-app and api-service. I need a Markdown version for Slack plus a shorter spoken version. Include: what I finished, what I’m doing next, blockers, and any topic I should raise with the team.

プロンプトが具体的になるほど、参照ソースの選び方、出力形式、会議への適合度が大きく改善します。

より根拠のある出力にするための確認ポイント

daily-meeting-update installで手に入るのはワークフローそのもので、品質は参照できるソース次第です。使う前に、次を確認してください。

• GitHub文脈を使いたいなら gh auth status が通るか
• ローカルgitのシグナルを期待するなら、そのrepoが有効なgit repositoryか
• チケット文脈が必要なら Jira CLI が設定済みか
• セッション要約がほしいなら Claude Code history が ~/.claude/projects に存在するか

このスキルは「ツールが設定済みであること」を勝手に前提にしません。信頼性の面では長所ですが、そのぶん権限や利用可否の確認が入る前提で考えておくとスムーズです。

Claude Code historyスクリプトが補ってくれること

scripts/claude_digest.pyは、Claude Codeセッションのダイジェストを取得します。含まれる項目の例は次のとおりです。

• session title
• project path
• branch
• touched files
• command count
• date/session count

これは、作業実績をマージ済みPRだけで追うよりも、コーディングセッションの流れから復元したほうが分かりやすい場合に役立ちます。まだGitHub上に見えていない途中作業を思い出す助けにもなります。

daily-meeting-updateの日次運用でおすすめの流れ

実践的なdaily-meeting-update usageパターンは次のとおりです。

1. スタンドアップの最中ではなく、始まる前に実行する
2. 利用可能な連携を許可する
3. 取得された活動情報を見て、関係あるものだけを選ぶ
4. 足りない文脈を4つの質問で補う
5. 初稿が冗長なら、短く言い換えるよう依頼する
6. Markdown出力をSlackや手元メモ用に保存する

こうして使うと、単なるログの垂れ流しになりにくくなります。

明示しておくと便利な出力形式

このスキルはMarkdownを生成しますが、それでも欲しいスタイルは具体的に伝えたほうが有効です。

• スタンドアップチャット向けの箇条書き
• 口頭共有用の話し言葉スクリプト
• 実装詳細を減らしたマネージャー向けステータス
• daily sync向けの短い版、async update向けの長い版

フォーマット指定は使い勝手に直結するので、最初に伝えておく価値があります。

daily-meeting-updateスキルのFAQ

daily-meeting-updateは普通のスタンドアップ用プロンプトより良い？

たいていはYesです。特に、作業の痕跡がGitHub、Git、Jira、またはClaude Code historyに残るならなおさらです。通常のプロンプトは記憶頼みですが、daily-meeting-updateは先に文脈を復元し、その後で狙いを絞った質問をするため、漏れや曖昧な更新を減らしやすくなります。

すべての連携を設定しておく必要はある？

いいえ。スキルは利用可能なものを確認し、使う前に尋ねる設計です。外部文脈なしで、インタビュー中心のワークフローとしてdaily-meeting-updateを使うこともできます。ただし、要約の根拠になる外部情報がないぶん、価値はやや下がります。

初心者でも使いやすい？

はい。ただし注意点が1つあります。初心者だと、自分の環境でどの連携が実際に使えるのか判断しにくいことがあります。インタビュー自体はシンプルですが、どこまで事前入力が埋まるかはセットアップ状況に左右されます。

いちばん大きな制約は？

このスキルは、どの活動が政治的・戦略的に重要かを魔法のように理解してくれるわけではありません。作業の根拠は拾えますが、最終的には自分で次を判断する必要があります。

• 何を強調するか
• 何はあえて触れないか
• 未完了の作業をどう表現するか
• どのブロッカーをエスカレーションすべきか

daily-meeting-updateを使わないほうがよいのはどんな時？

次のような場合は使わないほうが適しています。

• 更新内容を完全に手作業かつ非公開で扱う必要がある
• 会議フォーマットが独特で、yesterday/today/blockers/topics にあまり近くない
• 自分のステータスではなく、複数人をまたいだチーム集計が必要
• 1日の仕事の大半が、接続ツールに現れにくい計画・コミュニケーション・デザイン作業だった

daily-meeting-updateスキルを改善する方法

最初にスコープを絞る

daily-meeting-updateの結果を手早く良くするいちばんの方法は、対象範囲を先に狭めることです。

• どのrepoか
• どのprojectか
• どの期間か
• どの連携を使うか
• 誰向けの更新か

スコープを省くと、情報としては正しくてもノイズの多い文脈を集めやすくなります。

含めないものを先に伝える

よくある失敗の1つが、価値の低い活動まで過剰に報告してしまうことです。次のように伝えると防ぎやすくなります。

• “exclude routine review comments”
• “focus on merged work and meaningful progress”
• “don’t list exploratory branches unless they affect today”
• “omit internal troubleshooting details from the Slack version”

こうしておくと、更新文が単なる活動ログではなく、人が話すスタンドアップらしい内容に寄っていきます。

ツールでは拾えない人間側の文脈を足す

ツールのデータだけでは、たいてい次のような情報は拾えません。

• なぜ予定より時間がかかったのか
• どんなトレードオフを取ったのか
• どんな判断待ちがあるのか
• チームメイトに何を求めているのか

自動検出された文脈が出てきたら、インタビューの段階でこうした情報を追加してください。ここで初めて、daily-meeting-update skillは単なる自動レポートではなく、実務で使える道具になります。

2段階で仕上げる

おすすめの進め方は次のとおりです。

1. 1回目で、完全版のMarkdownスタンドアップを作る
2. 2回目で、その会議向けに絞った短い版を作る

追加入力の例:

Shorten this to 4 bullets, keep one blocker, and make the discussion topic a final line item.

最初から完璧な短さを狙うより、この2パス運用のほうがうまくいくことが多いです。

初稿の曖昧さはラベルを強めて直す

最初の出力で、完了済み・進行中・予定の区別が曖昧なら、ラベルを明確にした書き直しを依頼してください。

• Done yesterday
• Doing today
• Blockers
• Need input on

GitHub activityにマージ済み・未マージの作業が混ざる場合は、特にこの構成が有効です。

根拠ソースを検証して信頼性を上げる

更新内容がずれていると感じたら、文面だけを直すのではなく、参照元の経路を確認してください。

• gh が正しいアカウントで認証されているか
• 今いる場所が正しいgit repoか
• Jira CLIにアクセスできるか
• セッション履歴が欠けて見えるなら scripts/claude_digest.py の挙動を確認する

長期的にdaily-meeting-updateの出力品質を上げるうえで、これが最も実践的な改善方法です。