---
name: jira-lifecycle
description: Full Jira ticket lifecycle management for ESIDEPAISY.
---

# Skill: jira-lifecycle

Full Jira ticket lifecycle management for ESIDEPAISY.

## Invoked by

🎫 JiraOps mode

## Required Inputs

| Input | Source | Example |
|-------|--------|---------|
| `TICKET_KEY` | Jira issue key | `ESIDEPAISY-12081` |

## Overview

This skill manages a Jira ticket through its full lifecycle, from initial setup through to final acceptance. It handles field validation, Smart Checklist management, status transitions, attachments, and structured comments.

## Steps

### 1. Validate mandatory fields

```python
ticket = retrieve_ticket_details(TICKET_KEY)
```

Check and fix:

| Field | ID | Required | How to resolve |
|-------|----|----------|---------------|
| Feature Link | `customfield_10001` | ✅ Mandatory | Look up parent Epic via JQL: `project = ESIDEPAISY AND issuetype = Epic AND summary ~ "<module>"` |
| Sprint | `customfield_10000` | ✅ Mandatory | Derive from active sprint: `get_agile_boards("ESIDEPAISY")` → `get_sprints_from_board(board_id, states="active")` |
| Assignee | `assignee` | Recommended | `ticket_assignment(TICKET_KEY, assignee="currentUser()")` |

If Feature Link is missing:
```python
# Find the parent Epic
epics = list_tickets(jql_search='project = ESIDEPAISY AND issuetype = Epic AND summary ~ "<module keyword>"')
# Update the ticket
update_ticket_fields(TICKET_KEY, fields={"customfield_10001": epics[0]["key"]})
```

### 2. Create Smart Checklist

Set up the standard PAISY pipeline checklist:

```python
update_checklist(TICKET_KEY, items=[
    {"name": "## Analyse"},
    {"name": "Assessment erstellt", "status": "-"},
    {"name": "Plan erstellt", "status": "-"},
    {"name": "Testplan erstellt", "status": "-"},
    {"name": "GO erhalten", "status": "-!"},  # mandatory
    {"name": "---"},
    {"name": "## Implementierung"},
    {"name": "Code-Änderungen", "status": "-"},
    {"name": "Tests implementiert", "status": "-"},
    {"name": "Build grün", "status": "-!"},  # mandatory
    {"name": "---"},
    {"name": "## Review & Docs"},
    {"name": "Code Review", "status": "-"},
    {"name": "Lösungsdokumentation", "status": "-"},
    {"name": "PDF generiert", "status": "-"},
    {"name": "PR erstellt", "status": "-"},
    {"name": "Jira aktualisiert", "status": "-"},  # marked done only after PR merge
])
```

### 3. Status transitions

Manage the ticket through the ESIDEPAISY workflow:

| Phase | Status | When |
|-------|--------|------|
| Start | `In Progress` | After worktree creation, before implementation |
| Review | `In Review` | After implementation + tests, before code review |
| PR created | `Blocked` | After PR creation — pipeline STOPS here |
| Post-merge | `Accepted` | After PR is merged (manual trigger only) |

```python
update_status(TICKET_KEY, status="In Progress")
```

**Important:** The automated pipeline ends at `Blocked`. The transition to `Accepted` happens only after a human merges the PR and manually triggers the post-merge phase.

### 4. Update checklist as work progresses

Update individual items as phases complete:

```python
# After assessment is done
update_checklist(TICKET_KEY, items=[
    {"name": "## Analyse"},
    {"name": "Assessment erstellt", "checked": True},
    {"name": "Plan erstellt", "status": "~"},  # in progress
    # ... rest unchanged
])
```

**Important:** `update_checklist` replaces ALL items. Always send the full checklist with updated statuses.

### 5. Add structured comments at phase boundaries

At each major phase transition, add a German comment:

