Human-Like Code Review

Reviews a GitHub pull request like a thoughtful human reviewer and writes the feedback to a markdown file.

You say
Install this skill Read the source first Free Written by n8n-io · unverified publisher
Context cost
2k tokensestimated from the bundle, loaded when it triggers
Bundle
1 file · 7.9 kBtext throughout, nothing executable
Licence
Source-availablefree to use
Last change
no release on file
Servers it uses
Noneruns standalone

What it does

Reviews a GitHub pull request like a thoughtful human reviewer and writes the feedback to a markdown file. Prioritizes bugs, behavioral regressions, security issues, and missing tests, ordered by severity. Use when given a PR URL to review, or when the user says /human-like-code-review.

Installed, it changes the agent in these ways.

What this skill changes about the agent is not written down here yet. The listing was collected from its source, and the description is in its own SKILL.md.

Workflow

Runs a procedure end to end.

collaborationgithubcode review

The skill itself

This is the whole product. A skill is instructions the model reads, so there is nothing behind the listing you cannot see first — the front matter loads with every session, and the body below it loads when the skill triggers.

SKILL.md7.9 kB · 151 lines
--- description: Reviews a GitHub pull request like a thoughtful human reviewer and writes the feedback to a markdown file. Prioritizes bugs, behavioral regressions, security issues, and missing tests, ordered by severity. Use when given a PR URL to review, or when the user says /human-like-code-review. allowed-tools: Bash(gh:*), Bash(git:*), Read, Glob, Grep ---
6# Human-Like Code Review
7
8Review a GitHub pull request with a code-review mindset and produce a copy/paste-friendly
9markdown file of feedback. Findings are the primary focus: prioritize bugs, behavioral
10regressions, security issues, and missing tests, ordered by severity. Do not make code
11changes unless the user explicitly asks for them.
12
13## Input
14
15The user must provide a **GitHub pull request URL** (e.g. https://github.com/n8n-io/n8n/pull/1234).
16
17If not provided, ask for it before proceeding.
18
19Extract the PR number and repository from the URL and use the gh CLI to fetch the PR diff and metadata.
20
21## Workflow
22
231. Parse the PR URL to get owner, repo, and PR number.
242. Fetch the PR diff: gh pr diff <number> --repo <owner>/<repo>
253. Fetch PR metadata: gh pr view <number> --repo <owner>/<repo>
264. Fetch existing review comments: gh api repos/<owner>/<repo>/pulls/<number>/comments
275. Review the diff thoroughly with a critical, code-review mindset.
286. Produce a new .md file named review-<repo>-<number>.md inside the repo's gitignored tmp/ folder, so it is never committed (the tmp folder is listed in .gitignore). Create the folder if needed (mkdir -p tmp) and write to tmp/review-<repo>-<number>.md. Print the path to the file when done so the user can open it.
297. If a point was already raised in existing PR comments, check whether it's still valid - if resolved, confirm it's fixed; if still open, expand on it or add context instead of repeating it.
308. Before finishing, clean up any scratch files created during review. The only
31 file that should remain in tmp/ from this skill run is the final
32 tmp/review-<repo>-<number>.md review file.
33
34## Temporary file hygiene
35
36Prefer reading gh output directly instead of writing extra files. If you need
37scratch files for a complex review (for example, a saved diff or extracted file
38contents), remove them before you finish. Do not leave tmp/pr-*.diff,
39extracted source files, or empty temporary files behind.
40
41## What to prioritize
42
43Findings must be the primary focus, ordered by severity (most severe first):
44
451. **Bugs** - logic errors, off-by-one, null/undefined handling, incorrect conditions.
462. **Behavioral regressions** - changes that break or alter existing behavior.
473. **Security issues** - injection, auth/authorization gaps, unsafe input handling, secret exposure.
484. **Missing tests** - the actual change isn't covered, or edge cases are untested.
49
50Style, naming, and minor nits come last, and only if they genuinely matter.
51
52## Backward compatibility
53
54Especially when nodes are changed, check that the change does not break backward
55compatibility for existing users' workflows (renamed/removed parameters, changed
56defaults, altered output shape, different behavior for the same input).
57
58If there's a risk of broken backward compatibility, consider node versioning and
59leave this inside the comments - point out the risk and suggest a new node version
60(or a versioned default) rather than changing existing behavior in place.
61
62## Output format
63
64The markdown file must contain:
65
66- A header with the PR title, URL, and date of review.
67- A ## Hints for a reviewer section (see below).
68- A ## General section (see below).
69- A ## Comments section with a list of review comments in this format:
70
71file name + line number + comment
72
73Comments should be easy to copy/paste. Do not quote comments using > - just write them directly.
74
75It's totally okay to have no line comments. Do not force findings or point out
76minor things just to have something to say. In those cases, prefer an empty
77comments list and a short positive ## General comment.
78
79When a comment suggests something different, be precise about it. Either propose the actual code change (a short snippet or suggestion block the author can apply directly) or, if a full snippet isn't practical, state the concrete direction (which function/value/approach to use) rather than a vague hint. Avoid comments like "this could be cleaner" with no actionable next step.
80
81### Hints for a reviewer
82
83Right after the header, include a ## Hints for a reviewer section to orient the
84human reviewer before they read the diff:
85
86- A short reason why the PR was created (the problem it solves or the goal).
87- A few basic words explaining the solution, without overcomplication.
88- If it's a community PR, mention it briefly. You can usually spot this from
89 authorAssociation or a fork-prefixed branch like random-fork-owner:fix-node-option.
90
91Keep it to a couple of sentences. It's about saving the reviewer time, not a
92detailed write-up.
93
94### General summary comment
95
96Before the line-by-line comments, include a ## General section that can be
97pasted as the review summary. Make it sound human and natural - it is okay to
98start with something short and friendly like "Hey, nice job on this" when the
99change deserves it. Then add any top-level, PR-wide feedback that doesn't belong
100on a single line - e.g. design or architecture concerns, an implicit/type-unsafe
101contract between files, repeated patterns, scope, or missing test coverage of
102the actual change.
103
104- Keep it short and conversational. Don't repeat or summarize the individual line comments here.
105- The exception is a big design issue with the overall solution: when the whole approach is wrong or has a structural problem, explain the overall idea here rather than scattering it across individual comments.
106- If there's genuinely nothing PR-wide to raise, write a short positive review
107 summary and move on - do not pad it.
108
109## Line number rules
110
111Line numbers MUST be the actual line numbers in the file on the PR branch (the new/right side of the diff), NOT the position within the diff hunk.
112
113To get the correct line number: look at the @@ hunk header (e.g. @@ -19,10 +19,9 @@). The +19 means the new file starts at line 19. Count down from there for each line that is a context line ( ) or an added line (+). Skip removed lines (-) - they don't exist in the new file.
114
115Example: if a hunk says @@ -10,5 +10,6 @@ and you want to comment on the 3rd non-removed line in that hunk, the line number is 10 + 2 = 12.
116
117Never guess line numbers. Always compute them from the hunk headers.
118
119## Consistency validation
120
121Before suggesting a change to a pattern (naming, structure, style), check whether the same pattern is used elsewhere in the codebase or in similar nodes/files. If it is an established convention, do NOT flag it. Only comment if something genuinely deviates from existing patterns.
122
123## Formatting rules
124
125- Never use long dashes or em-dashes. Use - instead.
126- Keep comments as short as possible. One sentence is ideal.
127- For line comments, avoid filler like "Nice work!", "Looks great!", or "Good job here." - keep them actionable or questioning.
128
129## Tone
130
131Write review comments naturally, like a friendly human reviewer.
132
133Feel free to use phrases like:
134
135- How about...
136- I wonder if...
137- WDYT?
138
139You can also insert an emoji from time to time 🙂
140
141Keep comments friendly, short, and collaborative. Avoid judgmental wording like "you made a mistake" or anything overly critical.
142
143## Important
144
145Do not make code changes unless the user explicitly asks for them. This skill produces a review, not a patch.
146
147The very last sentence of your reply must be a clickable Markdown link to the
148review file, so the user can open it from the agent chat immediately. Use this
149format: [tmp/review-<repo>-<number>.md](tmp/review-<repo>-<number>.md).
150Nothing should come after the link.
151
In the file
SKILL.md1,271 words
Files1
LicenceSource-available
Why you can read it

