Skills wshobson agents Conductor
track-management
- Use it when:
- You're starting a feature, bug fix, chore or refactor in a project run with Conductor, or writing or updating its spec.md and plan.md.
- It does:
- Defines a track, one unit of work with its own folder, an ID such as user-auth_20250115, a spec, a phased plan and metadata, and its lifecycle from creation to archive.
- You get:
- Templates for spec.md, plan.md, metadata.json and the tracks.md registry, plus quality checklists for specs and plans.
- Markers:
- [ ] pending, [~] in progress, [x] done with its commit SHA, [-] skipped, [!] blocked.
- Commands:
- Creating and reverting a track run /conductor:new-track and /conductor:revert, which come with the Conductor plugin, not with this skill.
Skill 2 of 3 in the Conductor bundle, after context-driven-development and before workflow-patterns.
Written for wshobson's Conductor plugin: creating and reverting a track go through its /conductor:new-track and /conductor:revert commands, which installing the skill alone doesn't add.
TL;DR
Conductor, a plugin in the same repo, keeps a project's context in a conductor/ folder and splits work into tracks; this skill is its guide to tracks. Creating one means gathering requirements by Q&A, writing spec.md (functional and non-functional requirements, testable acceptance criteria, what's in and out of scope, dependencies, risks and open questions) and plan.md (phases of tasks, each ending in verification tasks, with a checkpoint table), then registering it in tracks.md with a metadata.json and an index. During implementation, tasks are marked as they go and completed ones record their commit SHA; each phase needs its verification and an approved checkpoint before the next. On completion, the track is marked done, product.md and tech-stack.md are updated if features or dependencies changed, and the track is archived rather than deleted. Tracks should take one to five days, with two to four phases and 8–20 tasks; it lists signs of tracks too large or too small, how to record hard, soft and external dependencies, and phase patterns for features, bug fixes (start with a failing test) and refactors (start with characterization tests). The SKILL.md holds only ten best practices; the rest is in a reference file.
Summarizes the skill at 4bde316.
npx skills add https://github.com/wshobson/agents --skill track-management skills.sh pageSource on GitHubAll skills from wshobson/agents
- Total Downloads
- 10,600 on skills.sh, Nov 9, 2026
- Repo stars
- 42,334 wshobson/agents
- First seen
- Jan 20, 2026 on skills.sh
Weekly values
| Week to | Installs |
|---|---|
| Sep 21 | 178 |
| Sep 28 | 207 |
| Oct 5 | 260 |
| Oct 12 | 204 |
| Oct 19 | 174 |
| Oct 26 | 173 |
| Nov 2 | 164 |
| Nov 9 | 147 |
| Category |
Make the agent question you and write the plan down before it writes code. Everything for building software: planning, coding, debugging, design, frameworks, cloud, agents and skills. |
|---|---|
| Type |
A multi-step process the agent follows: interview, debug, run a TDD loop, review. |
| Effect |
Its own steps create or change files, git state or local tools. |
| Needs |
Instructions only. Works in any agent that supports skills. |
| Publisher |
Everyone else. Unverified vendor claims default to community. |
| Topics |
SKILL.md
From wshobson/agents at 4bde316. Checked daily, last changed Nov 6, 2026.
Frontmatter
name: track-management
description: Use this skill when creating, managing, or working with Conductor tracks - the logical work units for features, bugs, and refactors. Applies to spec.md, plan.md, and track lifecycle operations.
version: 1.0.0Track Management
Guide for creating, managing, and completing Conductor tracks - the logical work units that organize features, bugs, and refactors through specification, planning, and implementation phases.
When to Use This Skill
- Creating new feature, bug, or refactor tracks
- Writing or reviewing spec.md files
- Creating or updating plan.md files
- Managing track lifecycle from creation to completion
- Understanding track status markers and conventions
- Working with the tracks.md registry
- Interpreting or updating track metadata
Detailed patterns and worked examples
Detailed pattern documentation lives in references/details.md. Read that file when the navigation tier above is insufficient.
Best Practices
- One track, one concern: Keep tracks focused on a single logical change
- Small phases: Break work into phases of 3-5 tasks maximum
- Verification after phases: Always include verification tasks
- Update markers immediately: Mark task status as you work
- Record SHAs: Always note commit SHAs for completed tasks
- Review specs before planning: Ensure spec is complete before creating plan
- Link dependencies: Explicitly note track dependencies
- Archive, don't delete: Preserve completed tracks for reference
- Size appropriately: Keep tracks between 1-5 days of work
- Clear acceptance criteria: Every requirement must be testable