daily-meeting-update

daily-meeting-update 技能概览

daily-meeting-update skill 是一套用于会前准备的工作流，能把零散的活动记录整理成可直接使用的 standup 更新。它适合开发者快速、结构化地回答每日会议里最核心的几个问题：昨天改了什么、今天接下来做什么、卡点在哪里、哪些内容应该在线下或会上展开讨论。

daily-meeting-update 实际会做什么

和那种泛泛的“帮我写 standup”提示词不同，daily-meeting-update 会先尝试从你已经在用的工具里收集证据，再进行一轮简短访谈，最后把结果整理成 Markdown。它的核心价值不只是总结，而是把活动数据和人的上下文衔接起来。

最适合哪些人

这个 daily-meeting-update skill 特别适合以下用户：

• 日常工作主要留痕在 GitHub、Git、Jira 或 Claude Code 会话中
• 不想每天早上临场发挥，希望有一套可复用的 standup 流程
• 需要一份足够 polished 的更新，但仍想自己控制要写进哪些内容
• 如果没有提示，很容易忘记要讨论的话题或当前 blocker

它真正解决的任务是什么

多数用户其实并不需要“AI 写作”，而是需要有人帮自己准确还原昨天做了什么、识别哪些内容值得讲，再把它打包成一段简短更新，方便直接贴到聊天工具里，或在会议中口头汇报。daily-meeting-update for Meeting Prep 最强的场景，是你的工作分散在 commits、PR、tickets 和编码会话里。

相比普通提示词，它的关键差异

它最大的不同在于工作流更有纪律性：

• 不会默认集成一定可用，而是先检查环境
• 先拉取上下文，再开始提问
• 采用固定的 4 段式访谈
• 把机器可检测的工作记录和用户补充的细节结合起来

因此，它输出的内容通常比只靠记忆直接生成的盲写提示更可信。

哪些情况下不适合用这个技能

以下情况建议跳过 daily-meeting-update：

• 你不想经历任何访谈步骤
• 你的工作主要发生在开发工具之外，无法从 Git/Jira/历史记录中有效取证
• 你只需要一句话级别的状态更新
• 你想做的是团队级汇总，而不是个人 daily update

如何使用 daily-meeting-update 技能

daily-meeting-update 的安装背景

上游仓库是 softaworks/agent-toolkit，技能路径在 skills/daily-meeting-update。如果你的环境支持 GitHub 托管技能，常见安装方式是：

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

如果你的 agent 平台采用其他导入机制，就按仓库路径添加这个技能；但在正式会议里依赖它之前，建议先把源码文件过一遍。

先看这些文件

如果你想快速读懂这份 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 会话历史是如何被检测和摘要的

这个阅读顺序很重要，因为脚本文件能让你真正看明白“history integration”在实际中到底意味着什么。

daily-meeting-update 工作流是如何运行的

这个技能分 3 个阶段工作：

1. 检测并提供可用集成
   • Claude Code history
   • GitHub CLI
   • Git repository context
   • Jira CLI
2. 访谈
   • yesterday
   • today
   • blockers
   • discussion topics
3. 生成更新
   • 将拉取到的活动记录与你的回答结合
   • 格式化为可分享的 Markdown standup update

这里最关键的运行细节是：它的设计就是先拉数据，再访谈，这样后续问题才能问得更具体。

这个技能需要你提供哪些输入

要让 daily-meeting-update usage 发挥得更好，最好提前提供这些信息：

• 会议日期，或相对时间范围；如果 “yesterday” 有歧义，这一点尤其重要
• 你想聚焦的 repo 或项目
• 是否确认使用 GitHub/Jira/history 这些来源
• 那些不会出现在 commit 或 ticket 里的非工具型工作
• 受众和场景限制，比如“spoken standup”“Slack post”或“brief manager update”

缺少这些上下文时，结果可能技术上没错，但信息并不完整。

适合触发这个技能的说法

这个技能本来就是为以下这类请求设计的：

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

如果你想得到更好的结果，实际提问时最好比这些触发语更具体一些。

如何把模糊请求升级成高质量提示

弱一些的说法：

Help me with my daily.

更好的说法：

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.

最佳写法：

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
• 如果你需要 ticket 上下文，Jira CLI 已经配置好
• 如果你想用会话摘要，Claude Code history 确实存在于 ~/.claude/projects

这个技能明确不会假设所有工具都已经配置完成。这样做对可靠性是好事，但也意味着你需要预期它会先检查权限和可用性。

Claude Code 历史脚本具体提供了什么

scripts/claude_digest.py 会提取 Claude Code 会话摘要，字段包括：

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

