feat(skills): tighten review-pr, manage-labels, prepare-release bodies

PDE C-arm sweep against the 27-skill catalog (PR #2465 head, d116a4c)
flagged three body-class gaps where the right skill loaded but the
instructions did not carry the model through:

- T21 (3 inline review comments) burned 112 turns / 241 tool calls
  fumbling the pending-review sequence. Add an explicit
  pull_request_review_write create -> add_pull_request_review_comment x N
  -> pull_request_review_write submit_pending recipe to review-pr.

- T28 (create + apply a new label) thrashed verifying label state by
  re-listing. Append a verify-then-stop instruction to manage-labels
  pointing at get_label, and add get_label to its allowedTools so the
  recipe is actually callable from within the skill.

- T22 (release readiness inputs) thrashed across many tools. Replace
  prepare-release's flat workflow with a 6-step sequence that orders
  get_latest_release -> list_tags fallback -> list_commits ->
  search_pull_requests -> categorise -> draft, plus an orphan-commit
  callout.

No new skills, no toolsnap impact.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Author: asdfg-zxcvb

pkg/github/skill_resources.go

@@ -145,7 +145,7 @@ func skillReviewPR() skillDefinition {
 			"resolve_review_thread",
 			"unresolve_review_thread",
 		},
-		body: "# Review Pull Request\n\nYou are reviewing someone else's PR. Be thorough, constructive, and decisive.\n\n## Available Tools\n- `pull_request_read` — get diff, files, status, review comments, check runs\n- `get_file_contents` / `search_code` — read context beyond the diff\n- `create_pull_request_review` — start a pending review\n- `add_pull_request_review_comment` / `add_comment_to_pending_review` — add line comments\n- `submit_pending_pull_request_review` — submit with verdict\n- `delete_pending_pull_request_review` — discard pending review\n- `add_reply_to_pull_request_comment` — reply to existing comments\n- `resolve_review_thread` / `unresolve_review_thread` — manage threads\n\n## Workflow\n1. Read PR description and linked issues to understand intent.\n2. Check CI status with `pull_request_read` (method: get_status).\n3. Read the full diff with `pull_request_read` (method: get_diff).\n4. Create a pending review, add all comments, then submit once with a verdict.\n5. Always submit with approve, request_changes, or comment — don't leave orphan comments.\n\n## Anti-Patterns\n- Don't approve with failing CI.\n- Don't leave comments without submitting a review — pending reviews are invisible to the author.\n- Don't resolve threads you didn't start — that's the author's responsibility.\n- Read ALL changed files before commenting — your concern may be addressed elsewhere in the diff.\n",
+		body: "# Review Pull Request\n\nYou are reviewing someone else's PR. Be thorough, constructive, and decisive.\n\n## Available Tools\n- `pull_request_read` — get diff, files, status, review comments, check runs\n- `get_file_contents` / `search_code` — read context beyond the diff\n- `create_pull_request_review` — start a pending review\n- `add_pull_request_review_comment` / `add_comment_to_pending_review` — add line comments\n- `submit_pending_pull_request_review` — submit with verdict\n- `delete_pending_pull_request_review` — discard pending review\n- `add_reply_to_pull_request_comment` — reply to existing comments\n- `resolve_review_thread` / `unresolve_review_thread` — manage threads\n\n## Workflow\n1. Read PR description and linked issues to understand intent.\n2. Check CI status with `pull_request_read` (method: get_status).\n3. Read the full diff with `pull_request_read` (method: get_diff).\n4. Create a pending review, add all comments, then submit once with a verdict.\n5. Always submit with approve, request_changes, or comment — don't leave orphan comments.\n\n## Pending-review flow (multi-comment)\nFor 2+ inline comments on the same PR, group them into a single pending review:\n\n1. Call `pull_request_review_write` with `method: create` and **omit `event`**. This opens a pending review that you own.\n2. Call `add_pull_request_review_comment` once per inline comment. Each call attaches to the pending review automatically.\n3. Call `pull_request_review_write` with `method: submit_pending` and the verdict (`event: APPROVE | REQUEST_CHANGES | COMMENT`). All comments post atomically.\n\nDon't call `add_pull_request_review_comment` repeatedly without first opening the pending review — orphan comments stay invisible to the author until a review is submitted.\n\n## Anti-Patterns\n- Don't approve with failing CI.\n- Don't leave comments without submitting a review — pending reviews are invisible to the author.\n- Don't resolve threads you didn't start — that's the author's responsibility.\n- Read ALL changed files before commenting — your concern may be addressed elsewhere in the diff.\n",
 	}
 }
 
