PlanWright
How Planwright Works

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.

SEE IT · PROVE IT · EVERY STEP1 · agent + youAskAgent drafts,you approve2 · agentBuildPlans, then buildsto the criteria3 · youCheckAccept, or rejectwith a reason4 · automaticShipReleased on merge,changelog written5 · automaticLearnResults feedthe next brief
People ask and check. Agents build. Shipping and learning happen on their own, and what's learned feeds the next run.

1Ask

An agent drafts, you approve

Your 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 agent

A 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

You

Finished 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

Automatic

When 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

Automatic

Every 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.