feat: archive zoo_backup for home sync
This commit is contained in:
Patrick Plate
@@ -0,0 +1,245 @@
|
||||
---
|
||||
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 |
|
||||
Reference in New Issue
Block a user