Daily Standup

Daily Standup Skill

Automate the bridge between synchronized engineering discussions and asynchronous project tracking.

Scope

Transcript in, plan and updates out. Related skills:

• meeting-notes — general transcript → minutes extraction. This skill calls it.
• daily-status — your own activity from git/gh/Jira, no transcript.
• iteration-planner — sprint boundaries, not the daily cycle.

Purpose

• Status Updates: Move cards and post technical rationale to GitHub issues.
• Bias for Action: Enforce an options-based resolution format for blockers.
• Proactive Intervention: Detect stalled items and flag "Reality Gaps" between claims and system state.

Capabilities

1. Context Discovery: Auto-infer Project and current Iteration.
2. Semantic Mapping: Link transcript discussion points to specific GitHub issues.
3. Stall Detection: Flag items blocked for 2+ days without progress.
4. Lead Briefing: Prioritize critical path unblocking for the Engineering Lead.

Technical Guides

• references/status-update.template.md: Mandatory action-oriented comment format.
• references/intervention-logic.md: Rules for stall detection and reality checking.

Phase 0: Locate the transcript

Look for a Teams transcript among the newest files in ~/Downloads:

find ~/Downloads -maxdepth 1 -type f \
  \( -iname '*.vtt' -o -iname '*.srt' -o -iname '*transcript*' -o -iname '*recap*' \) \
  -printf '%T@ %p\n' 2>/dev/null | sort -rn | head -5

Decide as follows:

• A recent transcript is found (within ~24h): state the filename and its timestamp, and confirm it is the right meeting before proceeding.
• Nothing matches, or the newest match is stale: do not guess and do not scan the wider filesystem. Ask the user for the transcript location, and say what you looked for. Accept a path, a paste of the transcript text, or a Teams chat name to pull via the teams-headless skill (--recap).

Never proceed on an unconfirmed file. Acting on the wrong meeting means writing wrong decisions into real issues.

Orchestration Flow

1. Phase 1: Knowledge Gathering
   • Identify Project, Iteration, and Working Set.
   • Load the transcript confirmed in Phase 0.
2. Phase 2: Deep Analysis
   • Call meeting-notes skill to parse transcript.
   • Fetch issue history for all matches to detect stalls.
   • Perform Reality Checks (Refer to intervention-logic.md).
3. Phase 3: Proposal Generation
   • Apply the Bias for Action template to each update.
   • Generate Lead Briefing with priority escalations.
   • Assemble the day's plan (see Outputs below).
4. Phase 4: User Validation & Execution
   • Display Plan and Briefing; execute confirmed updates via gh.

Outputs

Produce all four, in this order:

1. The day's plan — what the user should do today, ordered by priority, derived from actions assigned to them plus anything the Reality Check flagged as a gap.
2. Decisions — material decisions reached in the meeting, each with the issue or PR it belongs to. Post as issue comments using the status-update.template.md format.
3. Issue updates — status moves, comments, new issues for unowned action items. Proposed first, executed only after confirmation.
4. Reminders — time-bound commitments made in the meeting ("I'll check with Priya by Thursday"). Write to the user's usual capture point: append to the Obsidian vault via obsidian-notetaker, or ~/projects/dailies/ if the vault is unavailable. Ask once which, then keep to it.

Execution Safety

Issue comments and status changes are visible to your team and are hard to retract. Therefore:

• Show every proposed write — target, action, exact body — before executing.
• Batch the confirmation: one list, one approval, then execute.
• Never invent an action item, owner, or decision that is not in the transcript. If attribution is ambiguous, mark it [owner unclear] and ask.
• A Reality Gap is reported, never silently corrected.

Maintained by: contributors | Version: 1.2 | Last Updated: 2026-03-14