Trackers pack reference
Every skill in the Trackers pack — what it makes, when to use it, what it needs, its quality bar, and what it hands off to.
For leads and PMs who run work in Jira, Linear or GitHub Projects: load a PRD into the tracker, triage the backlog, write the weekly status report, and check the tracker still matches the doc, all from an export or an MCP tool, with the numbers computed rather than estimated.
| Install | npx skilldrop-cli install --pack trackers |
| Skills | 3 plus 5 from core |
| Loops | none |
| How-to | Use the Trackers pack |
Skills
backlog-triage
Triage a whole backlog export from Jira, Linear or GitHub Projects (CSV, JSON or an MCP tool) — duplicate and near-duplicate pairs with the reason, items missing acceptance criteria or an owner, stale items, oversized items to split, priority conflicts, and a proposed ordering with a reason per item — ending in a change list the user can apply. A stdlib script computes the mechanical checks.
Tier standard · v0.1.3 · SKILL.md · skill page
Use it when the user wants to clean up, groom or refine a backlog, find duplicate tickets, or says "triage our backlog", "what should we pull next?".
Needs: Python 3 for its scripts (standard library only).
A good result:
- Numbers come from the data. Counts, ages and estimates are the script's output or a stated count from the export, never an estimate.
- Every duplicate names the pair and why. Which two keys, what makes them the same work, and which one survives.
- Readiness is explicit. Each item in the ordering says whether it can be pulled today, and if not, what's missing.
- Each position in the ordering has a reason tied to the ordering method, not "feels important".
- Priority changes are proposals, each with the facts behind it, addressed to whoever owns priority.
- The change list can be applied as written: key, change, reason, one row per action.
- Nothing is invented. No owner, date, estimate or customer count that isn't in the export or the user's message.
Hands off to: user-story-splitter when an item is over the size limit or too vague to estimate.
Not for:
- One bug report to turn into a ticket; use
bug-triage - Splitting one epic or large item into stories; use
user-story-splitter(this skill hands oversized items to it) - A weekly status update for stakeholders; use
team-status-report - Creating issues from a PRD, or checking the tracker against the doc; use
tracker-brief-sync
team-status-report
Write a weekly team status report from tracker data (Jira, Linear or GitHub Projects, via CSV, JSON or an MCP tool) — shipped, in progress, blocked with the blocker and owner, slipped against plan, risks and asks — with every number computed from the data by a stdlib script, never estimated, and a RAG status that states the rule that set it.
Tier standard · v0.1.4 · SKILL.md · skill page
Use it when the user wants a weekly status update, sprint report or stakeholder update from the tracker, or says "write this week's status report", "are we on track?".
Needs: Python 3 for its scripts (standard library only).
A good result:
- Every number is computed from the data, by the script or a stated count. No "about", no "roughly half", no velocity the data can't support.
- The RAG names its rule and the number that triggered it. Green with no plan says so.
- Blocked items name the blocker and the owner, or say "not recorded".
- Slipped is measured against a stated plan, and unplanned work is shown separately, not folded into completion.
- Facts from outside the tracker are attributed: "3 Oct (security team, per user)".
- Each ask has a who, a what and a when, and points at the item it unblocks.
- Nothing is invented: no dates, causes, owners or blockers the export and the user didn't give.
Not for:
- Condensing a long document into a one-page summary for executives; use
exec-summary - Cleaning up the backlog itself (duplicates, stale items, ordering); use
backlog-triage - Recording a decision and its rationale; use
decision-log
tracker-brief-sync
Turn a brief or PRD (such as prd-draft output) into tracker-ready epics and issues — title, description, acceptance criteria, labels and a link back to the doc section — as a CSV for Jira, a mapped CSV for other importers, or gh commands for GitHub; and in reverse, report drift between the doc and the tracker (issues with no section, sections with no issue, issues for Won't-have requirements).
Tier standard · v0.1.2 · SKILL.md · skill page
Use it when the user wants to load a PRD into Jira, Linear or GitHub, says "create tickets from this brief", or asks "does the tracker still match the PRD?".
Needs: Python 3 for its scripts (standard library only).
A good result:
- Every issue links back to its doc section with a Source line the drift check can read.
- Every story has acceptance criteria that restate the doc's requirement, testably, without adding behaviour.
- Won't-have requirements and non-goals produce no issues, and are listed as not created.
- The import file passes the spec check before it's handed over, and comes with the import steps for the user's tracker.
- Drift names each item and what happened, from the issue's own text or status, with both ways to resolve it.
- The doc and the tracker are treated as equals. Drift is a disagreement, not proof the tracker is wrong.
- Nothing is invented: no requirements, numbers, owners or reasons that aren't in the doc or the export.
Hands off to: user-story-splitter when a requirement is too large for one story.
Not for:
- Writing the PRD itself; use
prd-draft, then bring its output here - Slicing one epic into stories with a build order; use
user-story-splitter - Cleaning up an existing backlog (duplicates, stale items, ordering); use
backlog-triage
Included from core
Installed with this pack. Details: Core pack reference.
brief-intake: Turn raw mess — a Slack thread, meeting transcript, Jira ticket, half-written Notion page, email chain, or paragraph of free-form context — into a structured brief that the downstream skill (adr-generator, design-doc, runbook-generator, exec-summary, slide-outliner) can consume without further intake.context-graph: Map the decisions behind a codebase from its ADRs, RFCs and design records — each record's status and date, what supersedes or amends what, which records cite which, the files and folders each decision governs, and with git the commits that implemented it and the commits that changed each decision's code since it was made, and who made them — then answer "why is it like this?" from the record and check the record is still true. Finds supersessions only one side records, current decisions pointing at code that is gone, code that has drifted from its decision, two current decisions governing the same path, and references to records that don't exist.council-review: Convene a council of distinct senior-engineer personas (Architect, Security, Operator/SRE, Pragmatist, User-Advocate, plus optional bench seats) to deliberate a decision, design, or code change — each takes an independent stance, the genuine disagreements are surfaced as named cruxes, and a Chair issues a reconciled verdict that records dissents and states what would change the decision. The "Claude Council."doc-critique: Review an existing document — ADR, design doc, runbook, exec summary, tech-comparison matrix, deck outline, decision log — and produce a structured critique against the same quality bars the skilldrop generators enforce. Categorizes findings by severity (blocker / major / minor / nit), points to the exact section/line, and suggests a concrete fix for each.output-hygiene: Review agent-written text before it ships and strip the machine artifacts it carries — invisible Unicode, non-breaking spaces, homoglyphs, harness-added provenance trailers, trailing chat closers — then flag the prose tells a script cannot catch, each quoted with a rewrite.