Skip to main content
Daily work follows one principle: advance one independently verifiable feature at a time, and always leave repository state that the next developer or Agent can take over.

​
1. Start the session: read instead of guessing

Options: Read status · Validate the repository Also read AGENTS.md, feature_list.json, the relevant source_refs, and progress.md. Resolve existing validation errors before starting new work. status lists active, ready, and blocked features, approval status, traceability gaps, and recommended next steps. See Status and traceability output for field definitions.

​
2. Plan: create only when needed

Options: Create a milestone · Create a feature When an Agent creates a feature automatically, use a JSON input file inside the repository:
See the --input option → Input cannot inject a claim, workspace, evidence, or completed state. A feature should describe observable behavior, contain at least one verification, and connect to requirements, user stories, acceptance criteria, or ADRs through source_refs. Before planning the next milestone, archive the previous one once every feature in it is passing, so feature_list.json starts the new requirement cycle lean instead of accumulating every milestone the repository has ever had:
See the milestone archive options → Archived features keep satisfying dependencies and traceability coverage for the milestones that follow, so archiving never blocks or invalidates new work — see Archiving milestones.

​
3. Start: select ready work

The unified lifecycle command is recommended:
See the feature start options → Teams can also explicitly claim a specific feature or the highest-priority ready feature:
Options: Claim a specific feature · Select a feature automatically Lower priority values take precedence. Features without a priority follow those with one and retain their list order.

​
4. Isolate: create a workspace when needed

See the workspace create options → This command creates .worktrees/<feature-id> and a feature/<id> branch for a claimed feature. A small solo change may not need one; separate workspaces are recommended for parallel Agents or changes that are likely to conflict.

​
5. Implement: follow the project’s test strategy

Read testStrategy in harness.config.json and docs/workflow/06-agile-tdd.md. During implementation, modify only what the current feature requires. If you discover additional work, create a new feature instead of silently expanding scope. Automated verification:
See the verify options → A manual verification cannot run as a shell command. Record it with:
See the evidence manual options →

​
6. Review: after the latest verification

See the review record options → The reviewer must be independent of the claim owner. After any code change that affects a verification conclusion, run verify and record the review again.

​
7. Complete: let the CLI check the gates atomically

Options: Complete a feature · Validate the repository If completion fails, do not edit the state directly. Follow the error to restore a valid claim, resolve dependency failures, rerun verification for the current commit, or record a later passing review. When an external dependency blocks work:
Options: Block a feature · Reopen a feature block records the reason and releases the claim. reopen clears the blocker and returns the feature to not_started.

​
8. Close the session: leave a state others can take over

See the session close command → It runs validate and the configured environment checks, then summarizes Git state, feature counts, and next steps. Uncommitted changes are reported but do not cause failure by themselves; validation or environment-check failures return a nonzero exit code. Remove the workspace only when you no longer need it:
See the workspace remove options → The tool refuses to remove a workspace that contains uncommitted or unpushed work. Use --force only when you explicitly accept losing that content.