Skip to content
OpenPlanr Docs
GitHub (opens in a new tab)

Build one task at a time

Ship one planned task per change, verified and small enough to review as one pull request, or hand a task to another coding agent.

Build one task at a time. Each change stays small enough to review as one pull request, and it is checked against the plan it came from.

Ship a task

Invoke /ship with a task ID. Before it changes code, Ship reads the task completely, then follows it to the parent story, the acceptance criteria, the Gherkin file when there is one, and the spec. It also reads the repository instructions, the relevant code and tests, and the interfaces that the task's dependencies produced.

The task's Create and Modify lists describe where the change should land. Ship adds companion files when correctness needs them, leaves the Preserve list unchanged, and keeps unrelated changes in your working tree.

When your agent supports sub-agents, Ship can hand frontend, backend, database, QA, DevOps, and documentation work to role agents inside the same session. Otherwise it works through those roles itself.

How Ship checks its work

Ship looks for checks in this order: the task's test requirements, the repository instructions, the package scripts, then CI and pre-commit configuration. It runs focused checks while it works and regression checks at the end, and it fixes failures its own change caused.

It reports 5 things: the outcome (completed, partial, or blocked), the task, the files it changed, each check with passed, failed, or not run, and any open issue. Work it could not verify is labeled unverified.

Ship keeps the work local and does not publish or deploy it. Getting the change ready to merge belongs to /land.

Ship a direct request

For a small, clear change, you can skip the plan and give Ship the request itself. The request and the repository are enough context, and missing planning files do not block it.

Hand a task to another agent

When you explicitly want another coding agent to build a task, invoke /delegate. The other agent's CLI investigates, implements, and tests in its own worktree. Your current agent keeps the scope, reviews the observed changes, runs its own checks, and applies accepted changes as an uncommitted diff in your checkout. Committing, merging, and deploying stay separate decisions.

The full workflow is in Delegate implementation through a native coding CLI.

When something breaks

For a bug, start with /investigate instead of Ship. It reproduces the failure, tests competing causes, and changes code only when you ask for a fix.

Prompts for this stage

Next: Review before it lands.