jira

name	jira
description	Comment on, create, and read Jira issues from the operator lane, using the Jira credential already granted to the sweep on thor (the credential never leaves that host — the script runs its API calls there over ssh). Verbs: `show <ISSUE>` reads summary, status and the last five comments with ids and author account ids; `comment <ISSUE> "<text>"` posts a comment and prints its id; `create --project KEY --summary "<text>" [--type Task] [--description "<text>"]` files an issue and prints its key. Everything it writes lands UNDER THE SYSTEM'S JIRA ACCOUNT, so the sweep filters those comments as self-echo by account id (`examples/pr-upkeep/pr_upkeep_jira.py` `jira_comment_is_self_echo`): this is the operator's own hand on the board — for creating proof tickets and reading what the sweep will see — NOT a way to produce a human's fact. The system's own board moves go through the jira bridge actor's allowlisted verbs, never through this. Use when the operator says "comment on SCRUM-5", "open a proof ticket", "what does SCRUM-N look like". For status reads and transitions use the sibling `jira-status` skill.
type	command

jira — operator-lane Jira comment / create / show

bash .claude/skills/jira/scripts/jira.sh show SCRUM-5
bash .claude/skills/jira/scripts/jira.sh comment SCRUM-5 "t13 proof: run 01M... finished"
bash .claude/skills/jira/scripts/jira.sh create --project SCRUM --summary "t13 proof ticket" \
  --type Task --description "Created from the operator lane."

What it does

• show <ISSUE> — prints the summary, status, issue type, the account id the credential resolves to (the id the sweep treats as self), and the last five comments with id, author accountId, display name and created time. A comment authored by that same account is tagged [self-echo], so the operator can read exactly what the sweep will and will not turn into a fact.
• comment <ISSUE> "<text>" — POST /rest/api/3/issue/{key}/comment with an ADF document body (blank-line separated paragraphs, single newlines as hard breaks); prints the new comment id.
• create --project KEY --summary "<text>" [--type Task] [--description "<text>"] — POST /rest/api/3/issue; prints the new key. --type defaults to Task.

Issue keys are validated locally against ^[A-Z][A-Z0-9_]*-[1-9][0-9]*$ and project keys against ^[A-Z][A-Z0-9_]*$ before any ssh; a refusal exits non-zero with error: / hint: lines on stderr. Results go to stdout only.

Status reads and transitions are deliberately not here — use jira-status (status <ISSUE> / move <ISSUE> "<target>").

Whose voice this is

Every write this skill makes is authored by the system's Jira account — the same identity the jira bridge actor and the sweep use. The sweep's jira_comment_is_self_echo (examples/pr-upkeep/pr_upkeep_jira.py) drops the newest comment when its author account id equals the configured bot account id, so a comment posted here is filtered as the system talking to itself. That is the correct behaviour, and it is why this skill is not a way to manufacture a human's answer: an operator who wants their words to become an engine fact must speak on the board as a distinct identity (issue #197, gap 3). What this skill is good for is the operator's own hand-work — creating a proof ticket, seeding a description, reading state.

The system's own board moves are not this either: workflow runs comment and transition through the jira bridge actor (adapters/jira), whose verbs are bridge-allowlisted to one project prefix and named transitions (decision c19). This skill does not widen or bypass that custody; it is the same act as the operator typing on the board, scripted.

Custody

Identical to jira-status: the Jira credential pair lives in ~/.culture-nodes/runner-secrets.env on thor (granted to the sweep; reuse approved by the operator 2026-08-18). The script sshes to thor and performs the REST calls there inside a quoted python heredoc; the pair is read from that file on that host and never appears on the local machine, in argv, or in output. JIRA_STATUS_HOST / JIRA_STATUS_SITE override the host and site exactly as they do for jira-status.

Why it exists

Issue #197 measured two gaps on the SCRUM-3 live probe: ticket creation had no lane verb (gap 2 — creating SCRUM-3 needed an ad-hoc widening of the jira-status ssh custody), and the operator's board voice is filtered as self-echo (gap 3). The t8 proof ticket SCRUM-5 for the #230 closeout was then created the same way — an ad-hoc script scp'd to thor — which is a counted hand-turn. This skill is the declared, tested custody for that create/comment/read work, so the next proof ticket is a verb and not a widening. Gap 3 stays open by design: this skill names the self-echo, it does not paper over it.