Sign in with your Google account to see what the agents are doing.
Each agent owns one document, agentStatus/<name>, in the ops Firebase project and updates it at milestones with node apps/agent-dashboard/scripts/agentStatus.mjs --agent <name> --status … --now … --log …. Gus is updated by the agent-gus GitHub Actions workflow on every push, pull request and merge. The board updates as soon as anything is written.
{
"name": "Walter", // first name, tied to the task
"role": "Apple Watch",
"order": 2, // card position
"status": "working", // working · review · meeting · needs-you · done · idle · blocked
"meetingWith": ["gus"], // status meeting: who they are talking with
"now": "Writing the watch ↔ phone message protocol",
"session": "Background agent of the start-flow session",
"branch": "claude/apple-watch",
"prs": [{ "n": 3, "title": "Start Match Flow", "state": "merged" }],
"needsYou": ["Approve a watch-target plugin dependency"],
"next": ["Swift scoring port with shared fixtures"],
"log": [{ "at": "2026-10-02T21:15:00Z", "text": "Started on branch claude/apple-watch" }],
"updatedAt": "2026-10-02T21:15:00Z"
}
What we’re building, which team builds which part, and where the teams hand work to each other. The apps are what players and coaches install; the website is what people see before they install. Teams and live status come from the dashboard, so the plan follows when an agent changes team.
Teams that only work on the apps are on the left, website teams on the right, teams that serve both in the middle. Tap a team or a handoff to highlight it.
Every requirement in rank order: the higher it is, the sooner it’s built. A requirement says why and what; Rita’s team turns it into user stories with acceptance criteria and then moves it to To approve. An admin approves it (To approve → Ready), Pablo checks the UI/UX, and the agent that starts on it moves it to In development itself (never from this board). Once it is merged and deployed it goes to In QA; Quinn’s team tests it and moves it to Ready for release, where you sign it off (Closed). Blocked holds work that waits on something else; epics group requirements, and Lanes by epic shows them as swimlanes.
Loading requirements…
No product ships to production without Steven’s sign-off. An agent asks for one with the release candidate (a preview URL or test build); Steven approves it or rejects it with a note. The production deploy checks for an approved sign-off of the same commit, and GitHub asks Steven to approve the deployment too.
Loading sign-offs…
What changed in each deployed version of the back office, newest first, with links to its requirements and PRs. Reese writes the notes after each deploy; the version in the footer of every page links to its own notes.
Loading release notes…
What shipped on which day (back-office deploys and shipped releases) and what is planned. Admins plan releases on the Requirements page (Plan releases).
The Claude Code hooks, checks and agents of each repository: which gates exist, what they check, and why an agent was blocked. Each repository's CI publishes this from its .claude/ folder on every push to main. Read-only; changes go through a PR in the repository.
Each team gets its own room in the office and its own section of cards. Rename a team, change its colour, add one, or move agents between teams. Agents without a team wait in the Lobby.
People who signed in with Google and asked to see the dashboard. Approve them as a viewer, or as an admin who can also approve others.
Owners can't be changed or removed here. Removing someone signs them out of the dashboard on their next load.
The Claude Code hooks, check targets and project agents of court-apps, court-website and court-backoffice, as each repository's CI last reported them.
Social
Reese proposes a post per channel for every release, in English and Dutch. Check the image and text, post it by hand (Copy text, Download image), then mark it as posted, or reject it with a reason so the next one is better. Agents never post themselves.
Loading proposals…