Nothing in a skill executes. The client loads the text and the model follows it, so a skill can be audited the way a runbook is — by reading it.

What it costs in context

Skills are not billed by the call. They are paid for in context: every token the instructions occupy is a token your code, your diff and your conversation cannot use. Here is what this one takes and when it takes it.

≈90
always loaded
The name and description, so the model knows the skill exists and when to reach for it.
1,885
on trigger
The instruction body, read only when the skill fires.
0.99%
of a 200k window
Ten skills this size would take about 10% of the window before you open a file.
050k100k150k200k context window

2k tokens, estimated from the bundle at four bytes to the token, held for the rest of the session once it triggers. Middling. Fine to keep on in a project where you use it weekly, worth unloading in one where you never do.

Servers bill, skills cost

A server charges by the month. A skill charges once per session, in context, and then keeps charging it for as long as the session lives.

Before and after

The same question, put to the same model twice: once as it comes, and once with these instructions loaded.

No worked example has been published for this skill yet.

Adoption
Installsnone yet
Ratingno reviews yet

The procedure it runs

The procedure has not been published here. It is in the skill’s own SKILL.md, which its author has not sent to the marketplace yet.

Prose, not code

These steps are written for a model to follow, not executed by a runtime. It can still be told to skip one, and it will say so when it does.

