Metadata

name

setup-async-standup

description

Configure and create a native weekday Slack async-standup automation through a gated discovery, interview, read-only preflight, prompt-instantiation, and scheduler-verification workflow. Use when a user asks to set up, schedule, or automate a daily Slack standup that gathers evidence from Slack, repositories and Git hosting, coding-agent histories, Linear, Notion, meeting or transcript tools such as Granola and Grain, or other work sources. Do not use this skill to run or post the standup itself.

Setup Async Standup

Configure the automation in two phases: resolve and verify every required value, then create and read back the native schedule. Never run or post a standup during setup.

Enforce the configuration gate

• Use read-only operations until the configuration is complete.
• Never create the automation while a required value is unknown, ambiguous, inaccessible, or represented by a placeholder.
• Verify values from governing sources when confidence is high. Ask the user to choose when multiple values are plausible.
• Ask how to access an unknown source. If authentication is missing, ask the user to authenticate it or explicitly configure that source as NONE.
• Never ask the user to paste a token, cookie, password, API key, or other secret into chat.
• Ask whether an optional source should be configured or set to NONE; never silently omit it.
• Consolidate all unresolved items into one concise questionnaire and wait for the answers. Do not create a schedule in the same turn as an unanswered questionnaire.
• After the answers, run a read-only preflight. If it exposes another ambiguity or access problem, ask only the remaining questions and wait again.

Phase 1: Discover and interview

Read applicable workspace instructions and the complete instructions for each installed scheduling, Slack, Git-hosting, planning, documentation, meeting-transcript, or coding-agent integration selected for this setup. Inspect the system read-only to resolve as much of the following as possible.

Schedule

• Resolve the schedule name; default it to Daily Slack async standup unless the user chooses another name.
• Ask for the exact local standup time. Store it as {{STANDUP_TIME}}; do not assume a time.
• Resolve and save the user's explicit IANA timezone as {{IANA_TIMEZONE}}.
• Confirm Monday through Friday as the intended workdays. Do not add public-holiday exclusions unless the user requests a business-calendar integration.
• Use the agent platform's native scheduling or automation capability and enable the schedule immediately after creation.
• Prefer skip-missed-run and single-flight/no-overlap behavior when supported. Record unsupported when the native scheduler lacks either feature.
• Do not create cron, launchd, Task Scheduler, or another OS-level job unless no native scheduler exists and the user explicitly approves that fallback.

Identity and writing style

• Resolve the user's name and company or work scope.
• Resolve the voice and name the Slack post should use.
• Resolve whether posting uses the user's Slack identity, an authorized bot, or a customized bot identity.
• Record concise writing-style notes from prior standups when available.

Slack

• Resolve the Slack workspace, standup channel ID, and current channel name.
• Resolve the user's Slack user ID and inspect the raw identity signature of a previous standup reply when one exists.
• Record every verified field needed for reliable duplicate detection, including user ID, bot ID, app ID, customized username, or message subtype as applicable. Never use a shared bot ID alone unless another field proves the reply represents this user.
• Resolve how to identify the daily standup root and whether the channel is public or private.
• Resolve the authenticated Slack connector, CLI, app, or profile for reading and posting.
• Verify whether the posting method preserves native Block Kit rich-text lists and whether customized display name or avatar behavior is authorized.
• Ask what to do when the root has not appeared by {{STANDUP_TIME}}: stop for the day or retry for a user-selected duration that fits within the maximum runtime.

Repositories and Git hosting

• Resolve the user's Git-host login and Git author names and email addresses.
• Enumerate every local repository and linked worktree that counts as work.
• Resolve each remote repository and default branch.
• Resolve the authoritative Git host and authenticated CLI or connector.

Coding-agent activity

• Resolve every coding-agent system in use, such as Codex, Claude Code, Cursor, or another system.
• Resolve session-history locations and formats.
• Resolve how to exclude subagent or internal-worker sessions.
• Resolve how detached worktrees map to repositories using Git remotes.

Planning and documentation

• Determine whether Linear is enabled. If so, resolve the user's identity, in-scope workspace or teams, authenticated access method, and read-only access to issues, projects, comments, and history.
• Determine whether Notion is enabled. If so, resolve the user's identity, in-scope workspace, authenticated access method, and author-attributed page search and reading access.
• Set either integration to NONE only with the user's explicit confirmation.

