Jira ticket git
Skill ForeverAProgrammer/claude-devflow/skills/jira-ticket-git
Claude Code plugin with skills for daily dev workflows — commits, standups, PRs, design docs, and GitHub automation.
npx -y skills add ForeverAProgrammer/claude-devflow --skill jira-ticket-gitAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Turn the current git changes into a well-formed Jira/Linear-style ticket with acceptance criteria.
SKILL.md
2.3 KB, 507 tokens by cl100k_base, as published. Nobody here has run it
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/nullto 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, ordevelopexist on the remote withgit 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
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.
Gives 0 of the 12 instructions most pr commit review skills give in 507 tokens
Counted across 888 of the 1,342 authors here whose files we hold, read 2026-08-07
- Use conventional commits formatin 127 of 888, across 115 files
- Keep subject line under 72 charactersin 62 of 888, across 48 files
- Delete branches after mergein 51 of 888, across 38 files
- Use imperative mood in subject linein 51 of 888, across 42 files
- Use imperative mood in commit messagesin 44 of 888
- Verify directory is ignored before creating worktreein 43 of 888, across 12 files
- Generate a conventional commit messagein 43 of 888
- Add unignored worktree directories to gitignorein 42 of 888, across 10 files
- Make atomic commitsin 39 of 888, across 27 files
- Run tests before committingin 36 of 888, across 25 files
- Verify clean test baselinein 35 of 888, across 9 files
- Split unrelated changes into separate commitsin 35 of 888, across 30 files
Said here and by no other author read
- infer the ticket type from the changes
- describe the intent and value of the work
- omit obvious criteria unless explicitly scoped
- note any assumptions made about ambiguous intent
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.