About identify-reviewer
A skill for identifying the current reviewer before a code review, using GitHub and local Git identity data. It helps review workflows attribute comments, commits, and approval status accurately, while allowing review to continue if identity checks are unavailable.
Key features
- 01Detects GitHub and local Git identities
- 02Falls back to Git config when needed
- 03Attributes prior comments and commits
- 04Checks prior review status
- 05Distinguishes self-review
Use cases
- 01Preparing to review a pull request
- 02Attributing a reviewer’s earlier comments
- 03Summarizing commits by the local user
- 04Adjusting tone when reviewing one’s own pull request
Install
Copy the command and run it in a terminal.
npx skills add https:/ / github.com/ cloudflare/ workerd --skill identify-reviewerAfter installing, type/identify-reviewerin Claude Code to confirm it loaded.
Details
From the project READMEIdentify Reviewer
Load this skill at the start of any code review workflow — before analyzing diffs, commit logs, or prior comments.
Steps
-
Detect identities. Run these commands in parallel:
gh auth status git config user.name git config user.email- From
gh auth status, parseLogged in to github.com account <USERNAME>to get the GitHub handle. - From
git config, capture the local user's commit name and email.
These may not match exactly (e.g., GitHub handle
octocat, git nameOcto Cat, git email[email protected]). All three identify the same person.If
ghis not installed or the user is not authenticated, fall back to git config alone. If neither is available, skip identification and proceed without it — do not block the review. - From
-
Store the identity for the session. Use the discovered identity when:
- Attributing prior review comments. If the user previously commented on the PR, refer to those comments in second person ("your earlier comment about X") rather than third person ("octocat flagged X").
- Attributing commits. When analyzing
git logoutput, match the author name/email against the git config values. Refer to the user's own commits in second person ("your commitabc1234introduced...") and other authors' commits in third person. - Filtering approval status. Note whether the user has already approved, requested changes, or not yet reviewed. Frame the review summary accordingly (e.g., "You previously approved this PR; here are new findings since your approval").
- Distinguishing roles. If the user is also the PR author, flag this clearly and adjust tone (self-review). Match by both GitHub handle and git author email since either may appear in PR metadata.
-
Apply throughout the review. Every finding that references a prior comment or commit by the user should use second person. Prior comments and commits by other people remain in third person with their handle or name.
Matching Rules
- GitHub handle from
gh auth statusmatches PR review comment authors and PR author login. - Git name from
git config user.namematchesgit log --format='%an'author names. - Git email from
git config user.emailmatchesgit log --format='%ae'author emails. - A person is the local user if any of these identifiers match.
Examples
Without this skill:
octocat flagged the performance regression in a prior review. The author disagreed.
With this skill (when the local user is octocat):
You flagged the performance regression in a prior review. The author disagreed but did not provide benchmarks.
Without this skill:
Commit
abc1234by Octo Cat refactored the decoder interface.
With this skill (when git user.name is "Octo Cat"):
Your commit
abc1234refactored the decoder interface.