Plan and Execute

Use plan mode when the work is bigger than one obvious edit. Anode can inspect, draft a phased plan, name risks, propose checks, and then execute with tracked state.

Plan Mode

Start planning in the TUI with the /plan command. Describe your goal and Anode builds a structured plan artifact.

Command	Description
/plan <goal>	Draft a new plan for a larger change.
/plan revise <instructions>	Revise the active plan with specific instructions. Requires an active plan.
/plan discard	Discard the active plan, execution state, and pending plan decision.

Plan Artifact

Every plan contains:

Field	Type	Description
id	string	Unique plan identifier
version	int	Incremented on each revision
title	string	Human-readable plan name
status	string	Current plan state
phases	array	Ordered list of execution phases
risks	array	Identified risks and mitigations
validation	array	Quality checks to run post-execution
rollback	array	Rollback notes and metadata for undo
confidence	string	Agent confidence label such as low, medium, or high
estimated_scope	string	Size estimate (small, medium, large)

Phases

Each phase is a discrete unit of work:

Field	Type	Description
id	string	Phase identifier
title	string	Phase name
goal	string	What this phase accomplishes
steps	array	Ordered steps within the phase
files	array	Files this phase touches
tools	array	Tools this phase uses
risk	string	Risk level (low, medium, high)
validation	array	Phase-specific validation commands

Quality Checks

Validation commands verify that changes work. Each check has:

Field	Type	Description
name	string	Check name (e.g., “unit tests”)
command	string	Shell command to run
expected	string	What success looks like

Example:

{
  "name": "unit tests",
  "command": "go test ./...",
  "expected": "all tests pass"
}

Decision Options

When the plan has alternatives, Anode presents options:

Field	Type	Description
id	string	Option identifier
label	string	Short option name
description	string	What this option does

You pick one. Anode revises the plan accordingly.

Plan States

Plans move through a strict state machine:

State	Description
idle	No active plan.
collecting_request	User request is being captured and normalized.
inspecting_context	Plan run has started and is reading repository context.
drafting_plan	Initial structured plan is being drafted.
awaiting_clarification	Plan needs more input.
awaiting_plan_decision	Plan is ready for a decision.
approved_full_autonomy	User selected full autonomy.
approved_medium_autonomy	User selected medium autonomy.
chatting_about_plan	User chose to discuss before executing.
revising_plan	Plan is being revised.
discarded	Plan was discarded.
executing	Execution mode is active.
completed, failed, canceled	Terminal states.

The typical flow is inspecting_context -> drafting_plan -> awaiting_plan_decision -> one of the approval/chat/revise/discard states.

Autonomy profiles

Control how much Anode asks before acting:

Option	Internal value	Behavior
Start with full autonomy	full_autonomy	Execute the approved plan with minimal phase interruption while preserving normal tool permission gates.
Start with medium autonomy	medium_autonomy	Pause at the start of each phase. This is the default execution path.
Chat about the plan	chat	Discuss before execution.
Revise the plan	revise	Ask Anode to improve or change the plan before execution.
Discard the plan	discard	Exit plan mode without executing.

Tool permissions still apply during execution. For example, file writes and shell commands can still ask even in full autonomy unless policy or approval mode allows them.

Execution Mode

Execute an approved plan with the /execute command. Variants:

Command	Description
/execute	Start execution with medium autonomy
/execute full	Run all phases with full autonomy
/execute medium	Run with phase-start checkpoints
/execute status	Show current execution progress
/execute validate	Run validation checks without continuing
/execute review	Trigger self-review of changes so far
/execute stop	Stop execution at the next safe point

Execution statuses

Each phase and step tracks its own status:

Status	Description
queued	Waiting to run
running	Currently executing
blocked	Waiting on a dependency or issue
waiting_for_user	Paused at a checkpoint for your input
complete	Finished successfully
failed	Failed with an error
skipped	Skipped by user or policy
canceled	Canceled by user

Checkpoints

Checkpoints pause execution and ask for your decision. They fire at:

Checkpoint	When it fires
phase_start	Before a new phase begins
before_write	Before writing to a file
before_bash	Before running a shell command
before_risky_action	Before a high-risk operation
plan_deviation	When execution diverges from the plan
validation_failure	When a validation check fails
execution_complete	When all phases finish

Which checkpoints fire depends on the autonomy profile. medium_autonomy pauses before each phase; full_autonomy skips phase-start checkpoints but does not bypass normal tool permission prompts.

Checkpoint actions

At each checkpoint, you choose:

Action	Effect
continue	Proceed as planned
modify	Adjust the current step
skip	Skip this step or phase
stop	Stop execution entirely
chat	Open a conversation before deciding
allow	Allow a blocked action
revise_plan	Go back to Plan Mode and revise

Self-review

After validation, Anode builds a self-review summary from changed files, validation results, warnings, and remaining work. It does not replace anode review; use the review command for an independent read-only model pass.

Rollback metadata

Anode tracks what it can undo. Every file modification records the before-state. If execution fails or you stop midway, the rollback metadata shows which changes are reversible.

Validation

Validation commands run through the configured plan validation list when present. If no plan validation commands are available, Anode derives defaults from the changed files: gofmt -w for changed Go files, then go test ./..., go vet ./..., and go run ./cmd/anode --help.

# Example: validation runs go tests after a refactoring phase
go test ./internal/...

Change Tracking

Every file modification Anode makes is recorded in the change ledger. Use /changes to view them.

Change entry fields

Field	Type	Description
kind	string	Operation type (create_file, edit_file, etc.)
path	string	File path relative to workspace
status	string	applied, reverted, or committed
ownership	string	Who made the change (anode, user, pre_existing)
risk	string	Risk classification
diff	string	Unified diff of the change

Risk Classification

Files are classified by risk:

Risk	File patterns
High	.sh, .bash, .env, .pem, .key, Dockerfiles, CI configs, lockfiles, migrations, auth files, deletions
Medium	All other files (default)
Low	.md, .txt, .rst, test files, README, CHANGELOG

Commit Changes

Use /commit to prepare a git commit from tracked changes. Anode:

1. Validates tracked files against the workspace.
2. Generates a commit message from the change entries.
3. Runs git add for each changed file.
4. Runs git commit with the generated message.

A commit is ready when Anode-owned changes exist, no validation failures remain, and no high-risk changes are unreviewed.

Keep Going

• Code Review — review diffs without modifying code
• Profiles — customize the agent profile for plan and execute modes
• Interactive Mode — all TUI slash commands and shortcuts
• Permissions — control which tools require confirmation