Consolidated accessibility skill entrypoint for WCAG 2.2, ARIA Authoring Practices, cognitive accessibility, Section 508, EN 301 549, design intent verification, and the Accessibility Planner workflow.
日本語の概要は準備中です。原文の説明を表示しています。
Jira issue workflows for search, issue updates, transitions, comments, field discovery, and interactive credential setup via the Jira REST API. Use when you need to configure Jira access, search with JQL, inspect an issue, create or update work items, move an issue between statuses, post comments, or discover required fields for issue creation.
インストール方法を見るインストールする前に、エージェントに与えられる指示の中身を確認できます。
This skill provides a Python CLI for common Jira REST API workflows:
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.
Set the required environment variables before running the script.
| Platform | Runtime |
|---|---|
| Cross-platform | Python 3.11+ |
| Variable | When required | Purpose |
|---|---|---|
JIRA_BASE_URL | Always | Jira base URL, for example https://company.atlassian.net |
JIRA_USER_EMAIL | Jira Cloud | Account email used for basic authentication |
JIRA_API_TOKEN | Jira Cloud | API token paired with the Jira Cloud email |
JIRA_PAT | Jira Server or Data Center | Personal access token used for bearer authentication |
JIRA_CLOUD_TOKEN_MODE | Jira Cloud optional | unscoped (default) or scoped |
JIRA_CLOUD_ID | Scoped Jira Cloud token | Atlassian Cloud resource identifier |
Authentication is selected automatically:
JIRA_PAT is set, the script uses bearer authentication for Jira Server or Data Center.JIRA_USER_EMAIL and JIRA_API_TOKEN for Jira Cloud.https://api.atlassian.com/ex/jira/{cloudId};
mixed Cloud and Data Center credentials fail closed.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.
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.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.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.
| Variable | When required | Purpose |
|---|---|---|
JIRA_AUDIT_LOG | Optional | Path to a JSON Lines audit log. When set, every request is audited (see Audit Logging). |
JIRA_AUDIT_ACTOR | Optional | Overrides the recorded actor identity (for example, a CI service principal). |
JIRA_DEBUG | Optional | Inherited environment only. Set to 1 to print a redacted traceback on failure. Never disables redaction. |
JIRA_ALLOW_INSECURE | Optional | Set to 1 to permit explicit loopback HTTP development endpoints only. |
JIRA_CONFIRM_WRITES | Optional | Inherited environment only. Set to 1 to satisfy the write confirmation gate without --confirm or --yes. |
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:
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.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.
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.
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.
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:
⚠️ 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.
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:
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.code ~/.jira.env.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:
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.
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.
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
| Command or option | Syntax | Default | Description |
|---|---|---|---|
search | python scripts/jira.py search '<jql>' [max_results] | max_results = 50 | Search for issues with JQL |
get | python scripts/jira.py get <ISSUE-KEY> | None | Get one issue |
create | python scripts/jira.py create '<json>' | Reads stdin if omitted | Create an issue from JSON |
update | python scripts/jira.py update <ISSUE-KEY> '<json>' | Reads stdin if omitted | Update an issue from JSON |
transition | python scripts/jira.py transition <ISSUE-KEY> '<name-or-id>' | None | Move an issue to another workflow state |
comment | python scripts/jira.py comment <ISSUE-KEY> '<body>' | Reads stdin if omitted | Add a comment to an issue |
comments | python scripts/jira.py comments <ISSUE-KEY> [ISSUE-KEY ...] | None | List comments across one or more issues |
fields | python scripts/jira.py fields <PROJECT-KEY> [issue-type-id] | None | Discover issue types or required create fields |
--fields | --fields key,fields.summary,... | None | Extract selected fields from search, get, and comments output |
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
python scripts/jira.py --fields key,fields.summary,fields.priority.name,fields.status.name get PROJ-123
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"]
}
}'
python scripts/jira.py update PROJ-123 '{
"fields": {
"summary": "Updated summary",
"priority": { "name": "High" },
"labels": ["backend", "urgent"]
}
}'
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.
python scripts/jira.py comment PROJ-123 'PR #42 addresses this issue.'
printf 'Deployed to staging.\n' | python scripts/jira.py comment PROJ-123
python scripts/jira.py --fields _issue,author.displayName,created,body comments PROJ-123 PROJ-456
| Symptom | Likely cause | Resolution |
|---|---|---|
JIRA_BASE_URL is not set | Base URL is missing | Export JIRA_BASE_URL in the current shell |
| Authentication error | Wrong token or missing auth variables | Verify JIRA_PAT for Jira Server or Data Center, or verify JIRA_USER_EMAIL and JIRA_API_TOKEN for Jira Cloud |
Invalid issue key | Issue key format is malformed | Use keys in the form PROJ-123 |
| Transition not found | The requested workflow transition is unavailable | Re-run the command with the transition name returned in the error output |
| JSON payload error | Invalid JSON was passed to create or update | Validate the payload and retry with well-formed JSON |
| Network connection error | Jira instance URL is unreachable | Verify the base URL and local network access |
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
Consolidated accessibility skill entrypoint for WCAG 2.2, ARIA Authoring Practices, cognitive accessibility, Section 508, EN 301 549, design intent verification, and the Accessibility Planner workflow.
日本語の概要は準備中です。原文の説明を表示しています。
Build, refresh, report, or probe an accessibility coverage matrix across criteria, surfaces, and evidence methods. Use when assessing coverage with the accessibility runtime harness and generated evidence bundle.
日本語の概要は準備中です。原文の説明を表示しています。
Authoring skill for Architecture Decision Records (ADRs) supporting capture, from-planner-handoff, and adopt-template entry modes with selectable Y-Statement or MADR v4.0.0 output templates, supersession lineage, and ASR trigger evaluation.
日本語の概要は準備中です。原文の説明を表示しています。
Authoring conventions for exploratory data analysis notebooks and analytical dashboards, covering section sequence, visualization selection, scale thresholds, caching and state, and dashboard validation budgets. Use when composing or reviewing an EDA notebook, an analytical dashboard, or a dashboard test pass.
日本語の概要は準備中です。原文の説明を表示しています。
Architecture diagram authoring for cloud infrastructure and declared data catalogs. Use when rendering Azure IaC or DS_CATALOG_V1 relationships as caller-selected ASCII or Mermaid diagrams.
日本語の概要は準備中です。原文の説明を表示しています。
Create a durable Architecture Review Record from a confirmed System Architecture Reviewer scope, evidence, pillar analysis, trade-offs, and dispositions
日本語の概要は準備中です。原文の説明を表示しています。