standup
Standup — Cross-Project Status Report
What This Does
Generates a concise standup report by recalling checkpoints across all workspaces and reviewing active plans from multiple sources. Covers what happened, what's next, and what's stuck.
How to Generate a Standup
Step 1: Recall cross-project activity
mcp__goldfish__recall({ workspace: "all", days: 1 })
For a Monday standup covering the weekend:
mcp__goldfish__recall({ workspace: "all", days: 3 })
For a custom range:
mcp__goldfish__recall({ workspace: "all", from: "2026-02-10", to: "2026-02-14" })
Step 2: Gather plans from ALL sources
Plans may exist in two locations per project. Check BOTH:
Source 1: Goldfish plans — already included in recall output if an active plan exists.
Source 2: Project plan docs — scan docs/plans/*.md in each project that appeared in the recall results. Read files modified in the last 14 days (skip older ones — they're likely completed). Look at the **Status:** field in the header of each file.
Step 3: Assess plan status from evidence
Do NOT blindly trust the Status field in plan docs. Cross-reference against checkpoints:
- Status says "Approved" + checkpoints show all tasks done → effectively complete, note as done
- Status says "Approved" + checkpoints show partial progress → in progress, report remaining items
- Status says "Approved" + no checkpoint activity → upcoming work, report as planned
- Status says "Complete" → trust it, skip or mention briefly as done
For Goldfish plans (from recall), use the plan's status field directly — it's managed by the agent via the plan tool.
Step 4: Synthesize the report
Report Format
Structure the standup with these rules:
- One bullet per accomplishment. Each on its own line for easy scanning.
- Lead with impact, not activity. "Shipped auth refresh tokens" not "Worked on auth."
- Use past tense for done items. "Fixed," "Implemented," "Shipped."
- Blockquote (
>) for forward-looking items. Visually separates past from future. - Abbreviated month names in headers.
Feb 14notFebruary 14. - Date range in header when covering multiple days (
Feb 12–14, 2026). - Always state blockers explicitly. If none, say "Nothing currently blocked."
Multi-Project Format
When checkpoints span multiple projects, group by project with bullets for accomplishments, blockquotes for next/blocked, and plan references:
## Standup — Feb 14, 2026
### goldfish
- Implemented 4 skill files with behavioral language patterns
- Converted tool handlers from JSON to markdown output
> Next: Test skills with live agent sessions
> Plan: v5.1 skills refresh — 2/4 tasks complete (docs/plans/2026-02-16-v5.1-implementation.md)
### api-gateway
- Fixed rate limiter race condition in Redis cluster mode
- Added integration tests for multi-node scenarios
> Next: Deploy to staging, run load tests
> Blocked: Waiting on DevOps for staging Redis cluster
Single-Project Format
When all checkpoints are from a single project, drop the project grouping and use section headers:
## Standup — Feb 14, 2026
### Done
- Implemented 4 skill files with behavioral language patterns
- Converted tool handlers from JSON to markdown output
### Up Next
- Test skills with live agent sessions
- v5.1 skills refresh: workspace env var implementation (2/4 tasks complete)
### Blocked
- Nothing currently blocked
Synthesis Rules
- Be concise. A standup is 2 minutes, not 20. One line per accomplishment.
- Group by theme. Five checkpoints about "auth" become one bullet: "Implemented auth token refresh with rotation."
- Highlight blockers prominently. These are the most actionable items in a standup.
- Skip noise. Minor refactors, formatting changes, and config tweaks don't need individual mentions unless they were the main work.
- Use past tense for accomplishments. "Shipped," "Fixed," "Implemented" — not "Working on" for done items.
- Surface decisions. If a checkpoint captured an architectural decision, mention it briefly — the team may need to know.
- Include plan progress. When active plans exist, include a brief progress summary (e.g., "3/5 tasks complete") in the Up Next section.
Handling Edge Cases
No checkpoints found
Report honestly: "No activity recorded in the requested period." Don't fabricate.
Single project only
Use the single-project format above (Done / Up Next / Blocked sections).
Too many checkpoints (20+)
Be more aggressive about grouping. Summarize by theme rather than listing individual items. A standup with 15 bullet points defeats the purpose.
No plans found
That's fine — just skip the plan progress lines. Not every project has active plans.
Plans in docs/plans/ but no Goldfish plan
Include them in the forward-looking section. Plans don't need to be in Goldfish to be useful for standup.
Critical Rules
- Do NOT ask the user what to include. Recall gives you everything. Synthesize it yourself.
- Do NOT fabricate activity. Only report what checkpoints actually show.
- Keep it standup-length. If your report is more than a screenful, you're being too verbose.
- Include dates when covering multi-day ranges so the reader knows the timeline.
- Check BOTH plan sources.
.memories/plans/(via recall) ANDdocs/plans/(via file reading). Missing one source means an incomplete forward-looking view. - Infer plan status from evidence. Don't trust stale Status headers — verify against checkpoint activity.
More from anortham/goldfish
recall
Restore context from Goldfish developer memory — use when starting a new session, after context loss, searching for past work, or when the user asks what happened previously, wants to find old decisions, or needs cross-project context
13plan
Create and manage persistent plans in Goldfish memory — use when starting multi-session work, making architectural decisions, or when the user discusses project direction, roadmaps, or design decisions that need to persist across sessions
13plan-status
Assess progress against the active Goldfish plan using checkpoints and plan data — use when the user asks about project progress, how things are going, what's been accomplished, or wants a status check against their plan
12checkpoint
Save developer context to Goldfish memory — checkpoint at meaningful milestones, not after every action
12session-memory
Automatically restore session context from persistent memory at the start of every coding session. Use this skill IMMEDIATELY when starting work to recall previous checkpoints, active plans, and git context. MANDATORY for context restoration.
2progress-tracking
Proactively checkpoint work progress at key moments without asking permission. Use when completing tasks, fixing bugs, making discoveries, or reaching milestones. Builds persistent memory across sessions.
2