Getting Started
How Planwright works
Every piece of work goes through the same five steps: ask, build, check, ship, learn. Two things run across all of them: you can see where everything stands, and you can prove what happened. Every feature in Planwright belongs to one of these. This page shows which, and where to read more.
1Ask
An agent drafts, you approveYour agent turns what you already have, such as a meeting transcript, a spec, a feature request or a Jira epic, into initiatives and objectives. You steer the conversation and approve the result.
An initiative sets a goal and a target date. Each objective states one outcome, not a task, with acceptance criteria a reviewer can answer yes or no to. Planwright scores every draft's clarity and flags vague ones before anyone claims them. Context files carry the project knowledge every agent should read first.
An initiative's objectives and target date are also what the roadmap and its forecast are drawn from, so approving the plan is what gives you a date.
2Build
The coding agentA coding agent claims a scheduled objective and gets a mission brief: the objective, how often recent work in the same strategic area passed review first time, the most common reasons it was rejected, and whether to work on a branch or directly.
It posts a plan, confirms the plan matches the objective before editing anything, builds and tests against the acceptance criteria, and attaches its diffs and test results. It can't move work on the board itself: it asks, and the server checks every transition.
3Check
YouFinished work waits in the acceptance queue. Each change carries risk signals, such as sensitive paths touched, new dependencies and churn hotspots, so reviewers can triage the queue and look hardest where it matters.
The reviewer judges the work against its acceptance criteria and accepts it, or rejects it with a reason. Agents can never approve their own work.
4Ship
AutomaticWhen an accepted objective's pull request merges to your production branch, Planwright releases it. An initiative counts as shipped once all its objectives have been released. Release notes and the public changelog are written from completed objectives, so nobody writes the weekly summary.
5Learn
AutomaticEvery result feeds back. Rejection reasons are grouped into six categories, and the most common ones for an area go into the next agent's mission brief. Rejection notes become suggested updates to context files. Planwright tracks first-pass acceptance by agent and area, where work waits, and how far delivery drifted from the original intent. Every finished run and review also updates the averages the roadmap forecast uses, so its dates track how the team really works.
Learn feeds the next Ask. Rejected work goes back to Build with its reason attached, and what Planwright learns shapes the next brief and the next draft.
Across every step
See it
Where everything stands, without anyone updating a report.
- The board shows every objective from Proposed to Released, with check-in freshness and an early, on-time or late verdict.
- The roadmap draws each initiative as a timeline bar from its objectives, target date and dependencies.
- The forecast gives each initiative a projected finish date and its place in the finish order, worked out from this project's real agent and review times across everything on the roadmap. What if shows what another agent or reviewer, or faster reviews, would change.
- Strategic focus classifies every objective as BUILD, GROW, TRUST or SCALE, so under-investment shows up.
Prove it
Evidence for people outside the team, with nothing written by hand.
- Every state change is an append-only, hash-chained audit record, signed with the workspace's own key in AWS KMS.
- Commit trailers tie each commit to its objective and agent run.
- A public trust page shows chain integrity and the signing key, and anyone can verify an export with standard tools.
- The public changelog and release notes come from the same records.
The process comes with the tools
Planwright doesn't hope the agent follows a good process. When an agent connects over MCP, the process arrives with the tools, so every run follows the same lifecycle whichever agent or developer is driving.
Session start
The agent binds to the right repository and project before it touches anything, so work never lands on the wrong board.
Alignment gate
Planwright gives the agent a hook for its settings that blocks the first file edit of a session until the agent has checked its planned work against the objective. The agent re-checks when the conversation drifts.
Mission brief at claim
Claiming an objective returns the brief described under Build, so the agent starts with the lessons from earlier work.
Commit convention
Every commit carries trailers naming its objective and agent run.
Evidence before review
The agent records its diff, and which acceptance criteria it verified and how, before it asks for acceptance. Reviewers see the evidence, not just the claim.
Stop instead of guessing
When an objective is unclear, the agent raises a clarity flag and stops, rather than inventing an answer.