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 initcompleted) - 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 specificationThat’s it. One sentence.
3. What Happens Next
The agent reads the SpecForge configuration and executes a structured workflow:
- Load specification — Fetches the complete specification, epics, tickets, and dependency graph via MCP
- Analyze dependencies — Identifies the critical path and determines which epics can run in parallel
- Present implementation plan — Shows what it intends to do, in what order, and asks for confirmation
- Create worker teams — One team per epic (or per batch of tickets, depending on strategy)
- Workers implement — Each worker picks up tickets, writes code, runs tests, and reports results
- Quality gates — A validator checks each implementation against acceptance criteria
- 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:
| Strategy | Behavior |
|---|---|
auto | SpecForge chooses based on specification size and dependency structure |
single | One worker handles all tickets sequentially |
parallel | Multiple workers run simultaneously, one per epic |
phased | Epics 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:
| Prefix | Example 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: 1to 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 planThis 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 dashboardThis is autonomous implementation. One specification, one command, full implementation with dependency-aware orchestration and built-in validation.