jira-create-ticket
Skill19 starsChanged 36 days agoMITView on GitHub
To generate a Jira ticket, take the information provided by the user and produce a complete, paste-ready Markdown ticket following the standard format: a user story opening line, a background paragraph, and a checklist of acceptance criteria. 1. Read references/ticket-template.md to load the ticket structure and writing rules. 2. Gather the required information from the user's input: - Who is the persona (user role)? - What is the goal or feature? - Why does it matter (business/user value)? - What…
In this repository12 other files it gives its agents.
- ai-teamSkill
- architecture-decision-recordsSkill
- git-commitSkill
- github-pr-createSkill
- github-pr-review-reviewsSkill
- github-pr-reviewSkill
- grill-meSkill
- sre-analyze-alertSkill
- sre-grafana-dashboardSkill
- sre-grafanaSkill
- sre-kubernetes-rightsizingSkill
- sre-kubernetesSkill
The file
We split this skill into the rules it gives an agent
8 rules. About 0 are common, 3 are distinctive, and 5 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
5
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 22
Read references/ticket-template.md to load the ticket structure and writing rules.
- Distinctive: line 28
What conditions: must be met for the ticket to be closed?
- Very specific: line 34
Ask the user if the ticket should be automatically created in Jira using the acli in the CORE project or if the ticket should be adjusted.
- Distinctive: line 36
If the user wants to create the ticket automatically, ask for the ticket type, which can be "Epic", "Story", "Bug", or "Task".
- Very specific: line 38
Read references/adf-format.md to load the ADF structure and the --from-json creation strategy.
- Very specific: line 40
Write a single work item JSON file (e.g.
- Very specific: line 52
Create the ticket using --from-json:
- Distinctive: line 56
If the user wants to adjust the ticket, always output the full updated ticket in Markdown again and ask if they want to create it in Jira.
≈ “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
Jira Create Ticket
Overview
To generate a Jira ticket, take the information provided by the user and produce a complete, paste-ready Markdown ticket following the standard format: a user story opening line, a background paragraph, and a checklist of acceptance criteria.
Workflow
- Read
references/ticket-template.mdto load the ticket structure and writing rules. - Gather the required information from the user's input:
- Who is the persona (user role)?
- What is the goal or feature?
- Why does it matter (business/user value)?
- What conditions must be met for the ticket to be closed?
- Fill in the template. If any of the above is missing or ambiguous, infer reasonable defaults from context — do not ask clarifying questions unless the request is too vague to produce a useful ticket.
- Output the completed ticket as a Markdown code block so the user can copy and paste it directly into Jira.
- Ask the user if the ticket should be automatically created in Jira using the
acliin theCOREproject or if the ticket should be adjusted.- If the user wants to create the ticket automatically, ask for the ticket
type, which can be "Epic", "Story", "Bug", or "Task". Then:
- Read
references/adf-format.mdto load the ADF structure and the--from-jsoncreation strategy. - Write a single work item JSON file (e.g.
/tmp/jira-workitem.json) containingprojectKey,type,summary, and an ADFdescription. This file might already exist from a previous session, so remove it first (e.g.rm -f /tmp/jira-workitem.json) before writing it. Convert the User Story, Background, and Acceptance Criteria sections into ADF nodes (headings, paragraphs, and a bullet list) — never include the title in the description, since it is thesummary. Passing the whole work item via a JSON file (instead of inline--summary/--descriptionflags) avoids broken commands when the title or description contains double quotes, apostrophes, backticks, or other shell-special characters, and ADF ensures the ticket renders cleanly in the Jira web UI. - Create the ticket using
--from-json:acli jira workitem create --from-json /tmp/jira-workitem.json
- Read
- If the user wants to adjust the ticket, always output the full updated ticket in Markdown again and ask if they want to create it in Jira.
- If the user wants to create the ticket automatically, ask for the ticket
type, which can be "Epic", "Story", "Bug", or "Task". Then:
Writing Principles
- Short and precise — no filler, no padding.
- User story: one tight line.
As a <persona>, I want to <goal>, so that <benefit>. - Background: 1–2 sentences max. Explain why, not what. Do not restate the user story.
- Acceptance criteria: short, precise action items. Present tense. No vague
terms. No numbered/counted items (e.g. avoid "at least 3", "2 retries"). No
[]checkboxes. - A ticket title is always suggested as the first line of the ticket
(
**Title:** ...). It becomes the Jira summary and is not duplicated in the description. - The ticket shown to the user is Markdown only — no explanations or commentary
around it unless the user asks. When creating the ticket in Jira, the same
content is encoded as ADF (see
references/adf-format.md); the wording stays identical, only the format changes.
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.

