fix(skills): wrap add_issue_comment in review-pr for PR conversation comments

The Tier 1 review-pr description broadening promised "posting a
conversation-level comment on a PR" but did not gate the tool that
backs that workflow. PR conversation comments use add_issue_comment
(PRs are issues at the API level), which until now was only present
in the triage-issues skill. Without it gated on review-pr, the model
loads review-pr for the conversation-comment framing but cannot
actually post the comment.

Add add_issue_comment to review-pr.allowedTools, surface it in the
body's Available Tools list, and add a short "Conversation comments
vs review comments" subsection so the model picks the right tool
for line-anchored vs top-level comments.

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

Author: asdfg-zxcvb

pkg/github/skill_resources.go

@@ -143,10 +143,11 @@ func skillReviewPR() skillDefinition {
 			"submit_pending_pull_request_review",
 			"delete_pending_pull_request_review",
 			"add_reply_to_pull_request_comment",
+			"add_issue_comment",
 			"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## 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",
+		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- `add_issue_comment` — post a conversation-level comment on the PR (PRs are issues at the API level)\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## Conversation comments vs review comments\nUse `add_issue_comment` for top-level conversation comments on a PR (general questions, status updates, links to related work). Use `add_pull_request_review_comment` only for line-anchored comments inside a review. Don't open a pending review just to leave a single non-line-anchored note.\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",
 	}
 }