---
name: batch-ticket-processing
description: Process a batch of Jira tickets end-to-end. Use this skill when the user asks to work through a list of Jira tickets, process an epic, implement a sprint batch, or work through multiple Jira issues in sequence. Handles branch creation, implementation, commits, PRs, Jira comments, transitions, and assignments per ticket.
---

# Batch Ticket Processing Skill

Processes multiple Jira tickets end-to-end: fetch → review → implement → commit/push → PR → Jira update → transition → assign.

## ⚠️ Safety Rules (Non-Negotiable)

- **Never commit or push without explicit per-ticket user approval** — ask "Ready to commit and push?" before every `git commit` and `git push`
- **Never transition or close a ticket without implementing** the work and getting PR approval
- **Never auto-approve destructive git operations** — `git reset`, `git push --force`, branch deletion require explicit user confirmation
- **Pause between tickets** — after each ticket is complete, summarize what was done and confirm before starting the next one (unless the user explicitly says "process all without pausing")
- **One ticket at a time** — do not start implementing the next ticket until the current one is fully committed and the Jira issue updated

---

## Configuration

At the start of a batch session, confirm these values with the user (or load from `.claude/batch-config.json` if present):

| Setting | Description | Example |
|---|---|---|
| `base_branch` | Branch to cut ticket branches from | `taca/dev_preview` |
| `pr_target` | Branch PRs should merge into | `taca/dev` |
| `jira_project` | Jira project key | `TACA` |
| `reviewer_account_id` | Jira account ID to assign tickets to | `557058:22de1358-...` |
| `ready_for_review_transition_id` | Jira transition ID for "Ready for Review" | `131` |
| `in_progress_transition_id` | Jira transition ID for "In Progress" | (optional) |

If `.claude/batch-config.json` exists in the working directory, load it silently. Otherwise prompt the user.

### Example batch-config.json
```json
{
  "base_branch": "taca/dev_preview",
  "pr_target": "taca/dev",
  "jira_project": "TACA",
  "reviewer_account_id": "557058:22de1358-6224-49c3-8628-bd66c3b65e3e",
  "ready_for_review_transition_id": "131"
}
```

---

## Phase 1: Fetch and Review Tickets

### Fetch by Epic
```
Use mcp__claude_ai_Atlassian__searchJiraIssuesUsingJql with:
JQL: project = TACA AND "Epic Link" = TACA-XXX AND statusCategory != Done ORDER BY created ASC
```

### Fetch by JQL (general)
Accept any JQL the user provides. Always add `ORDER BY created ASC` if not specified.

### Fetch by ticket list
If the user provides a list of ticket IDs (e.g. "TACA-208, TACA-209, TACA-212"), fetch each via `mcp__claude_ai_Atlassian__getJiraIssue` and build the queue.

### Review Gate
After fetching, present a numbered table:

```
| # | Ticket | Summary | Status |
|---|--------|---------|--------|
| 1 | TACA-208 | Fix mobile menu data attribute | To Do |
| 2 | TACA-209 | Fix mega menu dropdown padding | To Do |
...
```

Ask: **"Proceed with all N tickets, or which ones should I skip?"**

Do not start implementation until the user approves the list.

---

## Phase 2: Per-Ticket Workflow

For each approved ticket, follow this exact sequence:

### Step 1 — Read the Ticket
Fetch full ticket details: summary, description, acceptance criteria, labels, linked issues.

Present a brief summary:
```
--- TACA-208: Fix mobile menu data attribute ---
Type: Bug | Priority: Medium
AC: [acceptance criteria bullet points]
```

### Step 2 — Create Branch
```bash
git checkout base_branch
git pull origin base_branch
git checkout -b TICKET-ID-slugified-summary
```

Branch name format: `TICKET-ID-lowercase-words-from-summary` (max ~50 chars, hyphens only, no special chars).

Example: `TACA-208-fix-mobile-menu-data-attribute`

### Step 3 — Implement
Read the relevant files. Understand the code before making changes. Implement the fix per acceptance criteria.

Follow the project's development principles:
- Prefer long-term solutions over quick fixes
- No backward compatibility hacks
- No `!important` in CSS
- Match existing patterns in the codebase

After implementation, briefly describe what was changed and why.

### Step 4 — Ask to Commit
```
Ready to commit and push TACA-208?
Changed files: [list]
Proposed message:
  fix(TACA-208): Fix mobile menu data attribute

  - [bullet describing change]
  - [bullet describing change]
```

