publish-review

Publish a /code-review report that already ran in this conversation. The finished two-axis report is the input. Assign each finding to an inline suggestion or the summary, approve the complete publication, then post it.

Use the target resolution and drafting rules in publish-message when it is installed. This skill handles publication itself so that the summary and inline suggestions receive one approval before either becomes visible.

Process

1. Split the findings

For every finding across both axes:

• Inline suggestion, GitHub/GitLab only: the fix is the finding, small, unambiguous, and scoped to one hunk (a rename, a dropped null check, a swapped condition). Something a reviewer would one-click-accept.
• Summary: everything else: judgement calls (the Fowler smells, "possible X"), anything spanning more than one hunk or file, anything on Jira (no diff to suggest against), and any GitHub/GitLab finding you aren't confident enough in to propose as a literal replacement.

When in doubt, summary. A wrong suggested change is worse than a described one: the reader can act on a wrong description by disagreeing with it, but a wrong suggestion invites a wrong one-click accept. Done when every finding from the report sits in exactly one of the two buckets.

2. Draft the complete publication

Resolve the target and posting mechanism, preferring an available tracker MCP tool over a CLI. Read the target's title and description to match its language. Draft a summary with one short paragraph per summary finding, each leading with the reason rather than restating the finding. When there are inline suggestions, end with + N inline suggestions on the diff, where N is the number drafted and ready to post.