The new alpha is live. This playbook is how we work right now — what the teams do, how things move from idea to live, how we stay in sync, and where to find things. Keep it up to date as things change.
Prototyped forms are with MDAs for approval. Forms and prototyping now sit inside the themed teams rather than as a separate track — each theme owns its own forms and prototype work end to end. Themed teams are focused on creating citizen value in a prioritised set of areas at a time rather than spreading across every theme at once — Health and NIS are prioritised right now.
Reworked as of 2 July 2026. Two foundation teams — Content and Platform — sit underneath three themed teams: Health, NIS, and a shared resource pool that now also covers Youth work directly, rather than only supplying specialists to others. Health and NIS have split out from what was previously one combined thematic team. Update this when the shape changes again.
There are two ways work moves through the teams. The board should reflect where things actually are — especially when something is sitting with an MDA or waiting on FormBuilder.
Signoff happens by email. Before infra will review, the PR needs to show that the right person at the MDA has approved — their name, the date, and a link to the email.
infra label and let infra knowOne board pulls in tickets from the platform, foundation, and themed team projects. Every card needs at least one label. Keep issues up to date and the board looks after itself.
infra means waiting on infra approval.Each team has their own board with columns that match how they actually work. The main board pulls everything together — same cards, different view. Set your columns up to reflect your real workflow.
The themed teams share the same structure since they work the same way. Platform and Content can shape theirs to fit. The labels — MDA, theme, priority, status — are what tie everything back to the main board, so keep those consistent regardless of how the columns are arranged.
The one thing to agree across all teams is what Done means. If it means different things on different boards, the main board becomes unreliable.
Every issue or PR needs at least a status label and either an MDA or theme label. Product team sets the priority labels.
duplicate, enhancement, good first issue, invalid, wontfix, QA. Hold already covers what wontfix was doing, and the MDA and theme labels do what enhancement was trying to.Use these as starting points. Keep everything on one thread per form — don't start a new email chain when you're following up or sending a revised link.
Default to async. Standups, the board, and the twice-weekly Slack updates cover most of what needs covering. Get people together when there's a decision to make.
priority: urgent on the issue and drop a message in the right Slack channel — link and one line of context is enough. Save @channel for actual incidents.This is where we keep Claude prompt templates, AI tooling patterns, and what we've learned about what works. If another team has figured something out, it should be here so you don't have to start from scratch.
Entries live in docs/wiki/skills/. Every entry starts as Draft. It moves to Beta once it's been used with a failure modes section filled in. It becomes Stable when two or more teams have used it successfully.
Generating plain English descriptions of NIS benefit eligibility.Draft / Beta / Stable[service name], [MDA name].Does not work when the citizen has multiple open claims. Required for Beta status.3 June 2026 — PR #47What we know about each MDA — how citizens use their services, how the back office works, what language to use, what the quirks are. When a team picks up an MDA for the first time, or someone new joins, this is where they start.
One file per MDA in docs/wiki/mdas/. Update it after any co-design session, citizen test, or significant conversation.
The wiki only works if it stays current. GitHub auto-flags anything not touched in 60 days. The audit is just deciding what to do with each flag.
documentation. Pick it up next sprint, or sooner if it's blocking someone.docs/wiki/archive/ with a note saying why and when. What didn't work is just as useful to know as what did.A set of short process docs is being written to cover specific pieces of how we work, listed below. Each starts as a first draft from the DMs, then gets iterated by the team actually doing the work as they use it — the aim is something that reflects how people work in practice, not a set of rules handed down and left unchanged.