/assess-release

name: "assess-release"
description: "Assess whether a release, fix version or milestone is ready to ship using Teamwork Graph across Jira, Projects, Confluence, connected code, deployments and chat. Answers in the conversation first with a rule-based verdict (Ready, Ready with conditions or Not ready), linked blockers, readiness by area, open work, decisions and recorded owners, and evidence gaps. Offers the existing HTML report on request and publication only when Atlassian Artifacts is available and requested. Use for release readiness, a go or no-go view, or /assess-release. For dependencies alone, use dependency-map. For goal health, use status-check. For shipped changes, use release-notes."

Assess release

Give a release driver, engineering manager or team lead an answer in the conversation that they can read in three minutes before a go or no-go call: whether the release is ready to ship, what's stopping it, what each area (work, code, testing, dependencies, rollout) shows, what needs deciding and who holds each decision, and what couldn't be checked.

A release page in Jira counts issues by status. The value of this skill is the judgement the release page, the board and the pull request list can't make on their own: which open items actually stop the ship, whether "done" work has merged and deployed code behind it, whether the testing and rollout work exists and is finished, and which dependencies on other teams are still open, all checked against linked records rather than titles.

Load the `teamwork-graph-context` skill first and follow it for gathering context, labelling sources, keeping sensitive content out and optional publishing. Its section "What the graph doesn't tell you" matters most here. This file adds what's specific to a release. An optional HTML report is built by `render.py` in this folder (Step 9), which applies the `atlassian-design` skill for you: load that skill only if the script can't run.

This skill selects "Answer-first delivery" in `teamwork-graph-context`: gather and assess, answer in the conversation, then ask whether the user wants an HTML report. Do not write report data, run a renderer or create an artifact unless the user requests an export, HTML report or publication. Use the existing report layout only for that optional export. Offer Atlassian Artifacts publication only after confirming availability; exporting does not authorise publishing.

What this skill will and won't do

• **It assesses one release now.** The verdict says whether the release could ship today on the evidence in its records. It never forecasts a ship date, a completion date or a velocity. The release date appears only as a record states it, with its moves if a record shows them.
• **A blocker needs a record.** A Blocked status, a flag, an open upstream issue link whose direction was read from Jira, or a record (a comment, an update, a decision page, a message) that says the release or one of its items is blocked. Never a title ("Coordinate with the Platform team"), and never a priority field alone.
• **A decision's holder needs a record.** The release's driver or approvers, a decision page's driver or approver, or an owner a record names. Otherwise "No owner recorded". The skill suggests decisions; it never assigns anyone.
• **Gaps are results.** Pull requests that couldn't be read, keys on another site, missing test records and checks that weren't run are shown in their area and in the footer, and never counted as done.

Connectors

• **Needed:** Jira, for the release's work and its issue links. If Jira isn't in the site's `products` list (see "Atlassian apps on the site" in `teamwork-graph-context`), there's no release to assess: say so and stop.
• **Helpful, from Atlassian:** Projects, for the project behind the release, its target date and its dependencies. Confluence, for the spec, test plan, rollout plan and decision pages. Bitbucket, for pull requests and deployments linked to the work. Compass, for the services the release touches. Skip the calls for an app that isn't on the site, and list it in the footer as "Not available on this site".
• **Helpful, from other tools:** GitHub or GitLab, for pull requests linked to the work. A deployment tool connected to the graph (Spinnaker, Bitbucket Pipelines), for how far each change has rolled out. Slack or Teams, for blockers and go or no-go discussion that never reached Jira. Google Drive or SharePoint, for specs and rollout plans kept outside Confluence.
• **Vendor connectors,** as `teamwork-graph-context` describes. Teamwork Graph comes first, and a connector fills only a known gap:
• GitHub or GitLab, to read a pull request's state and reviews when the graph returns it with `raw: {}`.
• Slack or Teams, to read a blocker thread in full when search returns only a snippet.

Budget

A release can hold a hundred items, so every step states its cap. In total, unless the user asks for a deeper pass:

| Tool | Cap | Where | | --- | --- | --- | | `getJiraProjectVersions` | 2 | Step 1: the version, and one name lookup in its project | | `getJiraProjectVersionRelatedWork` | 1 | Step 1 | | JQL | 10 | 1 in Step 1 (name lookup), 4 in Step 2 (the release's items, flagged items, epics' children, unversioned siblings count), 1 in Step 3 (open items with links), up to 3 in Step 3 (other projects' upstream items, one per project key), 1 in Step 6 (open work shown) | | `getJiraIssue` | 5 | Step 3: Blocked or flagged items, for the reason | | `getGraphContext` | 16 | 3 in Step 2 (the version, and up to 2 epics for the project), up to 8 in Step 4 (pull requests), up to 5 in Step 5 (deployments, pages included) | | `getGraphObject` | 2 batches | Step 4 (pull requests), Step 5 (deployments) | | `searchProjects`, `getProject` | 1 (only as a fallback) and 1 | Step 2 | | `search` | 3 | Step 5: 1 Confluence (spec, test or rollout docs), 2 third-party (blockers, go or no-go) | | CQL (`searchConfluence`) | 2 | Step 5: the space f