Improvement requests
A delivered product is never finished. Improvement requests are how shipped products evolve: features, changes, and bug fixes filed as cards on a project's Improve board, each planned, approved, built, QA'd, and merged as a reviewed delta.
Filing an improvement
There are two ways to file one — they end up in the same place:
- On the project's Improve board, create a card directly.
- From New request, choose Feature, Change, or Bug and pick the target project. These three types always route to the project's Improve board rather than starting a new pipeline, because they describe a delta against live code, not a new product.
A card has a kind (feature / change / bug), a title, and a body. As with intake, specificity pays: describe the current behavior, the desired behavior, and how you'd know it's done. You can attach files to a card.
The card lifecycle
Cards move across the Improve board's columns:
| Column | Meaning |
|---|---|
| Submitted | Filed · waiting for triage |
| Triaging | AI sizing up the work |
| Recommended | Plan ready · needs your call |
| Approved | Queued to build |
| Building | Build agent writing code |
| QA | Auditing the change |
| Awaiting merge | Ready to land |
| Merged | Shipped into the product |
A card can also be Rejected at any point before it's merged.
Triage: the AI writes a plan
Submitted cards are picked up by the triage runner, which reads the card against the product's documents and code and writes a triage plan — what it proposes to do, scoped and sequenced. The card then flips to Recommended: plan ready, needs your call.
Your call: approve, edit, or reject
On a recommended card you can:
- Approve — the card moves to Approved and queues for build.
- Edit the plan — replace the proposed plan with your own before approving. This is non-destructive: the first edit stashes the untouched AI proposal, so the original recommendation is always recoverable, and the card records who edited the plan and when. Plan editing is allowed only before a build starts — once building, the plan is what's happening.
- Reject — closes the card. Any non-terminal card can be rejected.
- Delete — remove the card entirely; allowed only while nothing depends on it (submitted, recommended, or rejected cards).
Approvals are validated server-side
Transitions are enforced strictly — only a Recommended card can be approved, and merged or rejected cards can't be reopened by a stale browser tab. What the board shows always reflects the real state.
Build, QA, merge
Approved cards are consumed by the build path: a build run implements the plan as a change against the product's repository. The change then passes through QA ("auditing the change") and lands in Awaiting merge when it's ready. Merging ships it into the product, and the card is done.
Costs are tracked per card just like pipeline requests — you can see what a given improvement cost to triage and build.
Working with the board
- The board live-updates — it refetches continuously, so cards move on their own as triage and builds progress.
- Cards are ordered by column, newest first within a column.
- Improvements can also be listed org-wide, across all your projects, for a portfolio view of in-flight work.
Who can do what
- Any project member can view the board.
- Creating cards, editing plans, approving, and rejecting require editor access or better on the project. See Teams and roles.
Tips for a healthy Improve board
- One card, one outcome. A card titled "various fixes" triages poorly and builds worse. Split it.
- Bugs: include reproduction steps. The triage plan is only as good as the failure description.
- Read the recommended plan before approving. It's cheaper to correct a plan than to reject a build.