compass-calendar

Ship the current Compass branch end-to-end: validate locally in Chrome when user-visible, review and simplify the diff, commit and open a ready PR, monitor and fix CI, squash-merge when safe, then monitor the main-branch release, staging deploy, and health check. Use when the user says ‘ship’, ‘ship it’, ‘ship this branch’, or asks to take current Compass work through merged and verified delivery.

Simplifies code by minimizing complexity, eliminating duplication, and prioritizing legibility for contributors. Use when implementing features, fixing bugs, refactoring, or when the user asks to simplify, clean up, make DRY, reduce complexity, or improve maintainability.

Team standup for the Compass roles. Spawns the four agent roles (QA, Fullstack, Architect, Product Owner) in parallel; each reviews the codebase/app against its charter and reports 3 bullets of recent work, top-3 next priorities, and blockers. Synthesizes into team/standups/YYYY-MM-DD.md, records founder decisions, then autonomously implements and lands every approved item via a serialized-merge workflow — no further launches needed from the founder. Use when the founder says "/standup", "run standup", "team standup", or "what's the team's status".

The team cleanup ritual from TEAM.md. Review everything merged to main since the last cleanup, run the `simplify` skill over those diffs, and auto-merge simplification PR(s) so the code ends up cleaner than it started — never sloppier. Also run a `qa-ux-sweep` over the merge window to catch usability/a11y friction and auto-fix it. Then log the close-out and run a `/qa-test-staging` sweep so the founder can do a final review of the living app in staging. Use when the founder says "/cleanup", "run the evening cleanup", "clean up the day's work", or "tidy up before I review staging".

Use when reviewing UI diffs, accessibility audits, or flaky UI tests to catch a11y regressions, semantic issues, keyboard/focus problems, and to recommend minimal fixes plus role-based test selectors.

Post-merge QA sweep of staging.compasscalendar.com in the user's real Chrome - select and verify the correct signed-in staging profile (never the localhost/temp-account one), run the standard usage flows as the authed test user watching console/network for breakage, then read the recent merged PRs and exercise their Manual Testing Steps to catch regressions in freshly-touched flows. Use when the user says "/qa-test-staging", "sanity check staging", "test staging", "check staging after deploy", "run the staging sweep", or asks to verify the staging deploy after a PR merged.

Proactively explore the app's recently-changed surfaces like a first-time user, looking for usability, accessibility, and UX friction (confusing focus order, missing labels, awkward keyboard paths, unclear states) that automated tests wouldn't catch - then fix what's fixable and ship it through the normal PR flow, same ship autonomy as any role session. Use when the user says "/qa-ux-sweep", "find UX bugs", "check for a11y issues", "play with the app and find problems", or when invoked by a role session after a PR ships, or by cleanup (over the merge window).

Review changed code in this repo for reuse, duplication, and unnecessary complexity — including overuse of useEffect/useRef/useState in React — then apply legibility-focused fixes using Compass conventions (Bun/Biome, packages/core|web|backend|scripts, Zustand stores). Quality only — it does not hunt for correctness bugs; use /code-review for that. Use when asked to simplify, clean up, make DRY, reduce complexity, or improve maintainability, or proactively while implementing features, fixing bugs, or refactoring.

Ship the current branch end-to-end - validate the change in a local Chrome preview, run a correctness-focused code review and fix what it confirms, commit it, run the simplify skill for a distinct follow-up commit, open a non-draft PR with a lower-case conventional-commit title, watch CI and push fixes for any failures, squash-merge once green, then watch the post-merge GitHub Actions on main (release tag, docker publish, staging deploy, health check). Use this whenever the user says "ship this", "ship it", "ship the branch", or asks to take the current work from local changes all the way to a merged, deployed PR instead of doing each step manually.

Use when reviewing UI diffs, accessibility audits, or flaky UI tests to catch a11y regressions, semantic issues, keyboard/focus problems, and to recommend minimal fixes plus role-based test selectors.