Startup Studio reference: the board, the stack, every command, and the glossary

This page defines the Startup Studio board, its default technology stack, every command the tool accepts, and the terms used across the site and the repository. It is for anyone running Startup Studio, contributing to it, or checking the precise meaning of a term.

1 > The Board

Every Project uses the same board as its only work queue. It has eight columns, one for each status key, and two further statuses that leave the board rather than sitting in a column. I keep the structure fixed because the agents use these exact names and keys. If they change, the team no longer matches the board.

The cards below are made up, to show the shape.

Agents move a ticket through all eight columns but one. That move is yours and no agent can make it: accepting the work, which moves the ticket out of UAT and into UAT Complete. Until you make it, nothing goes any further.

Eight columns: swipe to see them all

Who may move what

Two columns are the acceptance pair. uat means the work is waiting for you to test it. uat_complete means you have accepted it, and the move between them is the one move on the board that is yours.

The owner shown under each column is whoever makes the move INTO it, which is the same question the table above answers. Agents make every one of those except one: moving a ticket from uat to uat_complete belongs to you. Only QA may move a ticket into UAT, and only with test notes a person can follow. The agent that built the work cannot certify it.

An agent may set prod_deployed only after you have instructed the deployment, and the build reference goes in the note on that move. Where a project has built the visual version, its interface blocks a person from selecting that status and keeps the release reference read-only.

Tickets are created only in Backlog or To Do. That one is a convention rather than a lock, and it stops work appearing part way along the board without passing through the queue.

2 > The Stack

I use this stack for a Project unless there is a stated reason to deviate. It is the stack already proven on the most complete Project run this way, and it gives a reviewer one consistent answer to how access is enforced.

What it costs while a Project sits idle

Every layer has a free tier that covers a validation build, and none charges for idle capacity. That matters because a Project that fails validation should not keep producing a bill simply because it still exists.

Access is enforced in the database, so a permission cannot be bypassed by calling the data API directly. A Project may deviate from the default stack where the stated conditions justify it, and the deviation is recorded with an owner and a review date.

3 > Glossary

The nineteen defined terms used by Startup Studio. Each has its own address, so another page can link straight to the one you need.

The Studio

The one place that owns the team and the shared rules for every Project. The Studio is not a Project and does not build a product. When one Project learns something that would help the others, that change returns to The Studio.

A Project

One product, with its own repository, board and state. A Project uses the team owned by The Studio; it does not own that team. Lessons that apply beyond one Project are returned to The Studio.

Roster

The complete set of agents available to a Project. It contains seventeen Roles, each with a written brief defining what it owns and where its boundaries are. Some briefs also state what the Role is judged badly for. A Roster is generated, never written by hand.

Role

One agent's brief: product manager, tech lead, designer, QA and security reviewer are examples. A Role is a document, not a program. It tells the agent what its job is before work begins.

Load

Whether your coding agent can read a Role and register it as an agent you can call. A Role may be present on disk, current and identical to its source, and still fail to Load. When that happens the agent silently does not exist. Thirteen of the sixteen were in that state for weeks, because each file carried three invisible bytes at the front, while every check at the time reported everything clear. File presence does not prove Load.

Board

The Roadmap Actions Kanban: the record of what a Project is doing, kept as one file per ticket inside that Project’s own repository, so it is versioned and reviewable like the work it tracks. Its rules refuse rather than remind: QA alone moves a ticket to UAT, and only with test notes. A visual version on the web is a decision a founder makes for one Project, never an upgrade.

Compose

Building a Project's Roster by combining each shared Role with that Project's own additions. Nothing is duplicated and then edited by hand: a hand-edited duplicate goes stale the moment the shared version moves, and nothing tells you. The generated version is rebuilt from the current source, so a copy that has fallen behind is named by the health check and one command brings it back into line.

UAT

User acceptance testing. The stage where the person who asked for the work decides whether it is the work they asked for. It is the one point on the board that waits for you. QA alone moves work into the column and an agent moves it out, so what you own is the acceptance itself rather than the column.

Stack Card

One file per Project recording what the Project is built with and how it works. Every Role reads it, so the stack is written once instead of seventeen times. The Stack Card is what all Roles need to know; an Overlay is what one of them needs to know.

Overlay

What one Project adds to one shared Role during Compose. It may hold facts about the Project's stack, extra rules, or a shared rule deliberately waived. A waiver must have an owner, a reason and a review date.

Fragment

A rule shared by more than one Role, written once and pulled into each Role that needs it during Compose. Some Fragments reach all seventeen Roles and some reach a handful. Before Fragments, the most widely shared rule sat in eleven Role files and had to be edited in each one by hand. Eleven copies with ten updated look exactly like eleven copies all updated.

