pi_mcps/zoo_backup/work/skills/jira-lifecycle/SKILL.md

name, description

name	description
jira-lifecycle	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

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:

# 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:

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)

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:

# 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:

# 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

# 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):

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)

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.

# 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