agentleFS
SvampenSvampen/claude-skills/skills/jira-start/SKILL.md

jira-start

Skill0 starsChanged 9 months agoMITView on GitHub

Start working on a Jira ticket. Fetches ticket details via Jira MCP, assigns to current user, transitions to "In Progress", creates a git branch or worktree based on ticket type, and generates a TICKET.md context file. Use when user says "start ticket", "work on ABC-123", "pick up ticket", "begin work on", or similar phrases indicating they want to start a Jira ticket.

1 other project uses a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

4 rules. About 0 are common, 3 are distinctive, and 1 is 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.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use Jira MCP to fetch ticket details.

    line 21
  2. Distinctive:

    Before creating branch/worktree:

    line 65
  3. Very specific:

    Create <TICKET-KEY>.md (e.g., ABC-123.md) in repository root (or worktree root):

    line 111
  4. Distinctive:

    If worktree was created, ask:

    line 139

≈ “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 Start Workflow

Begin work on a Jira ticket with proper git setup and context.

Prerequisites

  • Jira MCP server connected (authentication provides current user identity)
  • Git repository as working directory

Workflow

Step 1: Connect to Jira and Fetch Ticket

Use Jira MCP to fetch ticket details. If MCP unavailable or connection fails: → Inform user, ask if they want to provide ticket details manually or troubleshoot MCP

Required fields to fetch:

  • Key (e.g., ABC-123)
  • Summary (title)
  • Description
  • Type (Story, Bug, Task, etc.)
  • Status
  • Assignee
  • Priority
  • Reporter
  • Acceptance criteria (if field exists)

Step 2: Handle Assignment

Check current assignee:

Unassigned → Assign to current user via MCP (use auth token identity)

Assigned to current user → Continue

Assigned to someone else → Prompt user:

"This ticket is assigned to [name]. Would you like to:

  1. Reassign to yourself
  2. Continue without reassigning
  3. Abort"

Step 3: Transition to In Progress

Query available transitions for the ticket via MCP. Look for transitions matching (case-insensitive):

  • "In Progress"
  • "Start Progress"
  • "Start"
  • "Begin"

Match found → Execute transition

Already in progress-like status → Skip, inform user

No match found → Show available transitions, ask user which to use (or skip)

Step 4: Check Git State

Before creating branch/worktree:

Uncommitted changes detected → Warn user:

"You have uncommitted changes. Proceed anyway, stash them, or abort?"

Step 5: Determine Branch Prefix

Map Jira ticket type to branch prefix:

Ticket TypeBranch Prefix
Storystory/
Bugbugfix/
Tasktask/
Epicepic/
Subtasksubtask/

Type not in table → Ask user for preferred prefix

Step 6: Ask Branch or Worktree

Prompt user:

"How would you like to set up your workspace?

  1. Branch — Create <prefix>/<TICKET-KEY> in current repo
  2. Worktree — Create worktree at ../<repo-name>-<TICKET-KEY> with that branch"

Step 7: Create Branch/Worktree

Determine branch name: <prefix>/<TICKET-KEY> (e.g., story/ABC-123)

If branch already exists:

"Branch story/ABC-123 already exists. Check it out, or create with different name?"

Branch option:

git checkout -b <branch-name>

Worktree option:

# From repo at /path/to/repo-name
git worktree add -b <branch-name> ../repo-name-<TICKET-KEY> <branch-name>

Step 8: Create TICKET.md

Create <TICKET-KEY>.md (e.g., ABC-123.md) in repository root (or worktree root):

# <TICKET-KEY>: <Summary>

**Type:** <Type> | **Priority:** <Priority> | **Reporter:** <Reporter>

[View in Jira](<jira-url>)

## Description

<Full description from Jira>

## Acceptance Criteria

<If available, otherwise omit section>

## Technical Notes

<!-- Add implementation notes, decisions, blockers here -->

## References

<!-- Links to docs, related tickets, PRs -->

Step 9: VS Code (Worktree Only)

If worktree was created, ask:

"Open VS Code in the new worktree folder?"

If yes:

code ../repo-name-<TICKET-KEY>

Error Handling

  • MCP connection failure: Offer manual ticket details or MCP troubleshooting
  • Transition failure: Show error, offer to continue without transition
  • Git errors: Show error details, suggest resolution
  • Permission errors: Explain and abort gracefully

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.