---
title: Track Management
category: product
entity_type: skill
price: $15
canonical: https://forgehouse.ai/skills/track-management/
lang: en
hreflang_alt: https://forgehouse.ai/tr/skiller/track-management/
last_updated: 2026-06-20
---

# Track Management

> When creating, managing, or working with Conductor tracks: the logical work units for…

A disciplined system for turning features, bugs, and refactors into trackable work units, each with its own spec, phased plan, and metadata. It enforces clear scope boundaries, atomic tasks tied to commit SHAs, and a status-marker convention so you always know exactly what is done, in progress, blocked, or skipped. Work becomes git-aware and revertable at the track, phase, or task level.

## Use cases
- Breaking a feature into spec.md + phased plan.md
- Tracking bug fixes from reproduction test to verification
- Managing a track registry across an active backlog
- Recording commit SHAs for per-task traceability
- Reverting a unit of work cleanly by track or phase
- Right-sizing work to avoid oversized, unmergeable changes

## Benefits
- Every requirement maps to a testable acceptance criterion before code starts
- Scope creep is caught early with explicit in-scope and out-of-scope sections
- Stalled work is visible: blocked tasks carry their reason inline
- Reverting is surgical instead of risky, thanks to SHA-level tracking

## What’s included
- spec.md structure with functional/non-functional requirements and risk table
- Phased plan.md template with verification gates after each phase
- Five status markers: pending, in-progress, complete, skipped, blocked
- tracks.md registry format for active, completed, and archived work
- metadata.json schema covering phases, tasks, checkpoints, and dependencies
- Track sizing guidelines (1-5 days, 2-4 phases, 8-20 tasks)

## Who it’s for
Engineering teams and solo builders who want feature and bug work organized into spec-driven, revertable, traceable units instead of loose commits.

## How it runs
A track that cannot fit in five days is two tracks. Between that sizing rule and the final archive, every Conductor track passes through the same gated lifecycle:
1. Creates the track through interactive Q&A: gathers requirements, acceptance criteria, scope boundaries and dependencies, then generates a structured spec.md (functional and non-functional requirements, explicit in-scope and out-of-scope lists, a risk table and open questions).
2. Generates plan.md as a phased breakdown: tasks grouped into 2-4 phases, each phase ending in verification tasks, with a checkpoint SHA table. Sizing is enforced up front: a track should fit 1-5 days; 5+ phases or 25+ tasks means split into separate tracks.
3. Registers the track in tracks.md with a {shortname}_{YYYYMMDD} ID and writes metadata.json carrying status, phase and task counters.
4. Executes implementation with strict status markers: a task moves from pending to in-progress, gets implemented TDD-first, then is marked complete with its commit SHA recorded inline, so every line of work is traceable to a commit. Blocked tasks carry an explicit reason, skipped tasks an explicit justification.
5. Closes each phase through a gate: all tasks checked, verification tasks done, checkpoint approval received and the checkpoint SHA recorded before the next phase may start. Phase order follows the dependency direction (schema before logic before UI), never reversed.
6. Completes the track only when every acceptance criterion is checked, product and tech-stack docs are synced, tracks.md and metadata.json are updated, and the track is archived rather than deleted so it stays revertible at track, phase or task granularity.

## FAQ
### Is this overkill for a solo developer, or only useful for teams?
The sizing guideline: one to five days, two to four phases, eight to twenty tasks per track, works at solo scale too; the spec and plan files mainly stop you from drifting on your own work. Teams get the extra benefit of the shared tracks.md registry and visible blocked-task reasons.

### What makes reverting 'surgical' instead of just running git revert and hoping?
Every atomic task records its commit SHA in the track metadata, and the plan is split into phases with verification gates between them. So you can revert one task, one phase or the whole track as a known set of commits instead of hunting through the log for what belonged to the feature.

### Does it replace Jira or another project management tool?
No. It is a file-based convention, spec.md, plan.md, tracks.md and metadata.json living in your repo for Conductor tracks: with no boards, notifications or assignee workflows. It organizes the engineering unit of work; team-level project tooling is a different layer.

## Price
$15, one-time, no subscription. VAT included.

Related guide: [AI code review and developer workflow](https://forgehouse.ai/guides/ai-code-review/)