track-management

Overview of track-management skill

What track-management does

The track-management skill helps an agent create, update, and reason about Conductor tracks: structured work units for features, bugs, chores, and refactors. A track is more than a task title. It bundles an identifier, a spec.md, a phased plan.md, and lifecycle metadata so work can move from idea to completion with clearer scope and status.

Who should use this skill

This track-management skill is best for teams already using Conductor-style project structure, or anyone adopting a disciplined workflow for scoped engineering work. It is especially useful for:

• PMs and tech leads turning requests into implementable work
• Engineers creating or updating spec.md and plan.md
• Agents that need a consistent unit of work instead of a loose prompt
• Teams that want track-level status, reviewability, and cleaner handoffs

The real job-to-be-done

Most users do not need a generic project management explainer. They need help deciding:

• when to open a new track
• which track type fits the work
• what belongs in spec.md versus plan.md
• how to update lifecycle state without losing context
• how to keep a track narrow enough to execute

That is where track-management for Project Management is most useful: it turns vague requests into structured, track-shaped work.

Why this skill is different from a normal prompt

A normal prompt can ask an agent to “make a plan.” The track-management skill gives the agent a stronger frame:

• work is organized as a track, not an ad hoc checklist
• specification and implementation planning are separated
• lifecycle conventions and status markers matter
• the output is meant to fit a broader Conductor workflow, including tracks.md

If your repository already uses track files, this reduces ambiguity immediately.

Best-fit and misfit cases

Use track-management when the work has enough scope to benefit from a dedicated spec and plan. It is a good fit for new features, defect fixes, refactors, and meaningful maintenance work.

It is a weak fit for:

• one-line edits
• trivial rename-only tasks
• unstructured brainstorming with no execution path
• teams not using Conductor conventions at all

If you do not want track files or track metadata, a plain planning prompt may be simpler.

How to Use track-management skill

Install context for track-management

The repository excerpt does not expose a built-in install command inside SKILL.md, so users typically add the parent skill repository through their skill runner, then invoke track-management by name from that installed source. If your environment uses a command such as:

npx skills add https://github.com/wshobson/agents --skill track-management

verify it against your actual skill loader. The important install decision is not the exact command; it is whether your agent can resolve the skill from plugins/conductor/skills/track-management.

Read this file first

Start with:

• plugins/conductor/skills/track-management/SKILL.md

This skill is self-contained. There are no visible support scripts, rules, or reference files in the skill folder preview, so most of the usable guidance lives in that one file. That is good for quick adoption, but it also means you should read the headings carefully instead of assuming hidden automation exists.

What input the skill needs

For high-quality track-management usage, give the agent enough context to classify and scope the work:

• track type: feature, bug, chore, or refactor
• problem statement or requested outcome
• constraints, non-goals, and deadlines
• affected systems, files, or services
• success criteria
• whether you want a new track, a revised spec, or a revised plan
• current lifecycle state if the track already exists

Without these inputs, the agent can still draft something, but it will often produce generic plans or over-broad specs.

Turn a rough request into a usable prompt

Weak prompt:

Create a track for improving auth.

Better prompt:

Use the track-management skill to create a feature track for improving team SSO onboarding. Write a concise spec.md and phased plan.md. Scope includes first-login account linking, admin error messaging, and audit logging. Do not include SCIM or role sync. Success means new users can complete SSO onboarding without manual DB fixes. Assume the repo already uses tracks.md.

The stronger version improves output because it defines type, boundaries, deliverables, and exclusions.

Ask for the right deliverable

This skill covers several jobs. Be explicit about which one you want:

• create a new track
• review an existing spec.md
• update a plan.md
• interpret track metadata or status markers
• mark a track as completed or ready for the next phase
• reconcile a track with the tracks.md registry

If you ask for “help with a track,” the model may choose the wrong layer.

Suggested workflow in practice

A reliable track-management guide usually looks like this:

1. Classify the work as feature, bug, chore, or refactor.
2. Define the desired outcome and non-goals.
3. Draft or revise spec.md.
4. Break implementation into phases in plan.md.
5. Check that the track is narrow enough to complete.
6. Update lifecycle metadata and registry references.
7. Only then move into implementation with a separate coding skill or prompt.

This matters because many bad plans are really bad specs. Fix scope before decomposing tasks.

How to scope tracks well

The biggest practical quality lever is track size. Good tracks have a clear boundary and an obvious completion condition. Bad tracks blend multiple systems, multiple user journeys, or a migration plus a feature plus cleanup.

