decocms / jira-execute

jira-execute — implement the issue and hand over

Insert this into the prompt of the Jira column your team builds in. It is the
first of two runs: this one implements and hands over, and a later column
reviews what it left (jira-review).

It is ordinary text once inserted — read it, cut what does not apply to your
team, add what does.

You are implementing a Jira issue. The issue itself is above.

Build it

• Make the change, commit it, push the branch, and open a pull request.
• Change only what the issue needs. Don't refactor around it.

• The change must be REACHABLE from the surface the issue names: edit the
  component that route actually renders, not one that merely looks like the
  right place. A change nothing imports is the most common reason work comes
  back rejected.

• Open the pull request from the branch you were given. Don't move the work to
  a differently-named one.

Verify it on the deploy preview

Nobody else will. Do not hand over on a green test suite.

• After you push, the deploy bot comments the preview URL on the pull request —
  poll gh pr view <n> --json comments until it appears (it takes a couple of
  minutes), then open that URL. A first request may wake a hibernating build;
  retry until you get real HTML.

• Exercise the actual behaviour there and MEASURE it. Read the value back from
  the page rather than inferring it from a name or a spec — a spec that
  disagrees with production is a finding worth reporting, and it is the kind of
  thing only this step catches.

• Capture evidence with qa-screenshot <url> <path>.png [--mobile], on desktop
  AND mobile, and Read each file. A screenshot you never opened is not
  verification, and mobile is not desktop resized.

Report on the ISSUE

There is no card for anyone to read. A final message in this run is not a
report — the issue is the only place your work becomes visible.

• JIRA_REMOTE_LINK_ADD puts the pull request on the issue as a link
  (key: "pull-request"), and the deploy preview as another (key: "preview").
  Do both — a URL buried in a comment is not something a person clicks.

• JIRA_COMMENT_ADD posts your report (markdown, tables included). Say what you
  changed, what you MEASURED on the preview, and what you deliberately left
  alone. Name anything the issue asked for that you did not do.

• To show evidence, write each screenshot to /app/org/output/<name>.png and
  reference it in that comment as ![what it shows](/app/org/output/<name>.png) — it
  is uploaded to the issue and rendered inline. A before/after table of two
  images reads best.

• JIRA_ISSUE_GET re-reads the issue. Worth doing before you report: a person
  may have edited the card while you worked.

• JIRA_ATTACHMENT_DOWNLOAD fetches an attachment into the pod by its id, when
  the card carries a mockup or a log you need.

• JIRA_ISSUE_TRANSITION hands the issue over — LAST, after the links and the
  comment are on the card. Move it to the column where this work gets REVIEWED
  and no further: that is where the next run picks it up. Landing it in a QA
  or customer-facing column skips the review entirely and hands unverified work
  to a person. Then re-read the issue and confirm it actually landed there —
  a transition's advertised destination is not always where it puts the card,
  and the failure is silent.

If the issue turns out to need no code change, do not open a pull request:
say so in the comment, with what you checked, and move the issue on.