ticket - SKILL.md Agent Skill

name: ticket description: > Create, view, or update a JIRA ticket. Supports create, edit, view, assign, transition, check-version, set-version, and clone operations via acli CLI. argument-hint: PROJQUAY-XXXX [action] | create [description] allowed-tools: - Bash(acli jira workitem view ) - Bash(acli jira workitem create ) - Bash(acli jira workitem edit ) - Bash(acli jira workitem transition ) - Bash(acli jira workitem clone ) - Bash(acli jira workitem link create ) - Bash(curl -sS -u * https://.atlassian.net/rest/api/3/) - Read - Grep - AskUserQuestion

JIRA Ticket Operations

Parse $ARGUMENTS to determine the action:

Starts with create → Create a new ticket
Contains an issue key (e.g., PROJQUAY-1234) → View by default, or the specified action
Actions: view, create, edit, assign, transition, check-version, set-version, clone

JIRA API Access

Use the acli CLI for all operations. For custom field writes (set-version, components, priority on existing issues), fall back to REST API with curl.

REST credentials: ~/.config/acli/jira_config.yaml (email), ~/.config/acli/token.txt or $JIRA_API_TOKEN (token).

Target Version field: ${JIRA_TARGET_VERSION_FIELD:-customfield_10855}. Domain: ${JIRA_DOMAIN:-redhat.atlassian.net}.

Operations

Create

Gather required fields interactively — ask the user for anything not provided in $ARGUMENTS:

Project (required): PROJQUAY or QUAYIO
Type (required): Bug, Story, Task, or Epic
Summary (required): concise title, under 100 characters
Description (required): expand the user's input with clarifying questions (current vs expected behavior, steps to reproduce, acceptance criteria)
Component: quay, quay-ui, quay-operator (PROJQUAY) or quay.io (QUAYIO)
Priority: Critical, Major, Minor, or Undefined (default)
Assignee: defaults to @me
Labels: suggest eus-applicable for CVE/security fixes

Present a summary for confirmation before creating.

acli jira workitem create \
  --project "$PROJECT" --type "$TYPE" --summary "$SUMMARY" \
  --description "$DESCRIPTION" --assignee "${ASSIGNEE:-@me}" \
  --label "$LABELS" --json

For fields acli create does not support natively (components, priority, epic link), set them via REST after creation:

curl -sS -u "$EMAIL:$TOKEN" -X PUT -H "Content-Type: application/json" \
  -d '{"fields":{"components":[{"name":"COMPONENT"}],"priority":{"name":"PRIORITY"}}}' \
  "https://${JIRA_DOMAIN:-redhat.atlassian.net}/rest/api/3/issue/$ISSUE_KEY"

For epic link, set parent: {"fields":{"parent":{"key":"EPIC_KEY"}}}.

Alternatively, use --from-json with additionalAttributes to set custom fields at creation time:

acli jira workitem create --from-json ticket.json --json

Where ticket.json includes additionalAttributes for custom fields like components and priority.

Report the created ticket key and URL.

Edit

acli jira workitem edit --key "$ISSUE_KEY" --summary "$NEW_SUMMARY" --yes

Supported fields via acli: --summary, --description, --assignee, --labels, --type.

For fields requiring REST (components, priority, epic link, custom fields), use the same REST pattern as Create above.

View (default)

acli jira workitem view "$ISSUE_KEY" --fields '*all' --json

Extract key, summary, status, assignee, type, priority, labels. Check fields.customfield_10855[].name for Target Version.

Assign

acli jira workitem edit --key "$ISSUE_KEY" --assignee "@me" --yes

If a specific assignee is provided, pass their email instead of @me.

Transition

acli jira workitem transition --key "$ISSUE_KEY" --status "$STATUS" --yes

Valid statuses: New, ASSIGNED, POST, ON_QA, Verified, Release Pending, Closed, MODIFIED

If transition fails, list available transitions with acli jira workitem view "$KEY" --fields '*all' --json and check the transitions array.

Check Target Version

acli jira workitem view "$ISSUE_KEY" --fields '*all' --json | jq '.fields.customfield_10855'

If the field is a non-empty array, backporting is required after merge. If null or empty, no backporting needed.

Set Target Version

acli edit does not support custom fields. Use REST with jq to build the payload dynamically:

jq -n --arg ver "$VERSION" --arg field "${JIRA_TARGET_VERSION_FIELD:-customfield_10855}" \
  '{fields: {($field): [{"name": $ver}]}}' | \
  curl -sS -u "$EMAIL:$TOKEN" -X PUT -H "Content-Type: application/json" -d @- \
  "https://${JIRA_DOMAIN:-redhat.atlassian.net}/rest/api/3/issue/$ISSUE_KEY"

Clone

acli jira workitem clone --key "$ISSUE_KEY" --to-project "$PROJECT" --yes

After cloning, link the clone to the original:

acli jira workitem link create --out "$CLONE_KEY" --in "$ISSUE_KEY" --type Blocks --yes

If a target version is needed on the clone, set it via REST (same as Set Target Version above).

Customer Data

Never include customer names, company names, or identifying information in ticket descriptions. Generalize customer-specific details.

Configuration

JIRA_DOMAIN — JIRA instance (default: redhat.atlassian.net)
JIRA_DEFAULT_EMAIL — fallback email for auth
JIRA_TARGET_VERSION_FIELD — custom field ID (default: customfield_10855)