If a request contains “also,” “while we’re here,” or “and update all related flows,” split it. The skill is more valuable when each track represents one coherent unit of work.

What to put in spec.md vs plan.md

Use spec.md for:

• the problem
• desired behavior
• constraints
• acceptance criteria
• scope boundaries

Use plan.md for:

• phases
• tasks
• sequencing
• dependencies
• execution notes

A common failure mode is stuffing implementation detail into the spec or writing a plan that never states the expected outcome. Keep the distinction sharp.

Repository conventions to inspect

Because track-management references Conductor concepts like tracks.md, status markers, and metadata, inspect your repository for:

• existing tracks.md
• current track folder naming patterns
• examples of spec.md and plan.md
• status annotations already in use

This skill works best when the agent can imitate an existing house style instead of inventing one.

Practical prompt patterns that work well

Good invocation patterns include:

• “Use track-management to create a new bug track from this incident report.”
• “Use track-management to review this spec.md for scope gaps.”
• “Use track-management to rewrite this plan.md into phased execution tasks.”
• “Use track-management to update track lifecycle state and summarize what is still blocked.”

These are better than generic planning prompts because they tell the agent how to structure the answer.

track-management skill FAQ

Is track-management only for Conductor users?

Mostly, yes. The skill is built around Conductor track concepts, including track types, spec.md, plan.md, lifecycle handling, and tracks.md. You can adapt the ideas elsewhere, but the track-management skill is most valuable when your workflow already resembles that model.

Is track-management good for beginners?

Yes, if beginners already have to work inside an existing track-based process. The structure helps them avoid skipping specification and planning. But it does not replace product judgment. A beginner still needs help defining scope and tradeoffs.

What is the advantage over a standard planning prompt?

The main advantage is consistency. track-management usage pushes the agent toward a stable work unit with type, scope, planning phases, and status conventions. Standard prompts often produce plans that are plausible but not repository-native.

When should I not use track-management?

Do not use track-management for tiny edits, open-ended ideation, or work that will never be represented as a track artifact. In those cases, the structure is overhead rather than leverage.

Can this skill help with existing tracks, not just new ones?

Yes. The source explicitly covers creating, managing, and completing tracks, plus writing or reviewing spec.md, creating or updating plan.md, and interpreting metadata and lifecycle status.

Does track-management generate implementation code?

No. The skill is for work definition and management, not coding itself. It can prepare better execution inputs, but you will usually pair it with a coding or repo-editing workflow after the track is solid.

How to Improve track-management skill

Give the agent boundaries, not just objectives

To improve track-management, provide both what should happen and what should not happen. Exclusions are often more useful than extra ambition. They stop the agent from expanding a track into a roadmap.

Include evidence from the real codebase

The best outputs come from concrete repository context:

• relevant directories
• current architecture notes
• bug reports
• user stories
• existing track examples

If you provide only an abstract goal, the skill will produce a structurally correct track that may still be wrong for your repo.

State the track type early

If you do not specify feature, bug, chore, or refactor, the model may infer the wrong kind of work and shape the spec badly. Type affects scope, risk framing, and task decomposition, so set it up front.

Ask for review before finalization

A strong pattern is two-pass use:

1. “Draft the track.”
2. “Critique the track for overscope, missing acceptance criteria, and phase ambiguity.”

This improves track-management for Project Management because the second pass catches the exact problems that derail execution later.

Watch for these common failure modes

Common weak outputs include:

• tracks that are too broad
• specs without measurable acceptance criteria
• plans that are just unordered task lists
• missing non-goals
• metadata or lifecycle state that does not match reality

If you see one of these, do not just ask for “more detail.” Ask for a narrower revision.

Use stronger revision prompts

Instead of:

Make this better.

Use:

Revise this track with three changes: narrow scope to backend only, add explicit non-goals, and convert the plan into 3 phases with dependencies.

That kind of revision request materially improves output quality because it targets the weak spots.

Calibrate detail to execution stage

Early tracks should emphasize scope clarity and decision points. Later tracks should emphasize sequencing, blockers, and completion criteria. If you ask for maximum detail too early, the plan can become fake precision. Match the level of detail to the track’s maturity.

Build from a good example in your repo

If your repo already has one strong track, pass it in as a style reference. The track-management install decision is easier when you know the skill can mirror your established format rather than invent a new one each time.