ticket-trim
Skill3 starsChanged 30 days agoMITView on GitHub
Shorten an existing ticket that is too long or too technical, moving the engineering detail into a Technical notes comment so nothing is lost. Use when the user gives a ticket key or link and asks to trim, condense, simplify or clean it up, or says a product owner or analyst found it hard to read.
In this repository22 other files it gives its agents.
- confluence-jira-linksSkill
- diagnosing-bugsSkill
- epic-reviewSkill
- explain-the-numberSkill
- grillingSkill
- handoffSkill
- leader-1-1-prepSkill
- llm-integrationSkill
- no-ai-attributionSkill
- open-in-my-browserSkill
- pick-upSkill
- plain-writingSkill
- regression-proofSkill
- researchSkill
- retroSkill
- security-audit-runnerSkill
- skill-collision-auditSkill
- supervisorSkill
- tddSkill
- ticket-digestSkill
- ticket-writeSkill
- writing-for-agentsSkill
The file
We split this skill into the rules it gives an agent
1 rule. About 0 are common, 1 is distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 27
Leave tickets that are already done or closed alone.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Ticket trim
Reshape one existing ticket to the ticket-write shape: a short plain-language description, the detail in a Technical notes comment. The budgets, the templates and the lint script are in the ticket-write skill's folder.
Steps
- Read the ticket in full, with its comments and any acceptance-criteria field. Note its type, its reporter, and whether it has images, mentions or checklists, which must survive the rewrite. If someone else reported it, say so before changing anything.
Sort every sentence.
- Keep: the effect, why it matters, outcomes someone can check, scope, links. These become the new description.
- Move: root causes, file paths, function names, config keys, phased plans, verification steps. These become the technical notes.
- Link out: anything that is really a document, such as a multi-phase plan with a decision log. Do this only with the user's agreement, since it creates a page.
Rewrite acceptance criteria that name an implementation ("retry with backoff") as the outcome ("a short outage shows no error to visitors"). Keep a long criterion when it is long because it is precise.
- Lint the new description with
../ticket-write/scripts/ticket_lint.py. - Show before and after: the numbers on one line ("612 → 131 words, identifiers 40 → 1, criteria 9 → 4"), the new description, and the technical notes. Editing notifies watchers, so wait for a go-ahead.
- Apply, in this order:
- Post a comment titled
Original text (before trim)containing the old description and any rich-text field you will change, word for word. Some trackers keep no history for custom fields, which would make this comment the only copy. If such a comment already exists from an earlier trim, leave it. - Post or update the
Technical notescomment. - Replace the description, and the title if it was over 80 characters.
- Report the key and the numbers, and point to the original-text comment as the way back.
- Post a comment titled
Leave tickets that are already done or closed alone; nobody is left to read them.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.