{"id":17985,"plugin_id":"plugins_6a82e3d1df508191bfffcec222b18433","kind":"skill","collection_source":null,"comparison_source":null,"observed_at":"2026-09-30T23:14:32.904Z","digest":"d8015ee73ce53e7cf0bf11f1bbc4b6a1380a9c0d584638716f1710887598d872","against":null,"payload":{"description":"Update the work item after delivery - comment the PR link and a product-facing summary, and transition it to the team's review status. Supports Jira, Linear, GitHub Issues, and Azure DevOps via adapters. Use right after a PR is created for a story, or when the user asks to update/move a ticket.","included_files":[],"name":"issue-update","skill_md_contents":"---\nname: issue-update\ndescription: Update the work item after delivery - comment the PR link and a product-facing summary, and transition it to the team's review status. Supports Jira, Linear, GitHub Issues, and Azure DevOps via adapters. Use right after a PR is created for a story, or when the user asks to update/move a ticket.\n---\n\n# Issue Update\n\nClose the loop: after the code ships, the tracker must reflect it without anyone updating it by hand. This skill speaks to whichever tracker is configured in `.claude/dev-kit.json` (`tracker.type`).\n\n## Preconditions\n\n- `.claude/dev-kit.json` exists with a `tracker` block (otherwise run `dev-kit-setup` first).\n- The adapter's backend is authenticated (MCP connector authorized, or `gh`/`az` logged in) — otherwise tell the user how to authenticate and stop.\n- A PR URL and a product-facing summary of the delivered work are available from the delivery flow.\n\n## 1. Comment the delivery summary\n\n**Audience: product owners and other non-technical readers.** The comment explains what was delivered and why, in user terms — no test counts, coverage percentages, lint, or tooling jargon. All technical evidence lives in the PR, which is linked.\n\nPost a comment (via the adapter below) containing:\n\n```\nPull request: <PR URL>\n\nWhat was delivered:\n- <the new behavior, described as a user would experience it — one bullet per acceptance criterion addressed>\n\nDecisions taken:\n- <each meaningful decision or interpretation made during implementation, in plain language, with the reason>\n\nOut of scope / follow-ups:\n- <anything deliberately left out or worth a future ticket, or \"Nothing pending.\">\n```\n\nKeep it factual and grounded in what was actually built — never a template filled with assumptions. If an acceptance criterion was NOT met, say so here plainly.\n\n## 2. Ensure the item has a named owner\n\nEvery item carries a named owner: if it has no assignee, assign it to the current user. Agents act on a person's behalf — the item must always show whose behalf that is. (Skip only for trackers/flows where assignment is not applicable, and say so.)\n\n## 3. Transition to review\n\nMove the item to the team's review status. **Never hardcode transition/state IDs** — discover the available ones and pick the target named like \"In Review\" / \"Code Review\" / \"Review\"; if none matches, ask the user once and persist the choice under `tracker.reviewState` in `.claude/dev-kit.json`.\n\n## Adapters\n\n### Jira (`type: \"jira\"`)\n- Comment and assign via the **Atlassian MCP**.\n- Transition: fetch available transitions via the MCP (IDs vary per tenant), pick/persist the review transition under `tracker.reviewState`.\n\n### Linear (`type: \"linear\"`)\n- Comment and assign via the **Linear MCP**.\n- Transition: set the issue's workflow state to the team's review state (discover states via the MCP; persist the chosen state id).\n\n### GitHub Issues (`type: \"github\"`)\n- Comment: `gh issue comment <number> --repo <owner/name> --body-file -`.\n- Owner: `gh issue edit <number> --add-assignee @me` if unassigned.\n- \"Review status\": GitHub issues have no workflow states — apply the label the team uses (e.g. `in-review`) via `gh issue edit --add-label`, and/or move it in the project board if one is configured. Persist the label under `tracker.reviewState`.\n- **Verify both writes by read-back — never trust the exit code.** `gh issue edit` can fail while applying nothing (its project-fields prefetch trips on repos whose org ever used classic Projects), which is the worst shape for the step the story is not done without. After editing, run `gh issue view <number> --json assignees,labels` and confirm the assignee and label actually landed; on a miss, apply via REST instead — `gh api repos/<owner>/<repo>/issues/<number>/assignees -f \"assignees[]=<login>\"` / `gh api repos/<owner>/<repo>/issues/<number>/labels -f \"labels[]=<label>\"` — and report which path worked.\n\n### Azure DevOps (`type: \"azure\"`)\n- Comment and assign via the Azure DevOps MCP or REST / `az boards`.\n- Transition: set `System.State` to the team's review state (discover valid states for the work-item type; persist under `tracker.reviewState`).\n\n## 4. Report\n\nTell the user, explicitly and always covering all three: comment posted (link), **owner ensured (who — or why it could not be assigned)**, and transition applied (from → to). Anything that could not be done gets a reason — no step is ever skipped silently.\n\n## Failure handling\n\n- No matching review state (workflow differs): list the available ones and ask once; persist the answer.\n- No permission to transition: report it explicitly — do not silently skip.\n- The comment must be posted even if the transition fails.\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}