MCPInstall

standup-meeting

Turn messy daily-sync requests into one honest coordination-cadence packet: decide whether live-daily, async-daily, hybrid-daily, less-frequent syncs, or no recurring standup is justified, then pick the lightest standup mode that still catches blockers and handoffs. Use when the user needs a daily scrum, async check-in, board-walk, blocker-first sync, remote-team standup, launch- week cadence reset, or help fixing an overlong / low-signal standup. Route backlog planning to task-planning, sizing to task-estimation, retrospective process repair to sprint-retrospective, and incident-command work to debugging / launch-specific skills.

Installs
369
Last 24h
—
Trending rank
—
Security
Not audited

Install

Works with every agent the skills CLI supports.

npx skills add https://github.com/akillness/jeo-skills --skill standup-meeting
  1. 01

    Install

    Run the command in your project. The CLI asks which agents to install for.

  2. 02

    Describe the task

    Ask your agent for something this skill covers. It loads standup-meeting automatically when relevant.

  3. 03

    Review the result

    The agent follows the SKILL.md steps, scripts and references bundled with the skill.

SKILL.md

The instructions your agent reads when the skill is triggered.

Standup Meeting

Use this skill when the job is to turn vague daily coordination into one honest cadence decision, one small evidence packet, and one follow-up path.

standup-meeting owns:

  • daily-coordination cadence truth
  • standup mode selection when a recurring sync is justified
  • blocker / handoff visibility
  • short facilitation flow and update templates
  • clear separation between the core sync and follow-up huddles
  • anti-status-theater guardrails
  • explicit less-frequent / no recurring standup outcomes when daily ritual is unjustified

Read these references before unusual cases or when the request starts to sprawl:

  • references/cadence-gates-and-exceptions.md
  • references/facilitation-modes.md
  • references/intake-packets-and-route-outs.md

When to use this skill

  • A user asks for a daily standup, daily scrum, daily sync, or async check-in format.
  • A team needs to decide whether daily live cadence is still justified before choosing board-walk, blocker-first, async, hybrid, or classic three-question standups.
  • A daily ritual is running too long, drifting into status reporting, or generating too many side discussions.
  • A remote or hybrid team needs a lighter way to coordinate blockers and handoffs.
  • A launch / milestone / firefighting window may justify a temporary daily cadence even if the normal answer is lighter.
  • The best next artifact is a Coordination Cadence Brief with one cadence decision, one mode (if any), and one escalation path.

When not to use this skill

  • The real job is backlog decomposition, sprint prep, or execution-ready slicing → task-planning.
  • The real job is sizing, confidence framing, or capacity disagreement → task-estimation.
  • The real job is process reflection, recurring ceremony pain, or action follow-through after delivery → sprint-retrospective.
  • The real job is outage command, release war room, or incident triage → debugging / incident / launch-specific skills.
  • The user mainly wants manager-facing status collection or performance reporting. This skill is for lateral coordination, not upward theater.

Instructions

Step 1: Classify cadence first, then one primary mode if needed

Normalize the request before suggesting any format.

standup_intake:
  cadence_decision: live-daily | async-daily | hybrid-daily | less-frequent-sync | no-recurring-standup
  primary_mode: board-walk | blocker-first | async-check-in | hybrid-async-plus-live | classic-three-questions | none
  team_shape: colocated | hybrid | distributed | cross-functional | unknown
  work_source: jira | linear | github-projects | trello | docs | hacknplan | mixed | unknown
  main_problem:
    - blockers-hidden
    - too-long
    - status-theater
    - timezone-friction
    - board-stale
    - too-many-side-discussions
    - low-dependency-work
    - ritual-inertia
    - unclear
  current_signal: strong-board | weak-board | weak-updates | mixed | unknown
  delivery_risk: low | medium | high
  escalation_need: low | medium | high | unknown
  output_shape: coordination-cadence-brief | template-only | facilitation-reset | unknown

