agentleFS
ricobergerricoberger/dotfiles/.agents/skills/jira-create-ticket/SKILL.md

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…

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
  1. Very specific:

    Read references/ticket-template.md to load the ticket structure and writing rules.

    line 22
  2. Distinctive:

    What conditions: must be met for the ticket to be closed?

    line 28
  3. Very specific:

    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.

    line 34
  4. Distinctive:

    If the user wants to create the ticket automatically, ask for the ticket type, which can be "Epic", "Story", "Bug", or "Task".

    line 36
  5. Very specific:

    Read references/adf-format.md to load the ADF structure and the --from-json creation strategy.

    line 38
  6. Very specific:

    Write a single work item JSON file (e.g.

    line 40
  7. Very specific:

    Create the ticket using --from-json:

    line 52
  8. Distinctive:

    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.

    line 56

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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

  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 conditions must be met for the ticket to be closed?
  3. 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.
  4. Output the completed ticket as a Markdown code block so the user can copy and paste it directly into Jira.
  5. 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.
    • If the user wants to create the ticket automatically, ask for the ticket type, which can be "Epic", "Story", "Bug", or "Task". Then:
      1. Read references/adf-format.md to load the ADF structure and the --from-json creation strategy.
      2. Write a single work item JSON file (e.g. /tmp/jira-workitem.json) containing projectKey, type, summary, and an ADF description. 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 the summary. Passing the whole work item via a JSON file (instead of inline --summary/--description flags) 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.
      3. Create the ticket using --from-json:
        acli jira workitem create --from-json /tmp/jira-workitem.json
    • 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.

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.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.