The delivery lifecycle

After preparing the project, each delivery follows three steps: define the outcome, make the changes, and check that it is ready to close.

✦One delivery Define, implement, and complete

The same path repeats for each delivery, from the expected outcome to the final checks.

1. 01 /helmit:spec Define what to deliver Describe the expected outcome, its limits, and how to know it is done.
2. 02 /helmit:implement Make the changes Organize the tasks, implement the changes, and check each result.
3. 03 /helmit:ship Check and complete Confirm what was promised, run final checks, and close the delivery.

Human gate Deterministic proof

What each command does

spec, implement, and ship are the main delivery path. chart and validate are available when you want to inspect the work before moving on.

Command	What it does
spec	Defines the phase outcome, its limits, and how to know it is done.
chart (optional)	Shows or adjusts the plan before building. You can skip this step because implement prepares the plan when needed.
implement	Organizes the tasks, makes the changes, and checks the results.
validate (optional)	Checks whether the phase is ready without closing it. You can skip this step because ship already runs the final checks.
ship	Checks requirements and final results, then records the phase as complete. It never merges.

For preparation, recovery, or autonomy commands, see which command should I use?.

Two levels of specification

The same /helmit:spec appears at two points. It defines the product first, then only the next delivery. HelmIt identifies the level from the project state; you can also explicitly ask to revise either spec.

Where the two specs fit The same command defines the product first, then each delivery.

1 Project preparation At the start

1. /helmit:setup Set up the project
2. /helmit:spec Product spec The project goal, users, main flows, and limits.
3. /helmit:arch · /helmit:env Prepare architecture and environment

↓ The product spec guides every delivery

2 Each delivery cycle Repeats for every phase

1. /helmit:spec Delivery spec The next phase outcome, limits, and acceptance criteria.
2. /helmit:implement Make the changes
3. /helmit:ship Check and complete

↺After ship, the next phase begins with a new delivery spec.

Product spec: appears after /helmit:setup, before architecture and environment preparation. It records who the product is for, its main flows, overall limits, and lasting requirements in .helmit/SPEC.md. It guides the roadmap and later deliveries. It is not rewritten for every phase, but can be revised if the product direction changes.

Delivery spec: appears when a phase is about to start, after project preparation. It records that phase’s outcome, what is out of scope, constraints, requirements, and criteria for checking that it is done. It lives at .helmit/phases/<id>/SPEC.md. Implementation follows this definition; ship checks the result and closes the phase. The next phase gets its own delivery spec.

The agent uses the request and facts already available. It only needs to ask when an undecided choice could change the outcome or acceptance criteria; a clear request can proceed without questions.

Corrections take their own path

A localized correction adjusts something already defined: for example, it restores promised behavior, fixes copy, or changes configuration. It can come from a direct request or from Inbox triage. If the request creates a new capability or changes an important product commitment, it needs a delivery with its own spec and phase.

A localized correction gets a CHG identity, its own record, and focused verification. It does not become a phase task or add a phase to the roadmap. If a delivery is already in progress, HelmIt preserves its position, completes the authorized CHG, then resumes the delivery where it stopped.

Phases, tasks, and corrections Tasks belong to a phase. A CHG has its own record outside it.

Deliveries planned in the roadmap

Phase 1

1. Delivery spec
2. Implementation tasks
3. Ship: phase complete

→

Phase 2

1. Delivery spec
2. Implementation tasks
3. Ship: phase complete

Outside phases: localized correction

Request or Inbox item → CHG: change and focused proof → If a phase was active, resume where it stopped

From specification to tasks

Once the delivery spec defines the outcome, /helmit:implement organizes the work into a plan of verifiable tasks. Each task describes part of the outcome and how to check that it is done. If you want to inspect or adjust the plan before starting, use /helmit:chart; it is optional because implement also prepares the plan when needed.

The agent decides how many tasks are useful and can reorganize them during execution. It only needs to ask you if the plan reveals an undecided product or architecture choice.

From tasks to commits

The agent normally works in the open project. It may divide independent work among agents or use an isolated copy of the repository when that helps it work safely; task count alone requires neither. Your unrelated changes are preserved.

Changes advance through logical commits: coherent sets of changes you can review. One task may need several commits, and a single commit may complete related tasks. Every commit passes quick checks. When an entire task is ready, it also passes the verification defined for that task. An intermediate commit does not mark the task complete.

When to check the whole delivery

During implementation, the complete test, build, and lint suite runs when dependent changes come together or a real risk calls for an integration check. At the end, /helmit:ship checks requirements, accepted outcomes, and complete proof before recording the phase as done. To check readiness without closing the phase, /helmit:validate offers an optional diagnosis. Closing the phase does not merge automatically.

When work needs to wait

The flow only needs to stop when a decision that changes the outcome is missing, required authorization is absent, or verification fails. It may also wait if other work is demonstrably changing the same target and the two cannot be integrated safely. In that case, the agent explains why and preserves the next action; unrelated files or the mere existence of several tasks do not interrupt the delivery.

After an interruption or in a later session, /helmit:next reads the recorded position and shows how to continue.