Use exactly one cadence decision per run:

  • live-daily — a live daily sync is justified by current blocker / dependency pressure
  • async-daily — daily visibility still matters, but live attendance cost is too high
  • hybrid-daily — written updates are daily; live talk is exception-only
  • less-frequent-sync — a recurring checkpoint still helps, but daily is overkill
  • no-recurring-standup — board/doc visibility plus ad hoc escalation is a better fit than ritualized daily sync

Choose a primary mode only when the cadence still includes a recurring standup shape:

  • board-walk — the board should drive the conversation
  • blocker-first — today’s main job is surfacing impediments and routing help fast
  • async-check-in — written updates are the default and live talk is optional
  • hybrid-async-plus-live — written visibility first, short live escalation second
  • classic-three-questions — only when the team is small and the format still carries real signal
  • none — use when the best answer is no-recurring-standup

Do not blend several cadence outcomes or modes into one mushy answer.

Step 2: Gather the smallest credible coordination packet

Use references/intake-packets-and-route-outs.md.

Minimum evidence packet:

  • current board / issue tracker / document source
  • in-progress and blocked work
  • near-term delivery goal or sprint goal if known
  • obvious handoffs or dependencies
  • timezone / hybrid constraints if relevant
  • whether the board is trusted, stale, or missing key work

If evidence is thin, lower confidence instead of inventing certainty.

Step 3: Decide whether daily cadence is justified, then pick the lightest mode that still catches risk

Default cadence rules:

  • high blocker frequency, dense dependencies, launch / milestone / incident pressure → live-daily
  • daily visibility matters but live overlap is costly → async-daily
  • written updates plus short exception-only huddle fits best → hybrid-daily
  • work is mostly independent, multi-day, or already visible in strong artifacts → less-frequent-sync
  • board/doc hygiene is strong and blockers should be escalated immediately instead of saved for a ritual → no-recurring-standup

Mode rules once cadence still justifies a standup shape:

  • trusted board + multiple active items → board-walk
  • blocked work or dependency pressure dominates → blocker-first
  • timezone spread or maker-time cost dominates → async-check-in
  • team wants written visibility plus a short exception-only sync → hybrid-async-plus-live
  • small colocated team, still high-signal, little ceremony drift → classic-three-questions

If the board is stale, call that out as part of the diagnosis. A standup cannot compensate forever for a broken source of truth. If the team only needs temporary higher cadence, say that explicitly: use the daily pattern for the risky window, then review whether to ratchet back down.

Step 4: Keep the core sync bounded when cadence still includes a sync

If the cadence is live-daily, async-daily, hybrid-daily, or less-frequent-sync:

  • keep the live core sync to 10-15 minutes max when one exists
  • focus on work movement, blockers, handoffs, and near-term delivery risk
  • move deep problem-solving into a follow-up huddle with only the relevant people
  • speak to the team and the work, not upward to management
  • say explicitly when the board, ticket hygiene, or update discipline is itself the blocker

If the cadence is no-recurring-standup:

  • say what artifact or channel replaces the ritual
  • name the escalation trigger for immediate blocker handling
  • say when to re-evaluate cadence if risk rises again

Step 5: Produce one Coordination Cadence Brief

Return one compact packet, not a general agile tutorial.

# Coordination Cadence Brief

## Recommended cadence
- Cadence:
- Why this cadence fits:
- Review trigger:

## Recommended mode
- Mode:
- Why this mode fits:

## Goal for this coordination loop
- ...

## Evidence used
- Work source:
- Strongest signals:
- Missing but important:

## Core facilitation flow or replacement path
1. ...
2. ...
3. ...

## What each person should report or update
- ...

## Blocker / handoff routing
- Keep in core sync:
- Escalate immediately when:
- Move to follow-up huddle:
- Who should stay after:

