Create JIRA Issues from $ARGUMENTS
Analyze the provided file(s) and create a comprehensive JIRA hierarchy with all mandatory quality gates.
Process
- Analyze: Read $ARGUMENTS to understand scope
- Determine Structure:
- Epic needed if: multiple features, major changes, >3 related files - Direct tasks if: bug fix, single file, minor change
- Create Issues with hierarchy:
Epic → User Story → Tasks (test, implement, document, cleanup)
Mandatory for Every Code Issue
Test-First: Write tests before implementation Quality Gates: All tests/checks must pass, no SonarCloud violations Documentation: Check existing, update/create new, remove obsolete Cleanup: Remove temporary code, scripts, dev configs
Validation Journey
Tickets that change runtime behavior should include a Validation Journey section in the description. This section is consumed by the jira-journey skill to automate verification.
When to Include
Include a Validation Journey when the ticket involves:
- API endpoint changes (new, modified, or removed routes)
- Database schema changes (migrations, new columns, index changes)
- Background job or queue processing changes
- Library or utility function changes that affect exports
- Security fixes (authentication, authorization, input validation)
- Performance-critical changes requiring measurement
When to Skip
Skip the Validation Journey for:
- Documentation-only changes
- Config-only changes (env vars, CI/CD, feature flags with no code)
- Type-definition-only changes (interfaces, types, no runtime effect)
How to Write
Design the journey based on the change type. The agent executing the journey determines how to verify each step using patterns from the project's verfication.md. Place [EVIDENCE: name] markers at key verification points.
Add this section to the ticket description:
h2. Validation Journey
h3. Prerequisites
- Local dev server running
- Database accessible
- Required environment variables set
h3. Steps
1. Verify the current state before changes
2. Apply the change (run migration, deploy, etc.)
3. Verify the expected new state [EVIDENCE: state-after-change]
4. Test error/edge cases [EVIDENCE: error-handling]
5. Verify rollback or cleanup if applicable [EVIDENCE: rollback-check]
h3. Assertions
- Describe what must be true after verification
- Each assertion is verified against the captured evidenceGuidelines
- Steps must be concrete and verifiable — "Run
curl -s localhost:3000/health" not "Check the API" - Evidence markers at verification points — Place
[EVIDENCE: name]at states that prove the change works. Use descriptive kebab-case names (e.g.,api-response,schema-check,rate-limit-hit) - Include 2-5 evidence markers — Enough to prove the change works across happy path and error cases
- Assertions are testable statements — "Health check returns 200 with status ok" not "API works"
- Prerequisites include environment setup — Database connection, env vars, running services
Issue Requirements
Each issue must clearly communicate to:
- Coding Assistants: Implementation requirements
- Developers: Technical approach
- Stakeholders: Business value
Default project: from jira-cli config (override via arguments) Exclude unless requested: migration plans, performance tests
Execute the analysis and create the complete JIRA structure with proper parent-child relationships.