Menu
Identifies the local user's GitHub account and git identity before performing code reviews. Load this skill at the start of any PR review, code review, or commit log analysis so findings can be framed relative to the user's own prior comments, commits, and approval status.
Basé sur la classification professionnelle SOC
Load when working with the module registry in workerd — reading, modifying, debugging, or reviewing module resolution, compilation, evaluation, or registration code. Provides pointers to three reference documents covering the legacy registry, V8 module internals, and the new registry design.
Guidelines for posting pull request review comments via GitHub CLI, including suggested edits format, handling unresolved comments, etiquette, and report/issue tracking. Load this skill when reviewing a PR via GitHub and posting inline comments.
Mandatory rules for running bazel tests during development. Load this skill before running any bazel test command, especially when validating fixes or verifying regression tests. Prevents false confidence from cached results, filter flags that silently match nothing, and partial test runs that miss breakage.
Structured scratch tracking document for investigation state during bug hunts - prevents re-reading code, losing context, and rabbit holes; maintains external memory so you don't re-derive conclusions
Step-by-step guide for updating the V8 JavaScript engine in workerd, including patch rebasing, dependency updates, integrity hashes, and verification. Load this skill when performing or assisting with a V8 version bump.
KJ/workerd C++ style guidelines for code review. Covers naming, type usage, memory management, error handling, inheritance, constness, and formatting conventions. Load this skill when reviewing or writing C++ code in the workerd codebase.
| name | identify-reviewer |
| description | Identifies the local user's GitHub account and git identity before performing code reviews. Load this skill at the start of any PR review, code review, or commit log analysis so findings can be framed relative to the user's own prior comments, commits, and approval status. |
Load this skill at the start of any code review workflow — before analyzing diffs, commit logs, or prior comments.
Detect identities. Run these commands in parallel:
gh auth status
git config user.name
git config user.email
gh auth status, parse Logged in to github.com account <USERNAME> to get the GitHub handle.git config, capture the local user's commit name and email.These may not match exactly (e.g., GitHub handle octocat, git name Octo Cat, git email octocat@example.com). All three identify the same person.
If gh is 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.
Store the identity for the session. Use the discovered identity when:
git log output, match the author name/email against the git config values. Refer to the user's own commits in second person ("your commit abc1234 introduced...") and other authors' commits in third person.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.
gh auth status matches PR review comment authors and PR author login.git config user.name matches git log --format='%an' author names.git config user.email matches git log --format='%ae' author emails.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.