← Back to catalog

▸jira-git-flow

redickowii☍ owners: @redickowii
METADATA
namejira-git-flow
descriptionBridges a Jira issue and git — creates the correctly named branch for a task, links commit/branch/MR back to the issue, and transitions the issue status (To Do → In Progress → Done) as work moves. Use when the user says "начать задачу", "start EDS-1234", "ветку под задачу", "open MR for this task", or wants Jira and git to stay in sync. Branch naming is configurable; an EDS-style convention ships as the default.
licenseMIT
tags
jiragitworkflow
owners
redickowii
metadata{"author":"redickowii","version":"1.0"}
SKILL.MD

Jira Git Flow

Keep a Jira issue and the git branch/MR in sync: branch from the right base, name it from the issue key, move the issue through its workflow, and reference the key in commits/MRs. Jira access goes through the jira-cli skill; git via the Bash tool.

##Trigger

User invokes /jira-git-flow, or asks to start work on / open an MR for an issue key (<PROJECT>-<NUMBER>). Subcommands by intent: start, commit, mr, finish.

##Branch convention (configurable)

Default = EDS-style (from the user's git rules); override per request.

TypeBranchBase
Epicepic/<KEY>master/main
Feature<KEY>epic/<KEY> of the parent epic
Bugbug/<KEY>parent epic/<KEY>

If the team uses a flat convention instead (feature/<KEY>-slug off main), ask once and follow that. Never assume a base branch — confirm the base if the epic branch is ambiguous.

##Workflow

###start — begin work on an issue

  1. Fetch the issue: jira issue view <KEY> --plain (type, summary, parent epic).
  2. Determine base branch from the convention + the issue's epic. Verify it exists: git rev-parse --verify <base> (fetch first: git fetch).
  3. Create/checkout the branch: git checkout <base> && git pull && git checkout -b <branch>.
  4. Assign + transition (ask before mutating Jira): jira issue assign <KEY> $(jira me) and jira issue move <KEY> "In Progress".
  5. Report branch name + new issue status.

###commit — reference the issue in a commit

  • The commit message MUST contain the issue key (<KEY>). Refuse to commit without it on a key-named branch.
  • Do not add any Co-Authored-By / tool-attribution lines.
  • Suggest the message, show staged files, then commit on yes.

###mr — open a merge request / PR

  1. Push the branch: git push -u origin <branch>.
  2. Target = the base branch (epic for features/bugs), not master/main.
  3. Create the MR (GitLab glab mr create if available, else print the MR URL / compare link). Title and description reference <KEY>; link the Jira issue URL in the MR description.
  4. Optionally move the issue to "In Review" if that status exists.

###finish — wrap up

  1. Confirm the MR is merged (or ask).
  2. Transition the issue: jira issue move <KEY> "Done" (ask first; set resolution if the workflow needs one).
  3. Optionally log work via the jira-worklog skill.

##Guardrails

  • Never commit directly to master/main/develop — those are protected.
  • Never switch branches without the user's intent being clear.
  • Before the first change in a session, run git branch --show-current; if it does not match the task key, stop and ask.
  • Every Jira-mutating step (assign, move, write) asks for confirmation; default is no.
  • One retry max on a failing jira-cli/glab call, then report the exact error and stop — no retry loops.