Servers it uses

None. This skill calls no MCP servers at all.

Everything it needs is in the instructions, so it works in a project with nothing connected — the model reads the file and changes how it works with what it can already reach.

It writes no files and reaches no network. All it changes is how the model reasons and writes.

What it asks for
Writes filesno
Network accessno

Read from the allowed-tools line of this skill’s own SKILL.md. A skill grants no permissions of its own — it can only ask for tools your client already has.

What it will not do

Every skill is narrow, and the useful ones say where they stop. These are the jobs this one is the wrong tool for.

What this skill is not for has not been published here. Nothing is implied by that: it is a section the author has not filled in.

What is in the bundle

1 file, 7.9 kB on disk. A bundle is text throughout: the instructions the model reads, plus the templates it fills in.

  • SKILL.md7.9 kB
What is not in it

No dependencies and nothing executable: a skill is text the agent reads, so the bundle is 1 file you can review in full before installing. The Source-available licence covers the templates and examples as well as the instructions.

Install

Installing copies the bundle into your project. Nothing runs at install time — the files sit on disk until the model reads them.

# Human-Like Code Review · 2k tokens when loaded npx mcprush@latest skill add n8n-io/human-like-code-review

Writes to .claude/skills/human-like-code-review/ in the current project. Add --global to put it in your home directory instead, for every project.

Which clients pick it up on their own

A skill is a folder of text. A client with a skills folder reads it without being told; everywhere else the same text works, it is just handed to the model rather than found.

Claude Code.claude/skills/
Claude Desktop
ChatGPT
Cursor.cursor/skills/
VS Code.github/skills/
Codex CLI.agents/skills/
Gemini CLI.gemini/skills/
Grok.grok/skills/
Zed.agents/skills/
Windsurf.windsurf/skills/
Agent SDK.claude/skills/
HTTP / API
This release
Versionnot versioned
Publishedno release date on file
PriceFree
Referencen8n-io/human-like-code-review

Versions

Its author publishes no version number, so there is nothing here to pin to: what you install is the folder as it stands today. Instructions change more often than APIs do — a skill can be rewritten entirely without anything it depends on moving.

v
  • No earlier releases have been published to the marketplace.
Pinning

Nothing to pin to: this skill carries no version number of its own. What you install is what the folder holds on the day you install it.

Reviews

no reviews yet · no installs yet

Nobody has reviewed this skill yet. The rating is the mean of the reviews written here, so there is none until somebody writes the first.

Who can post

Only accounts that have had the skill installed for fourteen days, so a review is written after living with it rather than after reading it. Publishers may reply once.

Publisher
Servers0
Claim this skill