Getting Started
Core Concepts
The Planwright hierarchy from top to bottom:
Workspace → Project → Objective → Initiative → Strategic Focus
Workspace
Top levelMaps to a single GitHub organization.
The workspace is the team boundary. It owns the billing relationship, the member list, the audit chain signing key, and all projects inside it. It also publishes a live public changelog of completed objectives — updated automatically as work ships, with no manual maintenance required. One GitHub org = one workspace. Cross-org workspaces are planned for a future release.
See: Release Notes
Project
Under a workspaceThe planning board for a product area or team.
Engineering teams link a GitHub repository for commit tracing and PR association. GTM, product, ops, and compliance teams create projects without a repo — the full objective workflow applies either way. A single repo can serve multiple projects, useful for monorepos where different teams own different services. The project owns the Objective board, the lane configuration, the initiative history, and the context file library — documents agents read before every run.
See: Beyond Engineering
Objective
The atomic unitA clear, agent-executable outcome. The thing agents execute against.
An agent drafts objectives from your intake (a transcript, spec or request), usually with a person steering, and a human approves them. New objectives start in Proposed or Backlog, depending on the workspace's intake setting. Committing an objective to Backlog is the engineering commitment; scheduling it is the delivery commitment. Once scheduled, an agent claims the objective, posts a decomposition plan, makes changes, and requests human review. Objectives never have subtasks, checklists, or breakdowns — that work belongs inside the agent run. An objective moves through lanes: Proposed → Backlog → Scheduled → In Progress → Acceptance → Done → Released.
Initiative
Groups objectivesA named theme and version container that groups related objectives.
Initiatives give the board strategic shape. An initiative might be "Q3 Auth Overhaul" or "Docs Site." Objectives are optional members of an initiative — many useful objectives stand alone. Give an initiative a target date and it appears on the roadmap, where Planwright forecasts when its remaining objectives will land, worked out from this project's real agent and review times. When an initiative is released, Planwright writes a signed release record to the audit chain and generates a release notes artifact from its accepted objectives. Initiatives are optional — you can use Planwright without them for continuous delivery workflows.
Strategic Focus
ClassificationThe four-bucket taxonomy that classifies every objective.
Every objective — including ones proposed by agents — must declare a strategic bucket before it can be claimed. This keeps the portfolio aligned to what the team is actually trying to accomplish.
Engineering and non-engineering projects
A GitHub repo is one way to connect a project — not a requirement. Engineering teams link a repo so Planwright can associate commits and pull requests with objectives. GTM, product, ops, and compliance teams create projects without a repo, and the full objective workflow applies identically: same lifecycle, same agents, same audit chain, same human acceptance gate.
Commit-to-objective tracing and automatic PR linking require a linked repo — those features are not applicable for repo-less projects and don't affect anything else. See Beyond Engineering for use cases, example objectives, and the full capability comparison.
Anatomy of an Objective
Every field on an Objective has a job to do. In an agentic workflow each field is load-bearing — not optional metadata. Here is what each one is and why it matters when a coding agent is the one executing the work.
The agent's primary directive. It should be specific enough that a senior engineer — or a coding agent — could start without asking a clarifying question. Vague titles force agents to make scope assumptions that compound into rejection cycles later.
Agents don't accumulate ambient context the way human teammates do over months of standups and Slack. The description is the complete briefing document. Everything the agent needs to understand scope, motivation, and guardrails must be stated explicitly — it can't ask the PM at standup.
The most critical field for agentic execution. It defines the agent's verifiable target and the human reviewer's checklist at the acceptance gate. Without it, agents guess at completeness and reviewers have no objective basis for rejection. Specific criteria make the acceptance decision binary rather than subjective.
When multiple objectives are scheduled, agents use priority to determine claim order — replacing sprint planning as the scheduling signal. In multi-agent setups, high-priority work is claimed before low-priority work with no human scheduling intervention required.
User-provided or inferred by agent. Required before an objective can be claimed. Forces every piece of work — including agent-proposed objectives — to declare strategic intent before execution begins. Prevents agents from pulling the portfolio toward interesting-but-unstrategic scope. Low confidence scores surface for human review rather than blocking progress.
Agents executing one objective often discover a natural cluster of follow-on work. They can propose a new initiative and attach objectives to it, surfacing emergent scope for the human to evaluate and schedule as a set — rather than as disconnected one-offs.
Business value helps agents calibrate relative importance beyond the priority number. Complexity/risk informs execution approach: a high-risk objective warrants smaller commits, more explicit plan steps, and more verification checkpoints before touching critical paths.
For guidance on writing effective Objectives — including what to put in the Description and Acceptance Criteria — see Best Practices.
Objective lane flow
Only humans make the two commitments: Proposed to Backlog, and Backlog to Scheduled. Agents can move an objective from Scheduled to In Progress (by claiming it) and from In Progress to Acceptance (by requesting review). Only humans can move an objective from Acceptance to Done; a rejected objective goes back to Scheduled. Agents can never self-approve.
Nothing is dragged into Released by hand. An objective gets there when someone releases it from the Done lane or releases its initiative, or automatically when its pull request merges to the project's production branch, if auto-release is turned on. If a release was recorded by mistake, Return to Done corrects the record; it doesn't touch the code, which stays on the production branch until someone reverts it there.
Roadmap and forecast
Initiatives with a target date make up the roadmap. Turn on the forecast and each one gets a projected finish date and its place in the finish order, from a simulation of every remaining objective on the roadmap using this project's real times: how long agents take to pick up and build an objective, and how long reviewers take to sign it off. Dependencies between initiatives are respected.
What if lets you try more or fewer agents or reviewers, or faster reviews, without changing the real plan. Nobody estimates anything: every objective counts as the project's average, which works because objectives are small, single-run outcomes. See Forecast When Initiatives Will Land.