Restrict allowedTools to prevent approvals and broad API access

[francoisferrand]

Replace the broad "Bash(gh api )" allow rule with three narrow
patterns that match only the endpoints the review skills actually use:
pulls//comments (inline comments), issues/*/comments (summary
comments), and check-runs (check run create/update).

The broad rule allowed Claude to POST to .../pulls//reviews, which
is the approval endpoint. Narrowing it closes that path while still
supporting both review styles (inline + check run, inline + summary
comment) across consuming repos.

Issue: SOR-238

[claude]

LGTM

The change correctly narrows Bash(gh api *) to three specific endpoint patterns (*pulls/*/comments*, *issues/*/comments*, *check-runs*), closing the path to the pulls/<n>/reviews approval endpoint while preserving all functionality used by the review skill (inline comments via the pulls comments API, summary comments via gh pr comment, and check run creation/updates).

Review by Claude Code

[claude]

• The gh api allowedTools patterns are inconsistent: repos/*/pulls/*/comments* and repos/*/check-runs* lack the leading wildcard that *issues/*/comments* has. Without it, commands that include CLI flags (-X POST -H "Accept:...") between gh api and the URL won't match. Add a leading * to all three patterns.
  - Change repos/*/pulls/*/comments* → *pulls/*/comments*
  - Change repos/*/check-runs* → *check-runs*
  - The skill definition (.claude/skills/review-pr/SKILL.md line 6) still lists Bash(gh api *) in its allowed-tools. Consider narrowing it to match the workflow's patterns for defense in depth.
  
  Review by Claude Code

[SylvainSenechal]

Claude's comment looks legit 🤔
Edit: maybe not always problematic, it depends how claude will use the cli, but I guess safer to add the wildcard

[claude]

LGTM — good security tightening.

One optional follow-up:
- .claude/skills/review-pr/SKILL.md line 6 still declares the broad Bash(gh api *) in its allowed-tools frontmatter. The CLI --allowedTools flag is the enforcement point so this isn't a security gap, but updating the skill declaration to use the same three narrow patterns would keep them consistent.

Review by Claude Code

[francoisferrand]

Claude's comment looks legit 🤔 Edit: maybe not always problematic, it depends how claude will use the cli, but I guess safer to add the wildcard

It is somewhat legit, but not for the right reasons: permissions should actually be restricted, which does not really hinder functionality as the command can be written gh api repos/[...]/coments, but really enforces the security.

The problem is really that this could break existing SKILLS accross many repos...