Jira Skill

Overview

This skill provides a Python CLI for common Jira REST API workflows:

• Search with JQL
• Get issue details
• Create and update issues with JSON payloads
• Transition issues by name or ID
• Add comments and list existing comments
• Discover issue types and required fields for creation

The skill supports Jira Cloud with email plus API token authentication and Jira Server or Data Center with a personal access token.

Use --fields on read commands by default to keep output concise. The script supports dot-notation such as fields.status.name and prints tab-separated output for lists.

Parameters Reference

Script Reference

Search for Issues

Use bounded JQL for Jira Cloud queries. Include a project, assignee, sprint, or another filter instead of a bare ORDER BY query. See JQL Reference for the query patterns this skill expects.

python scripts/jira.py --fields key,fields.summary,fields.status.name search 'project = PROJ AND status = "In Progress"'
python scripts/jira.py --fields key,fields.summary search 'assignee = currentUser() ORDER BY updated DESC' 10

Get One Issue

python scripts/jira.py --fields key,fields.summary,fields.priority.name,fields.status.name get PROJ-123

Create an Issue

Discover valid issue types first:

python scripts/jira.py fields PROJ

Inspect required fields for one issue type:

python scripts/jira.py fields PROJ 10045

Create the issue:

python scripts/jira.py create '{
  "fields": {
    "project": { "key": "PROJ" },
    "summary": "Document rollout checklist",
    "issuetype": { "name": "Task" },
    "labels": ["docs", "release"]
  }
}'

Update an Issue

python scripts/jira.py update PROJ-123 '{
  "fields": {
    "summary": "Updated summary",
    "priority": { "name": "High" },
    "labels": ["backend", "urgent"]
  }
}'

Transition an Issue

Use a transition display name or a numeric transition ID:

python scripts/jira.py transition PROJ-123 'In Progress'
python scripts/jira.py transition PROJ-123 31

If a transition name is not found, the script returns the available transition names in the error output.

Comment on an Issue

python scripts/jira.py comment PROJ-123 'PR #42 addresses this issue.'
printf 'Deployed to staging.\n' | python scripts/jira.py comment PROJ-123

List Comments

python scripts/jira.py --fields _issue,author.displayName,created,body comments PROJ-123 PROJ-456

Prerequisites

Set the required environment variables before running the script.

Authentication Variables

Authentication is selected automatically:

• If JIRA_PAT is set, the script uses bearer authentication for Jira Server or Data Center.
• Otherwise, the script expects JIRA_USER_EMAIL and JIRA_API_TOKEN for Jira Cloud.
• Scoped Cloud mode routes only to https://api.atlassian.com/ex/jira/{cloudId}; mixed Cloud and Data Center credentials fail closed.

Scoped Cloud Token Setup

Scoped mode uses the same Basic authentication variables as unscoped mode and adds a Cloud ID. It is not the OAuth 3LO flow, so the oauth/token/accessible-resources endpoint is not a discovery or introspection step for these credentials.

1. Create a scoped API token for your Atlassian account and select its scopes during creation. See Manage API tokens for your Atlassian account.
2. Choose scopes for the commands you intend to run. read:jira-work covers search, get, comments, and fields. Add write:jira-work for create, update, transition, and comment. Granular scopes are listed in Jira scopes for OAuth 2.0 and Forge apps. Jira project permissions still apply independently of token scopes.
3. Obtain the Cloud ID for your site from a trusted Atlassian administrator or your site's account record. The Cloud ID is not a secret, but it determines the request destination.
4. Confirm that the Cloud ID belongs to the same site as JIRA_BASE_URL. The CLI cannot verify this association: in scoped mode it routes to the Atlassian resource API and does not use JIRA_BASE_URL as a destination. Treat the association as operator-maintained configuration.
5. Set the variables, then confirm access with a read-only command:

export JIRA_BASE_URL="https://company.atlassian.net"
export JIRA_USER_EMAIL="you@example.com"
export JIRA_API_TOKEN="$(cat ~/.secrets/jira-token)"
export JIRA_CLOUD_TOKEN_MODE="scoped"
export JIRA_CLOUD_ID="your-cloud-id"
python scripts/jira.py --fields key search "ORDER BY created DESC" --max-results 1

A successful read proves the token and route work together. It does not prove that the Cloud ID corresponds to JIRA_BASE_URL, so verify that separately in step 4.

Operational Variables

Audit Logging

When JIRA_AUDIT_LOG is set, the script writes a structured JSON Lines audit trail for every API request. Auditing is fail-closed and write-ahead:

• An attempt record is written before the request is sent. If the audit log cannot be written, the operation is aborted and nothing is sent to Jira.
• An outcome record (success or error, with HTTP status on failure) is written after the request completes.

Each record includes a UTC timestamp, the actor (from JIRA_AUDIT_ACTOR, otherwise JIRA_USER_EMAIL or jira-pat), the operation, HTTP method, normalized origin, auth mode, and event. Resource paths, Cloud IDs, credentials, authorization headers, and query strings are excluded. Place this operationally sensitive file at an access-controlled path and retain it only as long as operations require. Audit failures after the request emit a warning without altering the result.

Credential Rotation

Atlassian Cloud API tokens have a selected lifetime of 1 to 365 days. Prefer a scoped token and set JIRA_CLOUD_TOKEN_MODE=scoped with JIRA_CLOUD_ID. Atlassian 3LO is not used because its token exchange requires a client secret. For Jira Data Center, create a bounded PAT through the Jira UI and rotate it out of band. The CLI does not issue PATs because the response would contain a new secret without a transactional, non-model-visible sink.

