daily-meeting-update

Overview of daily-meeting-update skill

The daily-meeting-update skill is a meeting-prep workflow for turning raw activity into a usable standup update. It is built for developers who need a fast, structured way to answer the real daily-meeting questions: what changed yesterday, what is next today, what is blocked, and what should be discussed live.

What daily-meeting-update actually does

Unlike a generic “write my standup” prompt, daily-meeting-update first tries to gather evidence from tools you may already use, then runs a short interview, then formats the result as Markdown. Its core value is not just summarization; it bridges activity data and human context.

Best-fit users

This daily-meeting-update skill is best for people who:

• work from GitHub, Git, Jira, or Claude Code sessions
• want a repeatable standup workflow instead of improvising every morning
• need a polished update but still want control over what gets included
• often forget discussion topics or blockers unless prompted

Real job-to-be-done

Most users do not need “AI writing.” They need help reconstructing yesterday accurately, spotting what matters, and packaging it into a short update they can paste into chat or say aloud in a meeting. daily-meeting-update for Meeting Prep is strongest when your work is spread across commits, PRs, tickets, and coding sessions.

Key differentiators vs a plain prompt

The main difference is workflow discipline:

• checks whether integrations are available instead of assuming them
• pulls context before asking questions
• asks a fixed 4-part interview
• combines machine-detectable work with user-supplied nuance

That makes the output more trustworthy than a blind prompt based only on memory.

When this skill is a poor fit

Skip daily-meeting-update if:

• you do not want any interview step
• your work is mostly outside dev tools and hard to evidence from Git/Jira/history
• you only need a one-line status update
• you want team-wide reporting rather than a personal daily update

How to Use daily-meeting-update skill

Install context for daily-meeting-update

The upstream repository is softaworks/agent-toolkit, under skills/daily-meeting-update. If your environment supports GitHub-hosted skills, a common install path is:

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

If your agent platform uses a different import mechanism, add the skill from the repository path and then review the source files before relying on it in a live meeting.

Read these files first

For a fast daily-meeting-update guide, start with:

1. skills/daily-meeting-update/SKILL.md — the actual workflow and trigger behavior
2. skills/daily-meeting-update/README.md — clearer explanation of integrations and examples
3. skills/daily-meeting-update/scripts/claude_digest.py — shows how Claude Code session history is detected and summarized

This read order matters because the script reveals what “history integration” really means in practice.

How the daily-meeting-update workflow runs

The skill works in three phases:

1. Detect and offer integrations
   • Claude Code history
   • GitHub CLI
   • Git repository context
   • Jira CLI
2. Interview
   • yesterday
   • today
   • blockers
   • discussion topics
3. Generate update
   • combines pulled activity with your answers
   • formats a shareable Markdown standup update

The important operational detail: it is designed to pull data before the interview so the questions can be specific.

What input the skill needs from you

The daily-meeting-update usage is best when you provide:

• the meeting date or relative time window if “yesterday” is ambiguous
• the repo or project you want to focus on
• confirmation on whether to use GitHub/Jira/history sources
• any non-tool work that would not show up in commits or tickets
• audience constraints such as “spoken standup,” “Slack post,” or “brief manager update”

Without that context, the result may be technically accurate but incomplete.

Trigger phrases that fit the skill

This skill is intended to activate on requests like:

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

If you want the best result, make the request more specific than the trigger phrase.

Turn a rough ask into a strong prompt

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.

The stronger prompt improves source selection, output format, and meeting fit.

How to get better source-enriched output

daily-meeting-update install only gets you the workflow; quality depends on accessible sources. Before use, check:

• gh auth status works if you want GitHub context
• your repo is a valid git repository if you expect local git signals
• Jira CLI is configured if you want ticket context
• Claude Code history exists under ~/.claude/projects if you want session digests

The skill explicitly avoids assuming tools are configured, which is good for reliability but means you should expect permission and availability checks.

What the Claude Code history script contributes

scripts/claude_digest.py pulls a digest of Claude Code sessions, including fields such as:

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

That is useful when your “work done” is easier to reconstruct from coding sessions than from merged PRs alone. It also helps remind you of partially finished work that may not yet be visible in GitHub.

Suggested workflow for daily use

A practical daily-meeting-update usage pattern:

1. Run it before your standup, not during it.
2. Allow available integrations.
3. Review the pulled activity and select only relevant items.
4. Answer the 4 interview questions with missing context.
5. Ask for a concise rewrite if the first draft is too verbose.
6. Save the Markdown output for Slack or your notes.

This keeps the tool from becoming a passive log dump.

Output formats to ask for explicitly

The skill generates Markdown, but you should still specify the style you need:

• bullet list for standup chat
• spoken script for verbal delivery
• manager-facing status with less implementation detail
• terse version for daily sync, longer version for async update

Formatting requests materially change usefulness, so ask for them up front.

daily-meeting-update skill FAQ

Is daily-meeting-update better than a normal standup prompt?

Usually yes, if your work leaves traces in GitHub, Git, Jira, or Claude Code history. A normal prompt depends on memory. daily-meeting-update tries to reconstruct context first, then asks targeted questions, which reduces missed items and vague updates.

Do I need every integration configured?

No. The skill is designed to check what is available and ask first. You can still use daily-meeting-update as an interview-only workflow, but the value is lower when there is no external context to ground the summary.

Is this beginner-friendly?

Yes, with one caveat: beginners may need help understanding which integrations are actually available in their environment. The interview itself is straightforward, but setup quality affects how much the skill can pre-fill.

What is the biggest limitation?

The skill does not magically know which activity matters politically or strategically. It can surface work evidence, but you still need to decide:

• what to emphasize
• what not to mention
• how to frame unfinished work
• which blockers need escalation

When should I not use daily-meeting-update?

Do not use it if:

• your update must be entirely manual and private
• your meeting format is highly custom and not close to yesterday/today/blockers/topics
• you need a team rollup across multiple people rather than your own status
• your workday contained mostly planning, communication, or design work not visible in the connected tools

How to Improve daily-meeting-update skill

Give better scope up front

The fastest way to improve daily-meeting-update results is to narrow the scope:

• which repo
• which project
• which date range
• which integrations to use
• which audience the update is for

If you skip scope, the skill may collect correct but noisy context.

Tell it what not to include

One common failure mode is over-reporting low-value activity. Prevent that by saying things like:

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

This makes the update sound more like a human standup and less like an activity log.

Add the missing human layer

Tool data rarely captures:

• why something took longer
• what tradeoff you made
• what decision is pending
• what you need from teammates

After the auto-detected context appears, add those details during the interview. That is where the daily-meeting-update skill becomes genuinely useful instead of just automated reporting.

Use two-pass refinement

A good pattern:

1. First pass: generate a complete Markdown standup.
2. Second pass: ask for a tighter version tailored to the meeting.

Example follow-up:

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

This is usually better than trying to force perfect brevity in the first pass.

Correct ambiguity after the first draft

If the first output confuses finished work, in-progress work, and planned work, explicitly ask for a rewrite with stronger labels:

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

That structure is especially useful when GitHub activity includes both merged and unmerged work.

Improve trust by verifying evidence sources

If the update looks off, inspect the source path rather than just editing the wording:

• check whether gh is authenticated to the right account
• confirm you are in the right git repo
• verify Jira CLI access
• inspect scripts/claude_digest.py behavior if session history seems incomplete

This is the most practical way to improve daily-meeting-update output quality over time.