القائمة
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.
استنادا إلى تصنيف SOC المهني
Default path for all single-workflow work: new one-off workflows, existing- workflow edits, verification repairs, and workflow-local data tables. Use build-workflow directly — do not load planning or create-tasks first. Load planning only when multiple coordinated workflows or shared cross-task data tables require a dependency-aware task graph.
Handles workflow verification and setup after build-workflow succeeds, or when the message contains workflow-verification-follow-up or workflow-setup-required. Load after direct builds, when verificationReadiness requires action, or on orchestrator verify/setup follow-up turns.
Guides users through creating effective Agent Skills. Use when you want to create, write, or author a new skill, or asks about skill structure, best practices, or SKILL.md format.
Checks if a community pull request is ready for human review. Verifies CLA signature, PR title format, description completeness, test coverage, and cubic-dev-ai issues, then triages to the right Linear team or recommends a close. Use when given a PR number or branch name to review, or when the user says /community-pr-readiness-check, or asks to check if a PR is ready for review.
Create Linear tickets or GitHub issues following n8n conventions. Use when the user asks to create a ticket, file a bug, open an issue, or says /create-issue.
Creates GitHub pull requests with properly formatted titles that pass the check-pr-title CI validation. Use when creating PRs, submitting changes for review, or when the user says /pr or asks to create a pull request.
| name | n8n:human-like-code-review |
| 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 |
Review a GitHub pull request with a code-review mindset and produce a copy/paste-friendly markdown file of feedback. Findings are the primary focus: prioritize bugs, behavioral regressions, security issues, and missing tests, ordered by severity. Do not make code changes unless the user explicitly asks for them.
The user must provide a GitHub pull request URL (e.g. https://github.com/n8n-io/n8n/pull/1234).
If not provided, ask for it before proceeding.
Extract the PR number and repository from the URL and use the gh CLI to fetch the PR diff and metadata.
gh pr diff <number> --repo <owner>/<repo>gh pr view <number> --repo <owner>/<repo>gh api repos/<owner>/<repo>/pulls/<number>/comments.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.tmp/ from this skill run is the final
tmp/review-<repo>-<number>.md review file.Prefer reading gh output directly instead of writing extra files. If you need
scratch files for a complex review (for example, a saved diff or extracted file
contents), remove them before you finish. Do not leave tmp/pr-*.diff,
extracted source files, or empty temporary files behind.
Findings must be the primary focus, ordered by severity (most severe first):
Style, naming, and minor nits come last, and only if they genuinely matter.
Especially when nodes are changed, check that the change does not break backward compatibility for existing users' workflows (renamed/removed parameters, changed defaults, altered output shape, different behavior for the same input).
If there's a risk of broken backward compatibility, consider node versioning and leave this inside the comments - point out the risk and suggest a new node version (or a versioned default) rather than changing existing behavior in place.
The markdown file must contain:
## Hints for a reviewer section (see below).## General section (see below).## Comments section with a list of review comments in this format:file name + line number + comment
Comments should be easy to copy/paste. Do not quote comments using > - just write them directly.
It's totally okay to have no line comments. Do not force findings or point out
minor things just to have something to say. In those cases, prefer an empty
comments list and a short positive ## General comment.
When 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.
Right after the header, include a ## Hints for a reviewer section to orient the
human reviewer before they read the diff:
authorAssociation or a fork-prefixed branch like random-fork-owner:fix-node-option.Keep it to a couple of sentences. It's about saving the reviewer time, not a detailed write-up.
Before the line-by-line comments, include a ## General section that can be
pasted as the review summary. Make it sound human and natural - it is okay to
start with something short and friendly like "Hey, nice job on this" when the
change deserves it. Then add any top-level, PR-wide feedback that doesn't belong
on a single line - e.g. design or architecture concerns, an implicit/type-unsafe
contract between files, repeated patterns, scope, or missing test coverage of
the actual change.
Line 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.
To 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.
Example: 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.
Never guess line numbers. Always compute them from the hunk headers.
Before 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.
- instead.Write review comments naturally, like a friendly human reviewer.
Feel free to use phrases like:
You can also insert an emoji from time to time 🙂
Keep comments friendly, short, and collaborative. Avoid judgmental wording like "you made a mistake" or anything overly critical.
Do not make code changes unless the user explicitly asks for them. This skill produces a review, not a patch.
The very last sentence of your reply must be a clickable Markdown link to the
review file, so the user can open it from the agent chat immediately. Use this
format: [tmp/review-<repo>-<number>.md](tmp/review-<repo>-<number>.md).
Nothing should come after the link.