How do I install the Jira Ticket Git skill?

Run npx skillmds@latest add foreveraprogrammer/jira-ticket-git in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Jira Ticket Git safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Jira Ticket Git?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Jira Ticket Git free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Jira Ticket Git?

ForeverAProgrammer (@foreveraprogrammer) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Jira Ticket Git by foreveraprogrammer

Name: Jira Ticket Git
Author: ForeverAProgrammer

File contents

Turn the current git changes into a well-formed Jira/Linear-style ticket with acceptance criteria.

Determine the base branch using the first method that succeeds:

Run gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name' 2>/dev/null to get the default branch.
Run git remote show origin 2>/dev/null | grep 'HEAD branch' to detect it from the remote config.
Check which of main, master, or develop exist on the remote with git branch -r.
If none work, ask the user to specify the base branch and stop until they do.

Run git log --oneline <base>..HEAD to list commits on this branch. Run git diff <base>...HEAD to see all changes introduced by the branch. If there are no commits ahead of the base branch, tell the user there is nothing to generate a ticket from and stop.

Using the diff and commit context, output the ticket in this format:

Title A short, imperative-tense summary of what the change does (under 72 characters). Suitable for a ticket title or story card.

Type Infer one of: Story, Bug, Task, Spike. Use Story for user-facing features, Bug for defects, Task for internal/non-feature work, Spike for research or investigation.

Description 2-4 sentences explaining what needs to be done and why, written as if the work has not yet been done. Describe the intent and value, not the implementation. If the diff reveals implementation details, use them only to infer the purpose.

Acceptance Criteria A checklist of specific, testable conditions that must be true for the ticket to be considered done. Derive these from what the diff actually changes — each criterion should correspond to observable behaviour.

Out of Scope (optional) List anything that might seem related but is explicitly not included. Omit this section if nothing needs clarifying.

Rules:

Be specific — vague criteria like "it works correctly" are not acceptable
Do not pad with obvious criteria like "code is reviewed" or "tests pass" unless testing behaviour is genuinely part of the scope
If the diff is ambiguous about intent, make a reasonable assumption and note it in the Description
Keep the total output focused and scannable — this is a ticket, not a design doc

$ARGUMENTS

---name: jira-ticket-gitdescription: Turn the current git changes into a well-formed Jira/Linear-style ticket with acceptance criteria.---Turn the current git changes into a well-formed Jira/Linear-style ticket with acceptance criteria.Determine the base branch using the first method that succeeds:- Run `gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name' 2>/dev/null` to get the default branch.- Run `git remote show origin 2>/dev/null | grep 'HEAD branch'` to detect it from the remote config.- Check which of `main`, `master`, or `develop` exist on the remote with `git branch -r`.- If none work, ask the user to specify the base branch and stop until they do.Run `git log --oneline <base>..HEAD` to list commits on this branch. Run `git diff <base>...HEAD` to see all changes introduced by the branch. If there are no commits ahead of the base branch, tell the user there is nothing to generate a ticket from and stop.Using the diff and commit context, output the ticket in this format:**Title**A short, imperative-tense summary of what the change does (under 72 characters). Suitable for a ticket title or story card.**Type**Infer one of: Story, Bug, Task, Spike. Use Story for user-facing features, Bug for defects, Task for internal/non-feature work, Spike for research or investigation.**Description**2-4 sentences explaining what needs to be done and why, written as if the work has not yet been done. Describe the intent and value, not the implementation. If the diff reveals implementation details, use them only to infer the purpose.**Acceptance Criteria**A checklist of specific, testable conditions that must be true for the ticket to be considered done. Derive these from what the diff actually changes — each criterion should correspond to observable behaviour.- [ ] ...- [ ] ...**Out of Scope** (optional)List anything that might seem related but is explicitly not included. Omit this section if nothing needs clarifying.Rules:- Be specific — vague criteria like "it works correctly" are not acceptable- Do not pad with obvious criteria like "code is reviewed" or "tests pass" unless testing behaviour is genuinely part of the scope- If the diff is ambiguous about intent, make a reasonable assumption and note it in the Description- Keep the total output focused and scannable — this is a ticket, not a design doc$ARGUMENTS

Frequently asked questions

Jira Ticket Git