Create

Create Jira Issue

/jira:create <type> [project-key] <summary> [--component <name>] [--version <version>] [--parent <key>]

Creates Jira issues following best practices and team-specific conventions. Supports stories, epics, features, initiatives, tasks, bugs, risks, spikes, and feature requests with intelligent defaults, interactive prompts, and validation.

Type-Specific Guidance

Load the reference file matching the issue type for templates, interactive workflows, and best practices:

Also load Markdown for Jira for description formatting.

Arguments

• type (required) — story | epic | feature | initiative | task | bug | risk | spike | feature-request
• project-key (optional for bugs and feature-requests) — e.g., CNTRLPLANE, OCPBUGS, RFE. Default for bugs: OCPBUGS. Default for feature-requests: RFE.
• summary (required) — Issue title. Use quotes for multi-word: "Enable automatic scaling"
• --component (optional) — Component name. Auto-detected from summary for known projects.
• --version (optional) — Target version. Normalized to openshift-X.Y per project conventions.
• --parent (optional) — Parent issue key for linking (e.g., CNTRLPLANE-123).

Implementation Phases

Phase 1: Load Guidance

1. Load the type-specific reference file from the table above
2. Invoke the jira:jira-conventions skill when the project key, component, or summary keywords match a known project or team

Phase 2: Parse Arguments & Detect Context

Parse required and optional arguments. Analyze summary text for context clues (team, component, platform keywords).

Phase 3: Apply Smart Defaults

Universal requirements (ALL tickets):

"labels": ["ai-generated-jira"]
"security": {"name": "Red Hat Employee"}
contentFormat: "markdown"

Project and team defaults (version, component, labels) come from the jira-conventions skill.

Phase 4: Interactive Prompts

Follow the type-specific reference file's interactive workflow to collect missing information (story format, bug template sections, epic scope, etc.).

Phase 5: Summary Validation

Check for anti-patterns before creation:

1. Summary starts with "As a" or contains "I want" / "so that" → belongs in description
2. Summary exceeds 100 characters → likely too long

If detected:

The summary looks like a full user story. Summaries should be concise titles.

Current: "As a cluster admin, I want to configure ImageTagMirrorSet in HostedCluster CRs so that I can enable tag-based image proxying"

Suggested: "Enable ImageTagMirrorSet configuration in HostedCluster CRs"

Use the suggested summary? (yes/no/edit)

Phase 6: Security Validation

Scan all content (summary, description) for sensitive data:

• Credentials, API tokens, cloud keys (AWS, GCP, Azure)
• Kubeconfigs, SSH keys, certificates, PEM files
• URLs with embedded credentials

If detected: STOP creation, inform user of the type found (without echoing it), suggest placeholder values.

Phase 7: Create Issue via MCP

Use createJiraIssue with collected parameters. Include universal fields and any project/team-specific fields.

Phase 8: Return Result

Created: PROJECT-1234
Title: <issue summary>
URL: <issue URL>

Applied defaults:
- <Field>: <Value>

Custom Fields (redhat.atlassian.net)

Issue Hierarchy and Parent Linking

Jira issue types have a hierarchyLevel that determines valid parent-child relationships. The parent field only accepts an issue whose hierarchyLevel is exactly one level above the child. Not all projects have all levels — use getJiraProjectIssueTypesMetadata to discover available types and their levels for a given project.

Level 3: Outcome
Level 2: Feature / Initiative
Level 1: Epic
Level 0: Story / Task / Bug / Spike
Level -1: Sub-task

Parent Field

Use {"parent": {"key": "PARENT-KEY"}} in additional_fields for all parent-child relationships (Story→Epic, Task→Epic, Bug→Epic, Spike→Epic, Epic→Feature, Epic→Initiative, Feature→Outcome, Initiative→Outcome).