Claude Skills for Jira: Ticket and Review Templates

Claude skills for Jira are saved prompt instructions that produce well-formed tickets and review checklists without you writing the same formatting rules in every new conversation. You define what a good ticket looks like once, save it as a named skill, and call it each time.

Tools like fenbs store the shared requirements, team decisions, and project conventions alongside the skills. When Claude reads that context at the start of a session, the output reflects your actual standards rather than generic best practices.

What makes a good Jira skill

A good Jira skill gives Claude a fixed output structure and forces it to surface missing information rather than invent it. The worst tickets are ones that look complete but hide gaps: vague acceptance criteria, no definition of done, or a description that skips the business reason.

The skill should reflect your team's actual conventions, not a generic template. If your team always attaches a test environment note, put that in the skill. If your project uses story points, include a sizing prompt. A skill that matches your real process gets used; one that fights it gets abandoned.

Start with three skills: one for drafting a user story, one for writing acceptance criteria, and one for reviewing a ticket before it goes to the backlog. You can link all three in how to create a Claude skill and combine them into a short workflow.

A skill for drafting a user story ticket

This skill takes a request and produces a structured ticket. The output format matches what Jira expects, and the skill flags gaps rather than filling them in.

Draft a Jira user story ticket for the following request.

Request: {{request}}

Output exactly this structure:

Title: one line, starts with a verb, describes the user value
Type: Story
Description:
  As a [user type], I want to [action] so that [benefit].
  [Two to three sentences of context and business reason.]
Acceptance criteria:
  - [ ] First measurable criterion
  - [ ] Second measurable criterion
  - [ ] Third measurable criterion
Out of scope: [list what this ticket does not cover]
Open questions: [list anything missing that needs to be answered before work starts]
Suggested priority: Low | Medium | High | Critical with one-sentence reason

If information is missing to write any field, write "NEEDS INPUT:" followed by the question.

The "NEEDS INPUT" convention is important. It stops Claude from inventing plausible-sounding acceptance criteria when it does not have enough context. A ticket with an honest gap is easier to fix than one that looks complete.

A skill for writing acceptance criteria

When you already have a ticket title and description but need to sharpen the acceptance criteria, this skill focuses only on that part. It checks each criterion for testability.

Write acceptance criteria for the following user story.

Title: {{title}}
Description: {{description}}

Rules for each criterion:
- Starts with a verb in present tense ("User can...", "System returns...", "Error message shows...")
- Has a pass condition a tester can verify without asking the author
- Covers one thing only

Write four to six criteria as a checklist. After the list, note any edge cases the story description implies but does not address.

Run this skill after the user story skill if the initial criteria are vague. The two skills together cover the most common ticket quality problem: stories that describe intent but not testable outcomes.

A skill for reviewing a ticket before filing

This skill reads a draft ticket and checks it against a quality checklist before it goes to the backlog. It is faster than a manual review and catches the same issues every time.

Review this Jira ticket draft for completeness and clarity.

Ticket: {{paste the full ticket text}}

Check each item and mark Pass, Fail, or Not applicable:
- [ ] Title starts with a verb and describes user value, not implementation
- [ ] Description explains the business reason, not just what to build
- [ ] Acceptance criteria are testable and measurable
- [ ] Out-of-scope section is present
- [ ] No undefined terms or abbreviations
- [ ] No missing required fields

For each Fail, write one sentence explaining the problem and one sentence on how to fix it.
End with: Ready to file: Yes / No with one-line reason.

How to combine the skills in one session

A typical ticket workflow runs in three calls: draft the user story, sharpen the acceptance criteria, then run the review check. Each skill produces the input for the next. You review the output between each step, not just at the end.

For recurring ticket types (bugs, API changes, data migrations), save a version of the user story skill with the relevant defaults pre-filled. A bug skill might already include fields for reproduction steps and environment. A migration skill might require a rollback plan. Narrow the skill to the type and the review catches fewer issues.

If your team uses Jira with Claude Code, see Jira MCP and Claude Code for how to read and write tickets directly from a coding session. Skills work alongside that setup: the skill drafts the ticket, the MCP connection files it.

Adapting these skills for your team's ticket types

Every team writes ticket types that follow a slightly different structure. A bug report needs reproduction steps and environment details that a user story does not. An API change needs a backwards compatibility check. A data migration needs a rollback plan. Creating a named variant of the user story skill for each common type removes those fields from the manual work on every ticket.

Name each variant clearly: "Bug ticket", "API change ticket", "Data migration ticket". The base structure stays the same; only the required fields change. When you run the review skill on a bug ticket, it expects reproduction steps to be present and flags them as missing if they are not. A skill tuned to the ticket type catches the right gaps.

Store each variant as a separate named skill in the project. Over time the skill set becomes a library of your team's actual ticket standards, maintained in the same place as the decisions and rules that drive them. See Claude skills examples for more patterns across different ticket types.

How to do this with fenbs

1. Create a free account and add a project for the work this ticket workflow covers.
2. Go to Skills and prompts and add each skill: "Draft user story", "Write acceptance criteria", "Review ticket".
3. Add your team's definition of done and any standing requirements as Decisions and rules in the project.
4. Connect Claude over MCP from Integrations. At the start of a session, ask Claude to read the project context and list the available skills.
5. After filing a ticket, note the ticket reference in the task record so the next session can find the work it produced.

fenbs does not connect directly to Jira. It stores the skills and the shared context that makes the output useful. For the claude skills marketplace and claude skills files options, those cover how to share and import skills across projects.