Credential Setup

Run this workflow when credentials are missing, incomplete, or failing. It is verification-first and non-destructive: it audits the current state, guides acquisition, writes only non-secret values, and validates connectivity after the user supplies the credential themselves.

Safety boundary

These rules are not adjustable by autonomy mode or user request.

• Never ask for, accept, or echo a token or PAT in chat. Display this warning whenever instructing the user to add one:

  Copy

  ⚠️ NEVER paste your API token or PAT into this chat.
     Tokens entered here are sent through the AI model and are not secure.
     Edit the credentials file directly in the editor instead.

• Never write a credential value. Non-secret values (base URL, email) may be written; the token line is a placeholder the user replaces in their editor.

• Never write credentials to a tracked file. ~/.jira.env lives in the user's home directory, outside any repository, so it cannot be accidentally committed. Do not write to .vscode/mcp.json or any repository file.

• Never modify a shell profile without explicit user confirmation.

• Never display a token value or any part of one, including a prefix. A credential variable is reported only as set or missing.

• Never run a command that prints an environment value. printenv | grep -i JIRA and any other filtered dump are prohibited: grep selects which lines print, it does not mask them, so a live token reaches standard output and enters the transcript. Use the set-or-missing probe in the Protocol below instead. Never include raw credential values, full request headers, or verbose or trace HTTP output in a response, even while troubleshooting.

• Send nothing over the network until the user explicitly confirms connectivity testing.

Terminal session isolation

The agent's terminal and the user's terminal are separate sessions, so an export in one is invisible to the other. The CLI loads supported Jira variables from ~/.jira.env in-process before it creates a client. It treats every value as data, never evaluates the file as shell code, and does not overwrite a variable already inherited by the terminal.

JIRA_DEBUG and JIRA_CONFIRM_WRITES are inherited-environment-only control variables. An unconfirmed write is rejected before the credential file is read, so that file cannot grant mutation authority.

On POSIX platforms, the CLI requires the file to be owned by the current user and accessible only by that owner. It opens the path without following symlinks and in non-blocking mode, then rejects non-regular files, oversized files, malformed assignments, and files with group or other permissions before loading values. Windows does not expose equivalent owner and mode checks through this path; protect the file with user-only ACLs. Errors name the configuration problem without printing credential values.

The environment file bridges the sessions:

1. On POSIX, create the file with owner-only permissions by running umask 077; touch ~/.jira.env; chmod 0600 ~/.jira.env. On Windows, create it under the user's profile and apply a user-only ACL. Fill in non-secret values and credential placeholders.
2. Resolve and display the absolute path so the user knows exactly which file to edit.
3. Open it with code ~/.jira.env.
4. The user replaces the placeholders and saves.
5. Run the Jira CLI command. The CLI reads the file directly; do not source it.

Protocol

1. Audit. The CLI loads supported values from ~/.jira.env, so inherited-process probes alone are not a complete setup audit. Check whether the file exists without reading or printing it. For inherited variables only, classify known names as set or missing without printing any value:

   Copy

    for v in JIRA_BASE_URL JIRA_USER_EMAIL JIRA_API_TOKEN JIRA_PAT JIRA_CLOUD_TOKEN_MODE JIRA_CLOUD_ID JIRA_AUDIT_LOG JIRA_AUDIT_ACTOR; do
     if printenv "$v" >/dev/null 2>&1; then echo "$v: set"; else echo "$v: missing"; fi
   done

printenv exits zero only when the inherited variable exists, and its output is discarded, so the classification never reveals a value. Use no modifying command during the audit. Let the Jira CLI's value-free validation identify variables still missing after in-process file loading. 2. Detect the platform. JIRA_PAT set indicates Server or Data Center. JIRA_USER_EMAIL with JIRA_API_TOKEN indicates Cloud. When mixed or ambiguous, ask which platform the user has rather than guessing, because the wrong choice produces an authentication failure that looks like a bad credential. 3. Validate what exists. Confirm JIRA_BASE_URL starts with https:// and flag a malformed value. Identify which required variables are missing for the detected platform. 4. Guide acquisition. Direct the user to their Atlassian account token page for Cloud, or their instance personal-access-token settings for Server or Data Center. Give the steps; never request the result. 5. Write the file. Create or update ~/.jira.env with non-secret values and credential placeholders, including a do-not-commit warning comment. 6. Validate connectivity. After the user confirms the credential is saved, run one read-only call. The CLI loads the file in-process. A 401 or 403 means the credential is wrong, expired, or revoked; a connection error means the base URL is wrong. 7. Summarize. Report what changed, what remains, and the set-or-missing state of each variable.

Completion

Setup is complete when every required variable for the detected platform is set, the base URL is well-formed, and one read-only call succeeds. Anything short of that is reported as incomplete with the specific remaining step, never as a qualified success.

Quick Start

Search for your current Jira issues and return a compact table:

python scripts/jira.py --fields key,fields.summary,fields.status.name search 'assignee = currentUser() ORDER BY updated DESC'

Inspect one issue with a compact field list:

python scripts/jira.py --fields key,fields.summary,fields.status.name,fields.assignee.displayName get PROJ-123

Create an issue from JSON piped through stdin:

cat <<'EOF' | python scripts/jira.py create
{
  "fields": {
    "project": { "key": "PROJ" },
    "summary": "Fix login timeout on mobile",
    "issuetype": { "name": "Bug" }
  }
}
EOF

Troubleshooting