Meetings and transcripts

• Determine which meeting calendars, note systems, recording systems, and transcript sources count as evidence. Explicitly check for Granola, Grain, Fathom, Otter, Fireflies, Gong, Zoom transcripts, Google Meet or Drive transcripts, Microsoft Teams or SharePoint transcripts, and any similar configured source.
• Resolve the user's identity, workspace or account, authenticated connector, CLI, app, profile, or local storage path for each source.
• Verify read-only discovery of meetings in a time window and access to available titles, attendees, timestamps, summaries, action items, speaker attribution, and transcripts.
• Resolve which meeting classes are in scope, such as internal, customer, recruiting, planning, or incident meetings, and any exclusions required for privacy or confidentiality.
• Mark each meeting source as required, optional, or NONE. A calendar may establish that a meeting happened, but do not treat it as evidence of the meeting's content without notes, a transcript, or corroboration.

Other sources

• Resolve any additional work source, such as Jira, Google Docs, incident management, email, or another repository.
• Resolve non-secret authentication and whether each source is required, optional, or NONE.

Runtime and memory

• Resolve a working directory suitable for scheduled commands and any environment-loading prefix required before authenticated commands.
• Resolve a stable, persistent, user-owned memory-file path.
• Record known stale worktrees or evidence locations to ignore.
• Resolve the maximum reasonable runtime. Ensure any root retry duration fits within it.

Ask the consolidated questionnaire

For every unresolved or ambiguous item:

• Explain what must be selected and include verified candidates when available.
• Do not silently choose among plausible Slack channels, identities, repositories, workspaces, authentication profiles, schedule times, timezones, or meeting sources.
• For a missing integration, ask the user to authenticate it or approve NONE.
• Do not ask for secrets.
• Wait for the answer before continuing.

Phase 2: Preflight and create

1. Resolve every configuration value to a verified value or an explicit NONE where allowed.
2. Confirm the schedule time and IANA timezone with the user-provided values.
3. Confirm the Slack workspace, channel, authenticated identity, raw channel history, and raw thread-reading access.
4. Confirm the duplicate matcher against a previous raw reply when one is available. If none exists, require a verified user or posting-identity matcher plus user confirmation.
5. Confirm every repository path, remote, default branch, and Git-host access method.
6. Confirm access to every enabled coding-agent history source.
7. Confirm Linear and Notion attribution access when enabled.
8. Confirm meeting discovery and note or transcript reading for every enabled meeting source.
9. Confirm access to every additional enabled source.
10. Confirm that the memory path is persistent and writable by scheduled runs. Use scheduler single-flight behavior or place any required lock beside the memory file; do not rely on an undefined automation directory.
11. Do not send a Slack test message.
12. If critical Slack access fails, stop and ask how to proceed.
13. If an optional source fails, ask whether to repair it or create the automation with that source set to NONE. Do not silently omit it.
14. Read references/daily-standup-prompt-template.md completely.
15. Replace every double-braced variable in that reference with its verified value or an explicit NONE. Preserve the template's behavioral requirements.
16. Verify the instantiated prompt contains no double-braced variables, sample IDs, sample paths, or AUTO_DISCOVER values.
17. Create an enabled Monday-through-Friday native automation at the resolved {{STANDUP_TIME}} in the resolved {{IANA_TIMEZONE}}, using the instantiated daily prompt.
18. Configure skip-missed, no-overlap, and maximum-runtime behavior when supported. Record unsupported capabilities accurately.
19. Read the saved automation back from the scheduler and compare it with the intended configuration.

Report completion

Report:

• Automation name and identifier.
• Exact weekday recurrence, user-selected time, and IANA timezone.
• Enabled state and next run.
• Missed-run, overlap, and maximum-runtime behavior, including any unsupported capability.
• Resolved Slack target and posting identity.
• Included repositories.
• Enabled coding-agent, planning, documentation, meeting-transcript, and additional evidence sources.
• Persistent memory location.
• Read-only preflight results and any remaining limitations.

Do not include secrets. Do not claim success unless the scheduler readback confirms the saved automation and its fully instantiated prompt.