standup

name	standup
description	Session standup protocol. Execute at the start of every session to build full working memory before any substantive work begins. Reads project state files, checks for staleness, and produces a structured sync summary. Use this skill whenever starting a new session, when the user says /standup, or when context feels stale mid-session. Always run this before doing any real work.

Session Standup

This skill builds full working memory at the start of every session. It eliminates the ramp-up period where you operate without context and the user has to manually re-feed information from previous sessions. Do not start substantive work until this protocol completes and the user confirms.

Why This Exists

Persistent projects accumulate decisions, state changes, and context across many sessions. Without a structured standup, early-session work risks operating on stale assumptions, missing recent decisions, or duplicating effort. The /conclude skill captures everything at session end; this skill ingests it at session start. They are a matched pair.

Execution Steps

Run these steps sequentially. Do not skip steps. Do not start working on anything until the final step is complete and the user confirms.

Step 1: Core Reads

Read all state files completely. Do not skim. Do not rely on memory from prior sessions — read the current files every time.

1. STATUS.md (project root) — Current project state, priorities, open decisions. This is the entry point and quick-glance overview of where things stand.

2. Latest file in session-logs/ (sort by filename date, most recent first) — What happened last session: files modified, decisions made, open threads, state at session end. If the log contains a <!-- session-state ... --> block, parse it for structured metadata (open thread count, pending handoffs, priority changes, suggested next focus).

3. Additional state files (if your project has them — delete this item if not):

Step 2: Staleness Detection

After reading the core files, check for signs that the project state might not reflect reality:

• STATUS.md age: Parse the "Last updated" line. If the date is more than 7 days ago, flag it: "STATUS.md was last updated X days ago — may not reflect recent work done outside this environment."
• Session log gap: If the latest session log is more than 7 days old, flag it: "Last session log is X days old — significant work may have happened elsewhere since then."
• Session state block: If the latest log has a <!-- session-state --> block, check for handoffs_pending entries or high open_threads counts and flag them.

These are informational flags, not blockers. Note them in the output and move on.

Step 3: Handoff Check

This step supports cross-project context sharing. If your project doesn't use handoffs, these directories won't exist and this step skips silently.

• Check if Incoming/ exists in the project root. If it contains files, read each one — these are context artifacts from other projects that need integration.
• Check if Outgoing/ exists. If it contains files, these are unrouted handoffs from a previous session. Flag them: "X unrouted handoff(s) in Outgoing/ from previous sessions."
• If neither directory exists, skip silently — don't mention handoffs in the output.

Step 4: Conditional Deep Reads

Based on the session log and the user's opening message, determine if additional reference files should be read for deeper context.

If the session focus isn't clear from context, ask the user before doing deep reads — don't read everything speculatively. If this step has no entries configured, skip it.

Step 5: Output

Produce a standup summary with these sections. Keep it tight — this is a sync, not a report.

Where we left off: What the last session accomplished and any unfinished threads. Reference the session log date and key outcomes.

Current priorities: The highest priority items from STATUS.md, in order.

Open decisions: Anything unresolved that might affect today's work.

Staleness flags: Any warnings from Step 2 (omit this section entirely if nothing is stale).

Incoming handoffs: Any cross-project artifacts found (omit this section entirely if nothing to report).

Session focus: What the user seems to want to work on today, inferred from their opening message. If unclear, ask.

After producing the summary, wait for the user to confirm or correct before proceeding to any work. If something is off or stale, they correct it here — before time gets burned going the wrong direction.

Important Reminders

• Every session, every time. Do not skip the standup even if you think you have context from a recent session. Files may have been updated by other tools or sessions since your last conversation.
• Read the actual files. Do not rely on memory from prior conversations. The workspace is the source of truth, not your recollection.
• The standup is not the work. Keep it concise. The goal is to sync and confirm, then get into the real work as fast as possible.