@@ -379,7 +379,7 @@ func skillPrepareRelease() skillDefinition {
 			"list_commits",
 			"search_pull_requests",
 		},
-		body: "# Prepare Release\n\nCompile release notes from merged PRs and commits since the last release.\n\n## Available Tools\n- `list_releases` / `get_latest_release` / `get_release_by_tag` — browse releases\n- `list_tags` / `get_tag` — version tags\n- `list_commits` — commits since last release\n- `search_pull_requests` — find merged PRs in the range\n\n## Workflow\n1. `get_latest_release` to find the last version tag.\n2. `list_commits` since that tag to see all changes.\n3. `search_pull_requests` for merged PRs in the range — PR descriptions are richer than commits.\n4. Group changes: breaking changes, features, bug fixes, docs.\n5. Link PR numbers in release notes for traceability.\n\nUse PR titles and labels for categorization — commit messages alone are often too terse.\n",
+		body: "# Prepare Release\n\nCompile release notes from merged PRs and commits since the last release.\n\n## Available Tools\n- `list_releases` / `get_latest_release` / `get_release_by_tag` — browse releases\n- `list_tags` / `get_tag` — version tags\n- `list_commits` — commits since last release\n- `search_pull_requests` — find merged PRs in the range\n\n## Workflow\n1. `get_latest_release` to find the previous version tag.\n2. `list_tags` if no published release exists yet — fall back to the most recent tag.\n3. `list_commits` since that tag, paginated, to enumerate raw changes.\n4. `search_pull_requests` with `is:pr is:merged base:<branch> merged:>=<tag-date>` to find merged PRs in the window — PR titles and labels classify better than commit subjects.\n5. Group by label/path: breaking changes first, then features, fixes, docs, chore.\n6. Draft notes with PR numbers linked for traceability; flag any commits that don't map to a PR (often direct-to-main pushes).\n\nUse PR titles and labels for categorization — commit messages alone are often too terse.\n",
 	}
 }
 
@@ -409,9 +409,10 @@ func skillManageLabels() skillDefinition {
 			"list_labels",
 			"list_label",
 			"label_write",
+			"get_label",
 			"search_issues",
 		},
-		body: "# Manage Labels\n\nCreate a consistent, useful label system for a repository.\n\n## Available Tools\n- `list_labels` / `list_label` — browse existing labels\n- `label_write` — create, update, or delete labels\n- `search_issues` — check label usage before deleting\n\n## Best Practices\n- Use prefixed names: type:bug, type:feature, priority:high, status:needs-triage.\n- Use consistent colors within categories (all type: labels same color family).\n- Write helpful descriptions — they appear in the label picker.\n- Check label usage with `search_issues` before deleting or renaming.\n- Aim for 15-25 labels total. Too many means none get used consistently.\n",
+		body: "# Manage Labels\n\nCreate a consistent, useful label system for a repository.\n\n## Available Tools\n- `list_labels` / `list_label` — browse existing labels\n- `label_write` — create, update, or delete labels\n- `search_issues` — check label usage before deleting\n\n## Best Practices\n- Use prefixed names: type:bug, type:feature, priority:high, status:needs-triage.\n- Use consistent colors within categories (all type: labels same color family).\n- Write helpful descriptions — they appear in the label picker.\n- Check label usage with `search_issues` before deleting or renaming.\n- Aim for 15-25 labels total. Too many means none get used consistently.\n- After `label_write`, call `get_label` once to confirm the label exists with the intended color and description, then stop. Don't re-call `list_labels` to verify — one targeted read is enough.\n",
 	}
 }