Wait for "yes", "go for it", "yup", "commit and push", or equivalent.

**Never commit without this confirmation.**

### Step 5 — Commit and Push
```bash
git add [specific files — never git add -A or git add .]
git commit -m "$(cat <<'EOF'
fix(TACA-208): Fix mobile menu data attribute

- Bullet describing change 1
- Bullet describing change 2
EOF
)"
git push origin TACA-208-fix-mobile-menu-data-attribute
```

Do NOT include "Co-Authored-By: Claude" or AI attribution in commit messages.

### Step 6 — Create PR
```bash
gh pr create \
  --title "TACA-208: Fix mobile menu data attribute" \
  --base pr_target \
  --body "$(cat <<'EOF'
## Summary
- [What was changed and why]

## Jira
[TACA-208](link to ticket)

## Test plan
- [ ] [Specific test steps from acceptance criteria]
EOF
)"
```

Capture the PR URL from the output.

### Step 7 — Update Jira

**Add comment** (via `mcp__claude_ai_Atlassian__addCommentToJiraIssue`):
```
PR created: [PR URL]

Changes: [1-2 sentence summary of what was implemented]
```

**Transition to Ready for Review** (via `mcp__claude_ai_Atlassian__transitionJiraIssue`):
Use `ready_for_review_transition_id` from config.

**Assign to reviewer** (via `mcp__claude_ai_Atlassian__editJiraIssue`):
```json
{ "assignee": { "accountId": "reviewer_account_id" } }
```

### Step 8 — Confirm and Continue
Report completion:
```
✓ TACA-208 complete
  Branch: TACA-208-fix-mobile-menu-data-attribute
  PR: #66 — [URL]
  Jira: Transitioned to Ready for Review, assigned to Jonas

Ready to start TACA-209?
```

Wait for user confirmation before moving to the next ticket (unless "process all" mode was set).

---

## Phase 3: Batch Summary

After all tickets are processed, output a summary table:

```
| Ticket | PR | Status |
|--------|----|--------|
| TACA-208 | #66 | ✓ Complete |
| TACA-209 | #67 | ✓ Complete |
| TACA-211 | — | ⚠ Skipped (user request) |
```

---

## Error Handling

| Situation | Action |
|-----------|--------|
| Build fails after changes | Do not commit. Diagnose and fix. Show error to user. |
| PR creation fails | Report the error. Do not update Jira. Ask user how to proceed. |
| Jira transition fails | Report it, but don't block — the PR still exists. Note in summary. |
| Merge conflict on branch creation | Report conflict. Ask user to resolve or skip ticket. |
| Ticket is already "In Progress" or "Ready for Review" | Flag it. Ask user whether to re-process or skip. |
| Implementation is ambiguous | Ask the user before writing code. Don't guess. |

---

## Modes

### Default Mode
Pause for commit approval and "start next?" confirmation between every ticket.

### "Process All" Mode
User says: *"process all without pausing"* or *"just do all of them"*

In this mode:
- Still pause for commit approval on each ticket
- Skip the "ready to start next?" pause
- Never skip the commit confirmation — this is always required

### "Plan Only" Mode
User says: *"just plan it"* or *"don't implement yet"*

Fetch tickets, present the review table, describe the approach for each ticket, then stop. No branches, no code changes.

---

## Jira MCP Tools Reference

| Operation | Tool |
|-----------|------|
| Search tickets | `mcp__claude_ai_Atlassian__searchJiraIssuesUsingJql` |
| Get ticket details | `mcp__claude_ai_Atlassian__getJiraIssue` |
| Add comment | `mcp__claude_ai_Atlassian__addCommentToJiraIssue` |
| Get transitions | `mcp__claude_ai_Atlassian__getTransitionsForJiraIssue` |
| Transition issue | `mcp__claude_ai_Atlassian__transitionJiraIssue` |
| Edit issue (assign) | `mcp__claude_ai_Atlassian__editJiraIssue` |
| Look up account ID | `mcp__claude_ai_Atlassian__lookupJiraAccountId` |

---

## Notes

- Always use `git push origin <branch-name>` — never bare `git push`
- Always stage specific files, never `git add -A` or `git add .`
- If a linter auto-modifies a file after saving, re-read it before the next edit
- Large files (>500 lines): use `offset`/`limit` when reading
- Build commands: suppress verbose output with `2>&1 | tail -5`