ticket-reportlisted

Close the loop on a Jira ticket: post exactly one comment saying what was planned, what was built per requirement with evidence, and — the section that matters — what the ticket asked for that was NOT built and why; then move the ticket to the status the evidence supports. Partial coverage never lands in Done, ever: a ticket marked Done with unbuilt requirements removes the one signal a human needs. Transitions are discovered from the live workflow rather than assumed, rejected when they need fields nobody can legitimately fill, and skipped silently when the issue is already there. Both writes are idempotent — a resumed or re-run loop reports "already reported" instead of spamming the ticket. Runs in audit mode against an MR it didn't build, evidencing each requirement against the real diff. Use when: a ticket's MR has merged, "update the Jira ticket", closing out PROJ-123, or as the final stage of /ship-feature PROJ-123.
ohyesgocool/feature-loop · ★ 0 · AI & Automation · score 70

Install: claude install-skill ohyesgocool/feature-loop

# Ticket Report Write the outcome back to the ticket: **one comment**, then **one transition**. This is the only skill in the loop that writes to Jira. The comment's job is not to announce success. It is to tell the person who filed the ticket what they are actually getting — including the parts they asked for that they are not getting, and why. That section is the deliverable. > **Git first, Jira last, always.** Never write to the ticket before the git side is verified. > "Merged" is claimed only after the MR's `state` reads `merged`. If the user provided arguments: `$ARGUMENTS` — the issue key, optionally `--mr !N` and `--dry-run`. With no key, take it from the loop state or the branch name. --- ## Process ### Step 1: Bind the Jira tools Same discovery as `/ticket-intake` — list the session's MCP tools and bind by name, case-insensitively; read each tool's own parameter schema before calling it. | Role | Expected name | |---|---| | issue | `getJiraIssue` | | comment | `addCommentToJiraIssue` | | transitions | `getTransitionsForJiraIssue` | | transition | `transitionJiraIssue` | If **comment** or **transitions** fails to bind, stop and print the setup line — never improvise a REST call, a CLI, or a browser. If the write tools bound but the *account* turns out to lack permission, report the API error **verbatim**; a permission error names the exact grant that's missing, and paraphrasing it into "couldn't update the ticket" throws that away. ### Step 2: Establish th