Skip to Content
QuickstartAutonomous Implementation

Autonomous Implementation

Use orchestrated parallel execution to implement an entire SpecForge specification autonomously.

This is where SpecForge changes what a single developer can do. Instead of implementing tickets one by one, you tell your coding agent to implement an entire specification. It reads the plan, coordinates parallel workers, and they implement, validate, and report — while you monitor progress from the dashboard.

The result: a specification with 15+ tickets, fully implemented in branches, with linked commits and approved quality gates. In a single work session.

💡 Autonomous implementation assumes your specification is already planned and validated. If you haven’t created and refined your specification yet, start with First Specification.

Prerequisites

Before starting:

  • A coding agent with team/parallel capabilities (e.g., Claude Code with Agent Teams)
  • SpecForge CLI configured in your repository (specforge init completed)
  • A specification with tickets in ready status
  • API key authenticated (specforge login)

Enable Agent Teams (Claude Code)

During specforge init, Agent Teams configuration is generated automatically when Claude Code is detected. Verify in .specforge/config.json:

{ "projectId": "proj_abc123", "specificationId": "spec_xyz789", "agentTeams": { "enabled": true, "strategy": "auto", "maxTicketsPerTeam": 5, "maxParallelEpics": 3, "branchPrefix": "ticket/" } }

Set the environment variable before starting Claude Code:

export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1

ℹ️ Agent Teams is a Claude Code feature (Opus 4.6+, experimental). SpecForge generates the agents, skills, and orchestration configuration so Agent Teams works with your dependency graph out of the box.

The Flow

1. Start Your Coding Agent

Launch Claude Code (or your agent of choice) in your repository.

2. Give the Instruction

Implement the active SpecForge specification

That’s it. One sentence.

3. What Happens Next

The agent reads the SpecForge configuration and executes a structured workflow:

  1. Load specification — Fetches the complete specification, epics, tickets, and dependency graph via MCP
  2. Analyze dependencies — Identifies the critical path and determines which epics can run in parallel
  3. Present implementation plan — Shows what it intends to do, in what order, and asks for confirmation
  4. Create worker teams — One team per epic (or per batch of tickets, depending on strategy)
  5. Workers implement — Each worker picks up tickets, writes code, runs tests, and reports results
  6. Quality gates — A validator checks each implementation against acceptance criteria
  7. Progress reporting — Ticket statuses update in real-time on the SpecForge dashboard

⚠️ Always review the implementation plan before confirming. The orchestrator shows the full scope — number of teams, ticket assignments, branch strategy — before writing any code.

4. Monitor from the Dashboard

While agents work, the SpecForge dashboard updates in real-time:

  • Tickets transition from ready to in_progress to in_review to done
  • Session logs show which agent is working on what
  • The dependency graph highlights completed paths
  • Blocked tickets unblock automatically as dependencies resolve

Configuration Options

strategy

Controls how the orchestrator distributes work:

StrategyBehavior
autoSpecForge chooses based on specification size and dependency structure
singleOne worker handles all tickets sequentially
parallelMultiple workers run simultaneously, one per epic
phasedEpics execute in dependency order, parallelizing within each phase

maxTicketsPerTeam

How many tickets a single worker handles before the orchestrator creates a new team. Range: 1 to 20. Lower values mean more focused workers. Higher values reduce context-switching overhead.

maxParallelEpics

Maximum number of epics running at the same time. Range: 1 to 10. Bounded by your machine’s resources and your agent’s concurrency limits.

branchPrefix

Prefix for git branches created during implementation:

PrefixExample branch name
ticket/ticket/SF-42-implement-user-model
epic/epic/core-authentication
spec/spec/user-auth-system

Token Awareness

Parallel execution consumes significantly more tokens than sequential work. A rough guide:

  • 1 team ≈ 1x baseline token usage
  • 3 parallel teams ≈ 3-4x baseline
  • 5 parallel teams ≈ 5-6x baseline

✅ Start with maxParallelEpics: 1 to understand token consumption for your codebase before scaling up.

Preview Before Committing

Run a dry run to see the execution plan without implementing anything:

specforge plan

This displays: number of epics and tickets to implement, proposed team assignments, execution order based on dependencies, estimated branch names, and any blocked tickets or missing prerequisites.

Review this before running the full implementation.

Putting It All Together

The complete sequence, from zero to autonomous implementation:

# 0. Plan your specification (webapp or via MCP) # Make sure planning review has passed # 1. Set up the project specforge init # 2. Set the environment variable (Claude Code) export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 # 3. Preview the plan specforge plan # 4. Start your coding agent and say: # "Implement the active SpecForge specification" # 5. Review the plan, confirm, and monitor from the dashboard

This is autonomous implementation. One specification, one command, full implementation with dependency-aware orchestration and built-in validation.