yamcodesyamcodes/arkenv/skills/code-review/SKILL.md

code-review

Skill147 starsChanged 23 days agoMITView on GitHub

Fetch, analyze, and address code reviews and comments on GitHub, or perform a code review on changes in the workspace. Make sure to use this skill whenever the user mentions code reviews, addressing PR reviews, fixing PR comments, resolving review feedback, performing a code review, or running '/code-review', even if they don't explicitly name GitHub or the PR number.

We split this skill into the rules it gives an agent

12 rules. 0 are common, 9 are distinctive, and 3 are very specific to this project.

0
Common
Most of the 185 edited versions we read keep these.
9
Distinctive
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.

Common
Distinctive
Very specific

Distinctive:
Mode A: Address / Fix Review Comments: Follow this mode if the user wants to address, fix, or resolve comments/feedback from a prior or …
line 16
Distinctive:
Mode B: Perform Code Review: Follow this mode if the user wants a review of their changes or the current workspace (e.g., "review my code", …
line 17
Distinctive:
Run git status to find the current branch.
line 26
Very specific:
Run gh pr status to find the active pull request number and repository information.
line 27
Distinctive:
Check for Stale/Addressed Comments: Before making any code modifications, verify if the comment is already addressed or stale (e.g.
line 37
Distinctive:
Handle Ambiguity / Ask for Clarification: If a comment is ambiguous, lacks context, or if you are unsure of the best implementation path, …
line 38
Very specific:
Update the code using replace_file_content or multi_replace_file_content.
line 42
Very specific:
Run the test suite (e.g., pnpm test, npm test, or vitest) to ensure all tests pass.
line 46
Distinctive:
Run size limit checks if applicable.
line 47
Distinctive:
Comment and Resolve on PR: Always reply to and resolve addressed threads on GitHub:
line 55
Distinctive:
Run git status to check modified files.
line 83
Distinctive:
Run git diff (or compare branches) to retrieve the full diff of the changes under review.
line 84

“Common” is measured: kept by at least 6 in 10 of the 185 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.

Files

SKILL.md

Code Review

A dual-purpose skill to either (1) systematically retrieve and address pull request review comments on GitHub, or (2) perform a code review on changes in the workspace.

Workflow Selection

At the start of execution, identify the user's intent:

Mode A: Address / Fix Review Comments: Follow this mode if the user wants to address, fix, or resolve comments/feedback from a prior or active review (e.g., "fix PR comments", "address review notes", "resolve feedback", "address /code-review").
Mode B: Perform Code Review: Follow this mode if the user wants a review of their changes or the current workspace (e.g., "review my code", "check these changes", "do a code review", "/code-review").

Mode A: Address / Fix Review Comments

Systematically retrieve and fix comments from a PR review.

1. Locate current PR and comments

Run git status to find the current branch.
Run gh pr status to find the active pull request number and repository information.
Fetch Comments (Avoid Missing Inline Comments): Standard commands like gh pr view <PR_NUMBER> --comments only return high-level conversation summaries and completely omit inline code review comments made in the diff. To reliably retrieve the complete list of inline review comments, query the GitHub API directly:
```
gh api repos/:owner/:repo/pulls/<PR_NUMBER>/comments --jq '.[] | {id, path, line, body}'
```

2. Parse and analyze comments

Extract the list of review comments. Focus on unresolved or actionable requests.
For each comment, identify the affected file path, line numbers, and expected outcome.
Check for Stale/Addressed Comments: Before making any code modifications, verify if the comment is already addressed or stale (e.g. if the target code has already been changed or deleted in a recent commit). Mark such comments as "Stale/Already Addressed" and skip them.
Handle Ambiguity / Ask for Clarification: If a comment is ambiguous, lacks context, or if you are unsure of the best implementation path, STOP and ask the user for clarification. Do not make risky assumptions.

3. Implement the fixes

View the surrounding code using the view_file tool to understand context.
Update the code using replace_file_content or multi_replace_file_content. Keep changes minimal and adhere strictly to the codebase's existing code style, imports, and naming patterns.

4. Verify changes

Compile/build the package (e.g., pnpm build, npm run build, or tsc --noEmit).
Run the test suite (e.g., pnpm test, npm test, or vitest) to ensure all tests pass.
Run size limit checks if applicable.

5. Report results & comment back

Present a clear markdown table summarizing:
- Review comment / concern.
- File and lines changed.
- Action taken (e.g., "Fixed", "Already Addressed", "Skipped").
- Verification status.

Comment and Resolve on PR: Always reply to and resolve addressed threads on GitHub:

Reply: Post a reply to the thread using the REST API (with the database ID of the last comment):

gh api -X POST /repos/:owner/:repo/pulls/<PR_NUMBER>/comments/<comment_id>/replies -f body="Addressed in latest commit."

Resolve Thread: Mark the thread as resolved using the GraphQL API (using the GraphQL thread ID PRRT_...):

gh api graphql -F threadId="<thread_id>" -f query='
  mutation($threadId: ID!) {
    resolveReviewThread(input: { threadId: $threadId }) {
      thread { id isResolved }
    }
  }
'

General Comment: To add a general comment to the PR:

gh pr comment <PR_NUMBER> --body "Addressed review comments: ..."

Mode B: Perform Code Review

Perform a high-quality, professional code review of the workspace changes.

1. Retrieve changes

Run git status to check modified files.
Run git diff (or compare branches) to retrieve the full diff of the changes under review.

2. Analyze the changes

Review the diff/code for:

Correctness & Bugs: Off-by-one errors, edge cases, incorrect conditional logic.
TypeScript & Types: Stale or weak types, unsafe casts, unused imports or variables.
Dead Code: Functions, imports, or files that are defined but never used.
Stale JSDoc & Docs: Stale doc comments that refer to renamed functions or old signatures.
Architectural Patterns: Consistency with the repository's architecture (e.g. modular structure, proper abstraction boundaries).

3. Report review findings

Output the code review structured by file:

For each file, list specific findings with line numbers and recommendations.
Categorize findings into:
- ⚠️ Critical / Issues: Bugs, type/compilation errors, or logic issues.
- ℹ️ Refactors / Cleanup: Dead code, unused imports, stale JSDoc.
- 💡 Suggestions / Nits: Minor styling, readability improvements, or alternative approaches.

Download now (ZIP)

Other versions194 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 194
mattpocock/skills★ 309ksame name
TheAlgorithms/Python★ 226ksame name
microsoft/vscode★ 194ksame name
github/spec-kit★ 145ksame name
ggml-org/llama.cpp★ 133ksame name
shareAI-lab/analysis_claude_code★ 80ksame name
shareAI-lab/learn-claude-code★ 80ksame name
vectorize-io/hindsight★ 57ksame name
dbeaver/dbeaver★ 52ksame name
roboflow/supervision★ 51ksame name
184 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
Used alongsideProjects with it also use add-new-model, azsdk-common-sdk-breaking-change and 9 more.
Other files people use alongside this one.
- PydanticSkill
  add-new-model
  Add support for a newly-released language or image generation model in pydantic-ai (e.g. openai:gpt-5.6, anthropic:claude-sonnet-5, openai:gpt-image-2). Use when a provider ships a new model id and you need to wire literals, profile flags, adapters, and tests to recognize it. Handles SDK-lag, gateway list conventions, capability probing, and direct image-model geometry.
  Also in 9 projects that use this
- Microsoft AzureSkill
  azsdk-common-sdk-breaking-change
  Detect and mitigate SDK Breaking changes for an SDK package which is generated from TypeSpec. WHEN: "Detect SDK breaking changes for a service", "Detect SDK breaking changes for an SDK package", "Detect and mitigate SDK breaking changes for a service", "Detect and mitigate SDK breaking changes for an SDK package". INVOKES: skill: azsdk-common-generate-sdk-locally; MCP tools: azure-sdk-mcp:azsdk_customized_code_update, azure-sdk-mcp:azsdk_package_detect_breaking_change.
  Also in 4 projects that use this
- ww-w-aiSkill
  bkend-auth
  bkend.ai authentication guide. Signup, login, JWT tokens, sessions, role-based access control, and password management with bkend.ai BaaS. Triggers: bkend auth, bkend login, bkend signup, JWT, session, RBAC, password, bkend 인증, 로그인, 회원가입, bkend認証, ログイン, 新規登録, bkend认证, 登录, 注册, autenticacion bkend, authentification bkend, bkend-Auth Do NOT use for: data operations (use $bkend-data), file storage (use $bkend-storage).
  Also in 4 projects that use this
- ww-w-aiSkill
  bkend-cookbook
  bkend.ai cookbook with step-by-step tutorials and example projects. Build a todo app, blog, e-commerce store, and more with bkend.ai BaaS. Triggers: bkend cookbook, bkend tutorial, bkend example, todo app, blog app, bkend 쿡북, bkend 튜토리얼, 예제 프로젝트, bkendクックブック, チュートリアル, bkend教程, 示例项目, tutorial bkend, tutoriel bkend, bkend-Tutorial, ricettario Do NOT use for: initial setup (use $bkend-quickstart), specific features (use $bkend-data/auth/storage).
  Also in 4 projects that use this
- dzhngSkill
  close-spec
  When a spec under specs/<feature>/ is done shipping (a write-spec build, or any planned task that produced a spec), archive it to specs/done/ and rewrite it from a build-plan into a durable rationale — the why, the principles, the invariants — pointing back to the real code for the how. Use when implementation has landed and the plan no longer matches what shipped, or the user says a feature/spec is finished. Pairs with [write-spec](../write-spec/SKILL.md) (the plan this closes) and [review](../review/SKILL.md) (run before closing).
  Also in 4 projects that use this
- dzhngSkill
  design-with-images
  Explore UI and visual design with image generation, then iterate the real implementation against the user-selected concept. Use when brainstorming visual directions, offering mockup variants, or implementing an approved generated design; do not stop at the mockups or the first code approximation.
  Also in 4 projects that use this
- +5 more from ww-w-ai
In this repository40 other files it gives its agents.
- .agents/AGENTS.mdAGENTS.md
- AGENTS.mdAGENTS.md
- skills/typescript/AGENTS.mdAGENTS.md
- .agents/platforms/copilot-instructions.mdCopilot instructions
- arkenvSkill
- bulletproof-reactSkill
- changesetSkill
- create-skillSkill
- diagnoseSkill
- docs-writerSkill
- excalidrawSkill
- forward-portSkill
- gh-cliSkill
- grill-meSkill
- grill-with-docsSkill
- groom-issueSkill
- hallmarkSkill
- hexagonal-architectureSkill
- improve-codebase-architectureSkill
- internalize-skillSkill
- jsdocSkill
- modularizeSkill
- next-best-practicesSkill
- nuxtSkill
- pnpmSkill
- point-latest-at-rcSkill
- rename-skillSkill
- setup-matt-pocock-skillsSkill
- sync-mainSkill
- tackle-issueSkill
- tddSkill
- the-hatSkill
- the-voiceSkill
- to-prdSkill
- triageSkill
- turborepoSkill
- typescriptSkill
- write-a-skillSkill
- write-issueSkill
- zoom-outSkill

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

It worked
Partly
It didn't

What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free

12 rules. 0 are common, 9 are distinctive, and 3 are very specific to this project.

Code Review

Workflow Selection

Mode A: Address / Fix Review Comments

1. Locate current PR and comments

2. Parse and analyze comments

3. Implement the fixes

4. Verify changes

5. Report results & comment back

Mode B: Perform Code Review

1. Retrieve changes

2. Analyze the changes

3. Report review findings

Word for word · 0

Edited · 0

Wrote their own version · 194

add-new-model

azsdk-common-sdk-breaking-change

bkend-auth

bkend-cookbook

close-spec

design-with-images

Does it work?

No reviews yet

Your trail

Now do this for your own.