Tack
Concepts

Objectives & Planning

How Tack decomposes objectives into parallel work streams.

Objectives

An objective is the top-level unit of work in Tack. You describe what you want built, optionally choose a blueprint, and Tack starts the workflow for the current project.

tack plan "Add pagination to all list endpoints"
tack plan "Add pagination to all list endpoints" --blueprint standard

The default workflow:

objective created → discovery runs → dossier produced → planner runs → plan ready → human approval → execution → merge → PR

Before planning, Tack runs a discovery step that explores the codebase and produces a context dossier with cited references and suggested seams. The planner consumes this dossier to produce better decompositions.

See Writing Good Objectives for patterns and examples that produce better plans.

The Planner

When you submit an objective, Tack first runs discovery to produce a context dossier, then spawns a planner agent. The planner:

  1. Consumes the dossier — cited repo context and suggested seams from discovery
  2. Uses the dossier as its source of truth and requests dossier expansion when the current context is insufficient
  3. Identifies what needs to change to fulfill the objective
  4. Decomposes the objective into independent streams that can run in parallel
  5. Assigns file scopes — glob patterns defining which files each stream can modify
  6. Sets dependencies — ordering constraints between streams when changes must happen sequentially

The planner outputs a structured plan that Tack validates and presents for your review.

Planning Modes

The planning.default_mode config controls how planning works:

planning:
  default_mode: collaborative

Currently, collaborative is the default mode. The planner produces a plan and waits for your approval before any execution begins.

Plan Approval

Plans require human approval before execution begins. This is your checkpoint to verify the decomposition makes sense.

tack show <plan-id>    # Review streams, file scopes, dependencies
tack approve <plan-id> # Start execution
tack reject <plan-id>  # Discard the plan

What to Look For

When reviewing a plan, check:

  • Stream count — is the decomposition reasonable? Too many streams for a simple task means the planner over-decomposed. Too few for a complex task means work items may be too broad.
  • File scopes — do the glob patterns cover the right files? Are they too broad (agent may modify unrelated files) or too narrow (agent may be blocked from files it needs)?
  • Dependencies — are the ordering constraints correct? Unnecessary dependencies reduce parallelism. Missing dependencies cause build failures.

When the Plan Is Wrong

If the plan does not match your intent:

tack reject <plan-id>

Then resubmit with a clearer objective. Common reasons plans go wrong:

  • The objective was too vague for the planner to find the right scope
  • The objective mixed unrelated concerns that should be separate objectives
  • The objective referenced files or modules the planner did not discover

Providing more specific file paths, module names, and acceptance criteria in the objective helps the planner produce better decompositions.

Work Items and Streams

Plans are made of streams: parallel work items with file scopes, dependency ordering, and isolated execution.

Each stream has:

  • Title — a short description of what the stream does
  • Description — detailed task specification for the builder agent
  • File scope — glob patterns defining which files the stream can modify
  • Dependencies — other streams that must complete before this one starts

Streams are the execution unit you see in plans, tack watch output, and merge state. See Streams for the full lifecycle.

Blueprint Selection

Every objective runs against a blueprint that defines the workflow steps:

tack plan "Fix the typo in README.md" --blueprint standard

If you omit --blueprint, Tack resolves the default blueprint from the loaded blueprints for the current project. See Blueprints for how defaults work.

Objective Lifecycle

planning → approved → executing → completed
                               ↘ partial
                               ↘ failed
                               ↘ blocked
StateMeaning
planningPlanner is working on decomposition
approvedPlan approved, waiting to execute
executingAgents are working on streams
completedAll streams merged, PR created
partialSome streams merged, some failed
failedAll streams failed or the run could not proceed
blockedOne or more streams waiting for human guidance

On this page