Jira Workflow
Best practices for AI agents to create and manage Jira tickets when performing automated work like fixing vulnerabilities, resolving SonarQube issues, or improving test coverage.
Core Principles
- Create Ticket Before Work - Always create/find a Jira ticket before starting
- Discover Project Key - Never hardcode project keys
- Search Before Creating - Check for existing tickets first
- Severity-Based Processing - Process issues one severity level at a time
- Link Everything - Connect Jira → Branch → Commits → PR
Skill Contents
Sections
Available Resources
📚 references/ - Detailed documentation
Workflow Overview
| Step | Description | Reference |
|---|
| 0. Discover | Find user's Jira project key | references/project-discovery.md |
| 1. Search | Check for existing open tickets | references/ticket-search.md |
| 2. Create | Create ticket if none exists | references/ticket-creation.md |
| 3. Branch | Create branch with Jira key | references/branch-naming.md |
| 4. Process | Fix by severity level | references/severity-processing.md |
Quick Reference
Emoji Conventions
| Work Type | Emoji | Example |
|---|
| AI-assisted (all) | 🤖 | Required in ALL AI commits/PRs |
| Security/Vulnerability | 🛡️ | 🤖 🛡️ fix(security): resolve critical CVE |
| Code Quality/SonarQube | ✅ | 🤖 ✅ fix(quality): resolve BLOCKER issues |
| Test Coverage | 🧪 | 🤖 🧪 test: improve coverage |
| Dependency Updates | 📦 | 🤖 📦 chore(deps): update Spring Boot |
| Documentation | 📝 | 🤖 📝 docs: update API documentation |
| Performance | ⚡ | 🤖 ⚡ perf: optimize queries |
| Refactoring | ♻️ | 🤖 ♻️ refactor: simplify error handling |
Ticket Summary Format
🤖🛡️ Fix [SEVERITY] Dependabot vulnerabilities in [repo-name]
🤖✅ Resolve [SEVERITY] SonarQube issues in [repo-name]
🤖🧪 Improve test coverage for [module/class]
🤖📦 Update [dependency] to [version]
Branch Naming
{type}/{JIRA-KEY}-{short-description}
Examples:
fix/PROJ-123-critical-vulnerabilitiesfix/PROJ-456-blocker-sonar-issuestest/PROJ-789-coverage-payment-service
References
| Reference | Content |
|---|
references/project-discovery.md | How to discover user's Jira project key |
references/ticket-search.md | JQL queries to find existing tickets |
references/ticket-creation.md | Create tickets with proper format |
references/branch-naming.md | Branch naming with Jira keys |
references/severity-processing.md | Process by severity level |
Severity-Based Processing
Vulnerability Severity Order
- CRITICAL - Fix first
- HIGH - Only after no CRITICAL remain
- MEDIUM/MODERATE - Only after no HIGH remain
- LOW - Only after no MEDIUM remain
SonarQube Severity Order
- BLOCKER - Fix first
- CRITICAL - Only after no BLOCKER remain
- MAJOR - Only after no CRITICAL remain
- MINOR - Only after no MAJOR remain
- INFO - Only after no MINOR remain
Best Practices
- One severity per PR - Keep PRs focused and reviewable
- Batch related fixes - Group similar issues in one commit
- Clear descriptions - Document what was fixed and why
- Link everything - Jira ticket ↔ Branch ↔ Commits ↔ PR
- Update ticket status - Move ticket through workflow as work progresses
Skill Dependencies
| Skill | Purpose |
|---|
pr-lifecycle | PR creation, commit formats, GitHub CLI |
Related
.claude/skills/pr-lifecycle - PR creation and management.claude/skills/stacked-prs - Stacked PR workflows