Drift

A Project's generated copy of the team no longer matching the shared source. Drift is silent unless something checks for it. The health check reports it and shows which direction it went, because syncing over a local improvement would destroy that improvement, while promoting a stale copy would revert every Project.

Gate

A review that must pass before work ships, carried out by an agent that did not build the work. Code review, content review, security review and the mobile check are all Gates. A Gate reports what it found and changes nothing, so the builder never signs off its own work.

The Front Door

The assessment an idea passes before anything is built. Six leads assess it from their own disciplines, one paragraph each, and return build, kill or park, with the one Measure it is meant to move and every objection raised, including those that did not prevail. A kill means The Front Door is doing its job. If nothing is ever killed, the assessment is a rubber stamp.

Measure

What a piece of work is expected to improve, agreed before it is built, with the current number where that is known. If no Measure can be named, the idea is usually killed, because there would be no clear way to judge the result later.

Reality Check

A reading of what a Project actually did: revenue, orders, sessions, cost, and where the attention went. Thirty days is the default gap and a Project may set its own. Declining to answer is valid and is recorded. Any Project keeping its own ways of working document is named on every health check until it records a reading, so an unanswered month stays visible. A Project that keeps no such document is skipped and never appears at all, which is worth knowing: the ones furthest outside the process are the ones the check cannot see.

The Ceiling

The most work that can be in flight at once: one large item and three small ones, and while that large is in flight every small starting belongs to it. When The Ceiling is reached the count is stated out loud, and the next item waits somewhere visible.

Warm Start

The file written at the end of each session and loaded automatically at the start of the next. It records the single next action, what is deliberately unbuilt, and the decisions already settled. Work resumes without relying on anyone remembering which file to open.

Proving a Check

Deliberately breaking the condition a check exists to catch, then confirming the check goes red. Until a check has been seen to fail, a passing result does not prove the check works. Several here turned out to be passing for reasons that had nothing to do with what they claimed to test.

4 > Commands

Every switch studio.ps1 accepts, when you would reach for it, and what it writes. You run these in the studio, the one place that owns the shared roles and the skills. They act on your projects, which use those roles to build products of their own. The two exceptions are the hooks, which run on their own and say so in their rows. The recommended order of operations is on the how to run it page, and the switches that modify another command are listed last.

One limitation, stated plainly. The roster is installed into the directories Claude Code reads, and the two hooks are registered the way Claude Code registers hooks. The method itself is not tied to any one coding agent, but this tool is, and support for other agents is not built yet.

A second limitation, about when the Gates above actually run. They run before a release, not on every ticket. A ticket can reach done inside a batch of work that one review covers, and the release is the point where a review is required and refused for its absence. That is a deliberate trade, because a gate on every ticket was ignored in practice and a gate nobody runs is worse than one whose timing is written down. What the release refuses on is narrow and worth knowing: it refuses when no reviewer was started at all in the session shipping the work. It cannot tell whether the reviewer read the change, and it cannot tell whether the reviewer came back clean.

4.1 > Release and Update point in opposite directions

Use -Release when you are shipping a change you made to the studio. Use -Update when you want a newer version of a studio that somebody else publishes. The two sit one letter apart in a shell history and they move work in opposite directions.

studio.ps1 -Release   # your work goes OUT
studio.ps1 -Update    # upstream work comes IN

4.2 > Worked examples

You have improved a role and want every project to receive it. This is the common case, and the reason the studio exists.

# 1. change the shared role
edit base\agents\qa-tester.md

# 2. send it to every project
studio.ps1 -Sync

# 3. confirm nothing drifted
studio.ps1 -Doctor

Every tuned project now carries the new wording. A project with no layer of its own receives it from the machine-wide install instead.

You want one project to behave differently, without changing the base.

# 1. write what is true of this project only
edit my-app\.claude\agent-overlays\qa-tester.md

# 2. rebuild that project's roster
studio.ps1 -Compose -Project "my-app"

Only that project changes. The base roster and every other project are untouched.

You have changed the studio itself and want to publish your own version. A shared role, a skill, the method or the website. This does not deploy a project's product.

# 1. improve the shared role
edit base\agents\qa-tester.md

# 2. write a dated entry saying what changed
edit CHANGELOG.md

# 3. preview it, then ship it
studio.ps1 -Release -WhatIf
studio.ps1 -Release

The command reads that entry, commits and pushes the studio's private repository, publishes the public copy from the same entry, and rebuilds the website. Both repositories carry the same note.

Publishing used to be two separate commands. A change was committed to the private repository and never published to the public one, and nothing compared the two, so the public copy stayed behind for weeks. One dated entry now drives both.

How to run it →