```python
# After planning phase
add_comment_to_ticket(TICKET_KEY, comment="""
*Phase 1 abgeschlossen: Analyse & Planung*

Assessment, Plan und Testplan erstellt:
- Assessment: [TICKET_KEY-assessment.md]
- Plan: [TICKET_KEY-plan.md]
- Testplan: [TICKET_KEY-testplan.md] ({N} Testfälle)

GO erhalten am {date}.
""")

# After implementation
add_comment_to_ticket(TICKET_KEY, comment="""
*Phase 3-5 abgeschlossen: Implementierung & Tests*

Branch: current/{type}/{module}/{TICKET_KEY}-{desc}
Änderungen: {N} Dateien geändert, {M} neu
Tests: {T} Tests, alle bestanden
""")

# After documentation + PR creation (pipeline end)
add_comment_to_ticket(TICKET_KEY, comment="""
*Pipeline abgeschlossen — Warten auf PR-Merge*

Lösungsdokumentation als PDF angehängt.
PR erstellt: [PR #{pr_id}|{pr_url}]

Ticket wird auf *Blocked* gesetzt bis PR gemerged ist.
Nach Merge: Status → Accepted, Checklist-Punkt "Jira aktualisiert" abhaken.
""")
```

### 6. Upload attachments

```python
# Upload solution PDF
add_attachment_to_ticket(TICKET_KEY, file_path="/absolute/path/to/<TICKET_KEY>-solution.pdf")
```

### 7. Pre-merge checklist update

Mark all items done EXCEPT "Jira aktualisiert" (reserved for post-merge):

```python
update_checklist(TICKET_KEY, items=[
    {"name": "## Analyse"},
    {"name": "Assessment erstellt", "checked": True},
    {"name": "Plan erstellt", "checked": True},
    {"name": "Testplan erstellt", "checked": True},
    {"name": "GO erhalten", "status": "+!"},
    {"name": "---"},
    {"name": "## Implementierung"},
    {"name": "Code-Änderungen", "checked": True},
    {"name": "Tests implementiert", "checked": True},
    {"name": "Build grün", "status": "+!"},
    {"name": "---"},
    {"name": "## Review & Docs"},
    {"name": "Code Review", "checked": True},
    {"name": "Lösungsdokumentation", "checked": True},
    {"name": "PDF generiert", "checked": True},
    {"name": "PR erstellt", "checked": True},
    {"name": "Jira aktualisiert", "status": "-"},  # ← left open until post-merge
])
```

### 8. Set status to Blocked (pipeline stops here)

```python
update_status(TICKET_KEY, status="Blocked")
add_comment_to_ticket(TICKET_KEY, comment="""
*Status: Blocked — Warten auf PR-Merge*

Alle automatisierten Schritte abgeschlossen.
PR muss reviewed und gemerged werden, bevor das Ticket auf Accepted gesetzt wird.
""")
```

**⛔ PIPELINE STOPS HERE.** Do not proceed to Accepted automatically.

### 9. Post-merge finalization (manual trigger only)

This step runs only when explicitly triggered by the user after the PR has been merged.

```python
# Final checklist — mark "Jira aktualisiert" as done
update_checklist(TICKET_KEY, items=[
    # ... all items from step 7 with "checked": True ...
    {"name": "Jira aktualisiert", "checked": True},
])

update_status(TICKET_KEY, status="Accepted")
add_comment_to_ticket(TICKET_KEY, comment="""
*PR gemerged — Ticket abgeschlossen*

Alle Checklist-Punkte erledigt. Status → Accepted.
""")
```

## Language

- All Jira content (summary, description, comments, checklist items): **German**
- Technical terms (branch names, file paths, tool names): English as-is

## Conventions

- Feature Link (`customfield_10001`): always look up dynamically, never hardcode Epic keys
- Sprint: always derive from active sprint, never hardcode sprint IDs
- Comments: use Jira wiki markup (`*bold*`, `{code}`, etc.)
- Attachments: use absolute file paths
- Checklist: always send the FULL list (Railsware replaces all items on update)

## Partial Lifecycle

Not every ticket needs the full lifecycle. For quick fixes:

| Scenario | Skip |
|----------|------|
| Trivial bugfix (< 1 hour) | Skip assessment, testplan, review. Keep checklist minimal. |
| Documentation-only change | Skip implementation, tests, review phases. |
| Hotfix | Skip planning loop. Minimal checklist: Code → Test → Deploy. |

Adjust the checklist template accordingly when creating it.

**Human gate rule applies to ALL variants:** After PR creation, status → Blocked. Never auto-transition to Accepted.

## Pipeline Boundary

The automated pipeline covers steps 1–8. Step 9 (post-merge → Accepted) is a separate manual action.

| Boundary | Trigger | Action |
|----------|---------|--------|
| Pipeline end | PR created | Status → Blocked, comment with PR link |
| Post-merge | User says "PR merged" or "finalize TICKET_KEY" | Status → Accepted, final checklist update |