track-management
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.
46
48%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./plugins/conductor/skills/track-management/SKILL.mdQuality
Discovery
75%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
The description has good completeness with an explicit 'Use when' clause and is distinctively scoped to Conductor tracks. However, it could benefit from listing more specific concrete actions and including more natural trigger terms that users might say when they need this skill.
Suggestions
Add specific concrete actions like 'create spec files, generate implementation plans, update track status, close completed tracks' to improve specificity.
Include more natural trigger terms users might say, such as 'start a feature', 'plan a bug fix', 'track progress', or 'work breakdown' to improve discoverability.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain ('Conductor tracks') and mentions some artifacts (spec.md, plan.md, track lifecycle operations), but doesn't list specific concrete actions like 'create spec files', 'update plan status', or 'close tracks'. | 2 / 3 |
Completeness | Explicitly answers both 'what' (creating, managing, working with Conductor tracks including spec.md, plan.md, and lifecycle operations) and 'when' ('Use this skill when creating, managing, or working with Conductor tracks'). The 'Use when' clause is present and clear. | 3 / 3 |
Trigger Term Quality | Includes some relevant terms like 'tracks', 'spec.md', 'plan.md', 'features', 'bugs', 'refactors', but 'Conductor' is a tool-specific term that users may or may not naturally use. Missing common variations like 'task', 'ticket', 'work item', or action-oriented terms like 'start a feature' or 'plan a refactor'. | 2 / 3 |
Distinctiveness Conflict Risk | The description is clearly scoped to 'Conductor tracks' with specific file references (spec.md, plan.md), making it highly distinctive and unlikely to conflict with other skills. The tool-specific terminology creates a clear niche. | 3 / 3 |
Total | 10 / 12 Passed |
Implementation
22%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill is essentially a stub: it names the domain (track management) and lists generic best practices, but provides no actionable content — no templates, no example files, no commands, no workflow steps. The body defers almost entirely to a reference file that isn't provided, leaving the SKILL.md itself insufficient for Claude to act on. The best practices are reasonable but too abstract to guide concrete behavior.
Suggestions
Add a concrete example of a spec.md and plan.md file structure (even abbreviated) so Claude knows the expected format and can produce one immediately.
Define the track lifecycle as a numbered workflow with explicit steps and validation checkpoints (e.g., 'verify spec completeness before creating plan.md').
Show the exact syntax for status markers, task entries, and SHA recording — these are domain-specific conventions Claude cannot infer.
Include a minimal worked example: e.g., 'Given a feature request X, here is the resulting spec.md, plan.md, and tracks.md entry.'
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The 'When to Use This Skill' section is somewhat redundant with the opening description. The best practices list contains generic advice (e.g., 'one track, one concern', 'archive, don't delete') that Claude could infer. However, it's not excessively verbose. | 2 / 3 |
Actionability | There are no concrete commands, code examples, file templates, or executable steps. The content describes what to do abstractly ('create plan.md', 'mark task status') without showing how — no example spec.md structure, no example plan.md, no commands for track creation, no status marker syntax. | 1 / 3 |
Workflow Clarity | The track lifecycle (creation → spec → plan → implementation → completion) is mentioned in the description but never sequenced with clear steps. There are no validation checkpoints, no feedback loops, and the best practices list is unordered advice rather than a workflow. | 1 / 3 |
Progressive Disclosure | There is a reference to 'references/details.md' for detailed patterns, which is good progressive disclosure in principle. However, no bundle files are provided to verify this reference exists, and the SKILL.md itself contains almost no substantive content — it defers too much to the reference file without providing a usable overview. | 2 / 3 |
Total | 6 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 10 / 11 Passed | |
- Repository
- wshobson/agents
- Commit
cf6059d
- Reviewed
Table of Contents
Is this your skill?
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.