fix: trigger review skill failed to ack

[Vui-Chee]

No description provided.

[claude]

🔴 github.event.issue.number on lines 90 and 95 is undefined for pull_request_review_comment events — the PR number lives at github.event.pull_request.number for that event type. Since claude-review triggers on both issue_comment and pull_request_review_comment, an inline review comment will produce an empty PR number, breaking both the prompt context and the gh pr comment command. Use ${{ github.event.issue.number || github.event.pull_request.number }} in both places.

Extended reasoning...

Bug Description

The claude-review job triggers on two event types (lines 41-42):

• issue_comment — where the event payload includes github.event.issue.number
• pull_request_review_comment — where the event payload does not include an issue object; the PR number is at github.event.pull_request.number

However, the workflow uses github.event.issue.number in two places:

• Line 90 (prompt): PR NUMBER: ${{ github.event.issue.number }}
• Line 95 (command): gh pr comment ${{ github.event.issue.number }} --body "<your review>"

Step-by-step proof

1. A user posts an inline review comment on a PR containing @review.
2. GitHub fires a pull_request_review_comment event.
3. The claude-review job matches the if condition on line 42.
4. The job reaches the "Run Claude Review" step.
5. github.event.issue is undefined for this event type, so github.event.issue.number evaluates to an empty string.
6. The prompt becomes PR NUMBER: (empty), giving Claude no context about which PR to review.
7. The gh pr comment command becomes gh pr comment --body "..." (missing argument), which will fail.

Impact

When triggered by a PR review comment (as opposed to a regular issue comment on a PR), the entire review workflow silently breaks: Claude receives no PR number in its prompt and cannot post the review summary back because gh pr comment fails without a valid PR number argument.

Fix

Replace both occurrences of github.event.issue.number (lines 90 and 95) with:

${{ github.event.issue.number || github.event.pull_request.number }}

This falls back to github.event.pull_request.number when github.event.issue.number is not present, covering both event types correctly.

[claude]

🔴 The "Acknowledge trigger" step always calls reactions.createForIssueComment(), but for pull_request_review_comment events the correct API is reactions.createForPullRequestReviewComment() — this will 404 on inline review comments. Additionally, the ternary on lines 59-60 is dead code (both branches return context.payload.comment.id). The fix should branch on isReviewComment to call the appropriate reactions API method.

Extended reasoning...

What the bug is

The new "Acknowledge trigger" step (lines 54-60) computes isReviewComment to detect whether the event is a pull_request_review_comment, but then unconditionally calls github.rest.reactions.createForIssueComment(). This is the wrong GitHub API endpoint for PR review comments (inline code comments). The GitHub REST API has two separate endpoints:

• Issue comments: POST /repos/{owner}/{repo}/issues/comments/{comment_id}/reactions → reactions.createForIssueComment()
• PR review comments: POST /repos/{owner}/{repo}/pulls/comments/{comment_id}/reactions → reactions.createForPullRequestReviewComment()

These operate on different resource namespaces. A review comment ID passed to the issue-comment endpoint will return a 404 Not Found.

The dead ternary

On lines 59-60, the ternary expression is:

comment_id: isReviewComment
  ? context.payload.comment.id
  : context.payload.comment.id,

Both branches are identical — this is a copy-paste error. The isReviewComment boolean is computed but never influences behavior. While context.payload.comment.id happens to be the correct payload path for both event types, the ternary is misleading dead code that suggests branching was intended but never completed.

Step-by-step proof

1. A user posts an inline review comment on a PR containing @review.
2. The pull_request_review_comment event fires, matching the claude-review job condition (line 43).
3. The "Acknowledge trigger" step runs. isReviewComment is set to true.
4. The code calls github.rest.reactions.createForIssueComment() with the review comment’s ID.
5. GitHub looks up /repos/{owner}/{repo}/issues/comments/{comment_id}/reactions — but the comment ID belongs to a pull request review comment, not an issue comment.
6. GitHub returns 404 Not Found, and the step fails. The eyes reaction is never added.

Impact

Whenever the review workflow is triggered by an inline PR review comment (as opposed to a top-level issue comment), the acknowledge step will fail with a 404. This defeats the purpose of the acknowledgment — the user gets no visual feedback that their review request was received. Depending on the workflow’s continue-on-error configuration (not set here), this could also cause the entire job to fail, preventing the review from running at all.

How to fix

Branch on isReviewComment to call the correct API method:

const isReviewComment = context.eventName === pull_request_review_comment;
const params = {
  owner: context.repo.owner,
  repo: context.repo.repo,
  comment_id: context.payload.comment.id,
  content: eyes
};
if (isReviewComment) {
  await github.rest.reactions.createForPullRequestReviewComment(params);
} else {
  await github.rest.reactions.createForIssueComment(params);
}

This also eliminates the dead ternary, since comment_id no longer needs conditional logic (the payload path is the same for both event types — only the API method differs).

[Vui-Chee]

Prevent name clashes with default skills.