如果你的“已完成工作”更容易从编码会话里还原，而不是只靠 merged PR 来判断，这部分就很有价值。它也能提醒你一些尚未在 GitHub 中显现出来、但其实已经推进到一半的工作。

适合日常使用的 daily-meeting-update 流程

一个比较实用的 daily-meeting-update usage 模式是：

1. 在 standup 开始前运行，而不是开会时临时生成。
2. 允许它接入当前可用的 integrations。
3. 先审一遍拉出来的活动记录，只保留相关项。
4. 用 4 个访谈问题补上缺失的上下文。
5. 如果首稿太啰嗦，再要求它重写成更精简的版本。
6. 把 Markdown 输出保存到 Slack 或自己的笔记里。

这样用，工具就不容易沦为一份被动的活动流水账。

建议明确指定的输出格式

这个技能默认会生成 Markdown，但你仍然应该明确说出你要的风格：

• 适合 standup chat 的 bullet list
• 适合口头汇报的 spoken script
• 面向 manager、减少实现细节的 status update
• 用于 daily sync 的简版，以及用于 async update 的长版

格式要求会显著影响最终可用性，所以最好一开始就说清楚。

daily-meeting-update 技能 FAQ

daily-meeting-update 比普通 standup 提示词更好吗？

大多数情况下是的，前提是你的工作会在 GitHub、Git、Jira 或 Claude Code history 里留下痕迹。普通提示词主要依赖记忆；daily-meeting-update 会先尝试重建上下文，再提出有针对性的问题，因此更不容易漏项，也能减少那种很空泛的更新内容。

我需要把所有 integration 都配置好吗？

不需要。这个技能的设计就是先检查有哪些可用，再征求你的确认。你当然也可以把 daily-meeting-update 当成纯访谈流程来用，但如果没有外部上下文为摘要提供锚点，它的价值会明显下降。

对新手友好吗？

友好，但有一个前提：新手可能需要帮助，先搞清楚自己当前环境里到底有哪些 integration 真的可用。访谈本身并不复杂，但前置配置做得好不好，会直接影响这个技能能替你预填多少内容。

它最大的限制是什么？

这个技能并不会神奇地知道，哪些活动在政治层面或战略层面更重要。它可以帮你找出工作证据，但你仍然需要自己决定：

• 哪些内容要强调
• 哪些内容不必提
• 未完成的工作应该怎么表述
• 哪些 blocker 需要升级处理

哪些情况下不该使用 daily-meeting-update？

以下场景不建议用：

• 你的更新必须完全手写、完全私密
• 你的会议格式非常特殊，和 yesterday/today/blockers/topics 这套结构差异很大
• 你要的是多人团队汇总，而不是你自己的状态更新
• 你当天大部分工作是规划、沟通或设计，这些内容在已连接工具中并不明显可见

如何改进 daily-meeting-update 技能的使用效果

一开始就把范围说清楚

提升 daily-meeting-update 结果质量最快的方法，就是先缩小范围：

• 哪个 repo
• 哪个项目
• 哪个日期区间
• 要使用哪些 integrations
• 这份更新是给谁看的

如果你不限定范围，技能也许会收集到正确的信息，但噪音会很多。

明确告诉它哪些内容不要写

一个常见失败模式是：把低价值活动也汇报进去，导致过度报告。你可以直接这样限制：

• “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”

这样生成出来的更新会更像真人在做 standup，而不是一份活动日志。

补上工具数据缺失的人类上下文

工具数据通常抓不到这些信息：

• 为什么某件事花了更久时间
• 你做了什么取舍
• 哪个决策还在等待
• 你需要队友提供什么支持

当自动检测出的上下文出现后，记得在访谈阶段把这些细节补进去。也正是在这里，daily-meeting-update skill 才会从“自动化汇报”变成真正有用的助手。

用两轮 refinement 提升结果

一个很好用的模式是：

1. 第一轮：先生成一版完整的 Markdown standup。
2. 第二轮：再让它收紧成更符合会议场景的版本。

示例追问：

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

通常这比你在第一轮就强行要求“既完整又极简”更容易得到好结果。

首稿出来后，及时纠正歧义

如果第一版输出把已完成工作、进行中工作和计划中的工作混在一起，直接要求它按更明确的标签重写：

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

当 GitHub activity 同时包含 merged 和未合并工作时，这种结构尤其有用。

通过核对证据来源来提升可信度

如果更新内容看起来不对，不要只改措辞，应该先检查来源链路：

• 看看 gh 是否登录到了正确账号
• 确认你所在的是正确的 git repo
• 验证 Jira CLI 是否有访问权限
• 如果会话历史看起来不完整，就检查 scripts/claude_digest.py 的行为

这是长期提升 daily-meeting-update 输出质量最实际的做法。