CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

to-tickets

Break a plan, spec, or the current conversation into a set of tracer-bullet tickets, each declaring its blocking edges, published to the configured tracker (edges as text in one file per ticket locally, or native blocking links on a real tracker).

Quality

76%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Low

Low-risk findings worth noting

Fix and improve this skill with Tessl

tessl review fix ./.agents/skills/to-tickets/SKILL.md

The canonical home for this skill is to-tickets in mattpocock/skills

SKILL.md
Quality
Evals
Security

Quality

Content

75%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The body is a lean, well-sequenced instruction skill: concrete file patterns, copy-ready templates, an explicit user-approval checkpoint, and checklists. Weaknesses are minor — a missing post-publish verification step and dense inline templates/digressions that could move to reference files.

Suggestions

Add a post-publish verification step (e.g., re-read the created issues/files and confirm numbering, dependency order, and blocking edges are correct) to close the workflow's feedback loop.

Move the local-ticket and issue templates and/or the wide-refactor expand-contract guidance into references/ files, keeping SKILL.md a tighter overview with one-level-deep, clearly signaled links.

Trim the wide-refactor paragraph into tighter bullet rules (expand / migrate in blast-radius-sized batches / contract, with the integration-branch fallback) to cut tokens without losing the decision content.

DimensionReasoningScore

Conciseness

The body is lean and assumes Claude's competence — it never explains what a ticket or tracer bullet is, and every section carries actionable rules. Not 5 because the wide-refactor/expand-contract paragraph runs long as a single dense block and a few phrases ('Quiz the user' preamble, the Kent Beck quote) could be trimmed.

4 / 5

Actionability

Concrete, copy-ready guidance throughout: exact path pattern '.scratch/<feature-slug>/issues/<NN>-<slug>.md', 'numbered from 01 in dependency order', complete local-ticket and issue templates, explicit quiz questions, and the 'ready-for-agent' label. Not 5 because the real-tracker publish path gives no concrete commands or API mechanics — it defers to a setup skill the reader may not have loaded.

4 / 5

Workflow Clarity

Five clearly numbered steps with an explicit validation checkpoint ('Iterate until the user approves the breakdown') and acceptance-criteria checklists in both templates, plus a safety rule ('Do NOT close or modify any parent issue') for the batch publish. Not 5 because there is no post-publish verification step confirming the issues/files landed correctly.

4 / 5

Progressive Disclosure

No bundle files exist (no references/, scripts/, or assets/), and the ~105-line body is well-sectioned with tagged template blocks that are used on every run, so inlining is appropriate. Not 5 because the templates and the long wide-refactor digression are natural candidates for references/ files as the skill grows, keeping SKILL.md a tighter overview.

4 / 5

Total

16

/

20

Passed

Description

66%Weight 40%Scale 1-5

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 states concrete capabilities in third person with natural trigger vocabulary and a distinct niche, but it completely lacks a 'Use when...' trigger clause, which both caps completeness and weakens trigger guidance. Adding an explicit when-to-use sentence with synonyms (issues, tasks, backlog) would lift it to the top band.

Suggestions

Append an explicit trigger clause, e.g. 'Use when the user asks to break down a plan, spec, or the current conversation into tickets, issues, or tasks, or wants a ticket breakdown published to the tracker.'

Add common synonyms users would say — 'issues', 'tasks', 'backlog', and concrete tracker names (GitHub, Linear) — to improve trigger term coverage and distinctiveness.

Briefly mention what each ticket delivers (end-to-end behavior plus acceptance criteria and blocking edges) so the 'what' is comprehensive, not just the decomposition mechanics.

DimensionReasoningScore

Specificity

Names several concrete actions — 'Break a plan, spec, or the current conversation into a set of tracer-bullet tickets, each declaring its blocking edges, published to the configured tracker' — including both output forms ('one file per ticket locally, or native blocking links on a real tracker'). Not 5 because it omits what each ticket contains (e.g., acceptance criteria, ready-for-agent labeling) and the drafting/iteration steps.

4 / 5

Completeness

The 'what' is clear and concrete (decompose into tracer-bullet tickets with blocking edges, publish to the tracker), but there is no 'Use when...' clause or equivalent explicit trigger guidance, which caps completeness at 3 per the judging guidelines. Not 4 because the 'when' is entirely absent rather than merely weakly implied.

3 / 5

Trigger Term Quality

'plan', 'spec', 'tickets', and 'tracker' are terms a user would naturally say when needing this skill. Not 5 because common synonyms and variations ('issues', 'tasks', 'backlog', specific tracker names like GitHub/Linear/Jira) are absent; not 3 because the core vocabulary is natural rather than jargon.

4 / 5

Distinctiveness Conflict Risk

The 'tracer-bullet tickets' + 'blocking edges' + tracker-publishing niche is clearly distinguishable from generic planning or writing skills. Not 5 because 'break a plan into tickets' could plausibly overlap with other planning/decomposition skills when no tracker is configured.

4 / 5

Total

15

/

20

Passed

Validation

100%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository

tonykay/transcriber

Path

.agents/skills/to-tickets/SKILL.md

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.