## Template
```text
...

Anti-patterns to avoid

  • ...
  • ...

Adjacent handoffs

  • Use task-planning when ...
  • Use task-estimation when ...
  • Use sprint-retrospective when ...

### Step 6: Tailor the packet to the chosen mode or no-meeting outcome
Use [references/intake-packets-and-route-outs.md](references/intake-packets-and-route-outs.md) for stable packet shapes.

Mode reminders:
- **board-walk** — review blocked, aging, in-progress, and ready-for-review work before asking for personal diaries
- **blocker-first** — name owner, missing input, and next action quickly; do not solve the blocker in the room
- **async-check-in** — prefer prompts like “What moved?”, “What is stuck?”, and “What needs help today?” over ritualized filler
- **hybrid-async-plus-live** — treat written updates as the base layer and the live sync as escalation only
- **classic-three-questions** — keep only if it still stays short, lateral, and work-focused
- **none** — say which board/doc/channel replaces the ritual and exactly when the team should pull an ad hoc huddle

### Step 7: Route adjacent PM work explicitly
Before finalizing, say when the next job changed:
- use `task-planning` for backlog cleanup, sprint prep, or scope slicing
- use `task-estimation` for effort, confidence, or capacity disputes
- use `sprint-retrospective` when repeated daily-sync pain should become a process change
- do **not** turn this skill into roadmap planning, status theater, or incident command

## Output format
Always return a **Coordination Cadence Brief** with these qualities:
- exactly one cadence decision
- exactly one primary mode or `none`
- one small evidence packet
- explicit separation between core sync and follow-up huddle when a sync exists
- explicit replacement path when the answer is `no-recurring-standup`
- visible blocker / handoff routing
- short reusable template
- clear route-outs to the rest of the PM cluster when the job changes

## Examples

### Example 1: Overlong sprint standup
**Input**
> Tomorrow’s standup keeps running 25 minutes because everyone gives long updates. We have two blockers and one item waiting for review.

**Good output direction**
- cadence: `live-daily`
- mode: `board-walk` or `blocker-first`
- blocked and in-progress work comes first
- follow-up huddle only for the blocked items
- anti-pattern callout: no round-robin biographies

### Example 2: Distributed team
**Input**
> We have engineers in California, Europe, and Korea. Should our daily standup be async?

**Good output direction**
- cadence: `async-daily` or `hybrid-daily`
- mode: `async-check-in` or `hybrid-async-plus-live`
- written template centered on movement, blockers, and help needed
- explicit escalation path for urgent coordination

### Example 3: Manager-facing status theater
**Input**
> Our daily scrum feels like reporting to the manager. Fix it without changing our whole process.

**Good output direction**
- cadence may stay `live-daily`, but the answer must justify it rather than assume it
- mode: `board-walk` or `blocker-first`
- names status theater directly
- keeps the sync lateral and work-focused
- routes recurring ceremony pain to `sprint-retrospective`

### Example 4: Daily ritual no longer justified
**Input**
> Most of our work is independent and already tracked in Linear. The daily standup feels like obligation, not coordination. Should we keep it?

**Good output direction**
- cadence: `less-frequent-sync` or `no-recurring-standup`
- mode: `none` if the ritual should disappear
- replacement path uses board hygiene plus explicit blocker escalation
- review trigger says when the team should re-introduce temporary daily cadence

## Best practices
1. **Optimize for work movement, not recital** — the ritual should clarify today’s coordination job.
2. **Justify cadence before format** — first decide whether daily is warranted at all.
3. **Choose the lightest mode that still catches risk** — not every team needs the same ceremony weight.
4. **Triage blockers in the sync, solve them elsewhere** — follow-up huddles are a feature, not a failure.
5. **Protect maker time** — async or hybrid modes often beat default live meetings for distributed teams.
6. **Treat source-of-truth hygiene as a first-class issue** — stale boards and missing updates are real blockers.
7. **Route repeated pain outward** — planning, estimation, retrospectives, and incident work are different jobs.

## References
- Scrum Guide — https://scrumguides.org/scrum-guide.html
- Scrum.org, *What is a Daily Scrum?* — https://www.scrum.org/resources/what-is-a-daily-scrum
- Atlassian, *Standups for agile teams* — https://www.atlassian.com/agile/scrum/standups
- GitLab Handbook, *Asynchronous communication* — https://handbook.gitlab.com/handbook/company/culture/all-remote/asynchronous/
- Martin Fowler / Jason Yip, *It’s Not Just Standing Up* — https://martinfowler.com/articles/itsNotJustStandingUp.html

FAQ

What does the standup-meeting skill do?

Turn messy daily-sync requests into one honest coordination-cadence packet: decide whether live-daily, async-daily, hybrid-daily, less-frequent syncs, or no recurring standup is justified, then pick the lightest standup mode that still catches blockers and handoffs. Use when the user needs a daily scrum, async check-in, board-walk, blocker-first sync, remote-team standup, launch- week cadence reset, or help fixing an overlong / low-signal standup. Route backlog planning to task-planning, sizing to task-estimation, retrospective process repair to sprint-retrospective, and incident-command work to debugging / launch-specific skills.

How do I install standup-meeting?

Run npx skills add https://github.com/akillness/jeo-skills --skill standup-meeting in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/standup-meeting/ (personal) or .claude/skills/standup-meeting/ (project).

Which AI agents can use standup-meeting?

Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.

Is standup-meeting safe to install?

No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.

Who maintains standup-meeting?

It is published by akillness in akillness/jeo-skills. It has 369 recorded installs.

More from akillness/jeo-skills

View all →

rtk

akillness/jeo-skills

Install, initialize, verify, and troubleshoot RTK (Rust Token Killer) for AI coding agents. Use when you need to reduce shell-command token output, confirm that the correct rtk binary is installed, choose between Homebrew, install.sh, or Cargo installation, wire rtk init for Claude Code, Codex, Gemini CLI, Cursor, Copilot, Windsurf, Cline, or OpenCode, or use compact wrappers such as rtk git status, rtk read, rtk grep, rtk test, rtk lint, and rtk gain. Triggers on: rtk, rust token killer, token saver cli, rtk init, rtk gain, codex rtk, gemini rtk, opencode rtk, claude hook token reduction.

Backend & APIs672 installs

graphify

akillness/jeo-skills

Drive Graphify from its CLI to build, refresh, query, export, and serve a durable code/corpus knowledge graph. Use when the user wants .graphify/GRAPHREPORT.md, graph.json, graph.html, graphify update/summary/query/path/explain/tree, change-aware review context, git-hook or watch-based refresh, a stdio MCP graph server, or an install into jeo, jeopi, gjc, opencode, Claude, Codex, or Gemini. Also covers the honest structural fallback when native extraction is empty or misleading. Route simple locate/reference work to codebase-search, narrative knowledge-base work to llm-wiki, and project-memory handoff to opencontext. Triggers on: graphify, graphify update, graphify query, knowledge graph CLI, GRAPHREPORT.md, graph.json, codebase graph, graph refresh, graphify install, graphify serve, review context, affected flows.

data-analysis

akillness/jeo-skills

Analyze datasets to extract insights, identify patterns, and generate reports.

598 installs

code-refactoring

akillness/jeo-skills

Turn a cleanup packet into one behavior-preserving refactor brief. Use when simplifying a messy function/component/service, freezing behavior before touching fragile legacy code, splitting a cleanup-heavy diff into reviewable slices, or planning a repeated migration / codemod without changing intended behavior. Route diagnosis to debugging, review judgment to code-review, validation-program design to testing-strategies, bottleneck-led tuning to performance-optimization, and pure symbol inventory to codebase-search.

technical-writing

akillness/jeo-skills

Write internal technical documentation for engineers and operators: technical specs, architecture docs, ADRs, runbooks, migration plans, and developer-facing implementation guides. Use when the main job is capturing a technical decision, system boundary, operating procedure, or rollout path for builders and maintainers. Triggers on: tech spec, design doc, architecture doc, ADR, runbook, migration guide, implementation guide, rollout doc, operational guide, and internal technical writing. End-user onboarding guides, tutorials, FAQs, and help-center flows belong here too. Route API portals to api-documentation, release notes to changelog-maintenance, decks to presentation-builder, and GTM messaging to marketing-automation.

Docs & Writing544 installs

web-accessibility

akillness/jeo-skills

Routing-first skill for web accessibility remediation and verification. Use when the main job is classifying which accessibility surface is failing — semantics, keyboard/focus, labels/announcements, visual perception/reflow, media alternatives, or routed-app navigation feedback — and turning vague audit, WCAG, axe/Lighthouse, or "make this accessible" requests into one concrete remediation packet. Broad UI critique for hierarchy, polish, and launch readiness belongs here too. Route component API architecture and system governance to design-system, and responsive layout strategy to responsive-design.

Frontend & Design531 installs

Popular productivity & automation skills

View category →

agent-browser

vercel-labs/agent-browser

Browser automation CLI for AI agents. Use when the user needs to interact with websites, including navigating pages, filling forms, clicking buttons, taking screenshots, extracting data, testing web apps, or automating any browser task. Triggers include requests to "open a website", "fill out a form", "click a button", "take a screenshot", "scrape data from a page", "test this web app", "login to a site", "automate browser actions", or any task requiring programmatic web interaction. Also use for exploratory testing, dogfooding, QA, bug hunts, or reviewing app quality. Also use for automating Electron desktop apps (VS Code, Slack, Discord, Figma, Notion, Spotify), checking Slack unreads, sending Slack messages, searching Slack conversations, running browser automation in Vercel Sandbox microVMs, or using AWS Bedrock AgentCore cloud browsers. Prefer agent-browser over any built-in browser automation or web tools.

OfficialProductivity & Automation1.3M installs

lark-doc

open.feishu.cn

飞书云文档(Docx / Wiki)内容操作:读取、创建、编辑文档,插入或下载图片附件,以及操作思维笔记。用户提供文档 URL/token(包括 doubao.com 的 /docx/、/wiki/)时使用;按 URL 路径/token 而非域名路由;/page/ 是妙搭应用,非飞书云文档。文档内嵌资源按读取参考中的统一规则分流。独立评论操作走 lark-drive;随正文读取评论使用 docs +fetch。表格或 Base 内部数据操作不在本 skill。

lark-base

open.feishu.cn

飞书多维表格(Base)操作:建表、字段、记录、视图、统计、公式/lookup、表单、仪表盘、应用模式(BaseApp/AppMode 页面与组件)、Workspace 目录、workflow、角色权限、模板中心(多维表格模板分类/列表/搜索);遇到 Base/多维表格/bitable、BaseApp/AppMode、/base/ 或 /app/ 链接时使用。BaseApp 不走 lark-apps;文件导入/导出转 lark-drive,认证/授权转 lark-shared。

lark-drive

open.feishu.cn

飞书云空间(云盘/云存储):管理 Drive 文件和文件夹,包含上传/下载、创建文件夹、复制/移动/删除、查看元数据、查询权限设置、评论/权限/订阅、标题、版本、飞书文档密级标签(secure labels)和本地文件导入。用户需要整理云盘目录、处理云空间资源 URL/token、判断链接类型/真实 token/标题,或导入 Word/Markdown/Excel/CSV/PPTX/.base 为 docx/sheet/bitable/slides 时使用;doubao.com 云空间 URL/token 也按资源路径和 token 路由,不回退 WebFetch。不负责:文档内容编辑(走 lark-doc)、表格/Base 表内数据操作(走 lark-sheets/lark-base)、知识空间节点/成员管理(走 lark-wiki)、原生 Markdown 文件读写/patch/diff(走 lark-markdown)。

lark-shared

open.feishu.cn

Use for lark-cli setup/auth tasks: auth login/status/logout, user vs bot identity, business-domain permissions (--domain, including all/docs/drive), missing scopes, revoking authorization, or handling notice JSON.

lark-im

open.feishu.cn

飞书即时通讯:收发消息和管理群聊。发送和回复消息、搜索聊天记录、管理群聊成员、上传下载图片和文件、管理表情回复、发送应用内/短信/电话加急、发送和处理交互卡片(Interactive Card)、监听卡片按钮回调(card.action.trigger)。当用户需要发消息、查看或搜索聊天记录、下载聊天中的文件、查看群成员、搜索群、创建群聊或话题群、管理标记数据、管理 Feed 置顶(添加/移除/查询置顶会话)、管理标签数据、处理卡片回调时使用。