New: 98,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

ToolJet Pull Request Review

by ToolJet in ToolJet/ToolJet

Reviews a ToolJet pull request of any size and writes a findings report for you to read first, scaling the process to the diff and posting to GitHub only on request.

AGPL-3.0Auto-check passedDevelopment

Install ToolJet Pull Request Review

skills CLI
$ npx skills add ToolJet/ToolJet --skill review-pr -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install ToolJet/ToolJet review-pr --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/ToolJet/ToolJet.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.agents/skills/review-pr .claude/skills/review-pr && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
review-pr
GitHub stars
41k
Token cost
~3.1k tokens
SKILL.md length
1,577 words
Files
5 (incl. references)
Skills in repo
7
Repo updated
First seen
Licence
AGPL-3.0

At a glance

Reviews a ToolJet pull request of any size and writes a findings report for you to read first, scaling the process to the diff and posting to GitHub only on request.

  • Works in 3 steps: Links to fetch: GitHub issue, PR, spec,… → Pre-context pasted inline: Slack thread,… → None. Review cold.
  • Reviewing a ToolJet PR before merge
  • SKILL.md covers Intake, Scale, Workflow and Lenses, plus 6 more sections
  • Calls gh

What it does

Before reading any diff, the agent asks for review context: links to a GitHub issue, PR or spec to fetch, pre-context pasted inline such as Slack threads and known deviations, or none for a cold review. The target is a PR number, URL or branch, defaulting to the current branch's PR, and it never reviews a PR you did not name or imply. The deliverable is a report file, and nothing reaches GitHub unless you ask after reading it.

Effort scales with size, counted as additions plus deletions across the root PR and the ee-server and ee-frontend submodule PRs. A small diff under about 1k lines gets a single pass and one report, while a medium one of roughly 1k to 8k lines is split into two to five conceptual sections, with one optional subagent per section. The diff is read as concepts that build on each other, tests first, and findings should survive a challenge from the author and point to lines they can act on. Reference files cover context intake, review lenses, comment format and posting.

When your agent uses it

  • Reviewing a ToolJet PR before merge
  • Finding blockers in a branch or a diff
  • Reviewing PRs that include ee-server and ee-frontend submodule changes
  • Turning review notes into a report before any comments are posted

Example prompts

  • “Review the current branch's PR and write me a findings report.”
  • “Look over this ToolJet diff; the linked spec is the context.”
  • “Check this PR for blockers, but don't post anything to GitHub.”

Requirements

  • GitHub CLI (gh), for fetching issues and pull requests

Workflow steps

3 steps, taken from the first numbered list in SKILL.md.

  1. Links to fetch: GitHub issue, PR, spec, design doc. Fetched with gh issue view, gh pr view,
  2. Pre-context pasted inline: Slack thread, prior review notes, product decisions, known deviations.
  3. None. Review cold.

What it can do on your machine

Read from SKILL.md and the folder at commit 00af063. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • gh

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use gh, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

ToolJet Pull Request Review loads about 3.1k tokens when it runs, and up to ~9.7k if it reads all its reference files. Until then it costs about 131 tokens; SKILL.md has 1,577 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~131
When it runs · the whole SKILL.md, loaded when a task matches
~3.1k
With references · SKILL.md plus every file in references/, read only if the agent opens them
~9.7k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from ToolJet/ToolJet at commit 00af063, republished under its AGPL-3.0 licence (© ToolJet). 1,577 words, ~3,109 tokens.

Download SKILL.mdSave it as .claude/skills/review-pr/SKILL.md (or your agent's skills folder). This skill also uses 4 other files; get the full folder from GitHub.
name
review-pr
description
Review a ToolJet pull request of any size and produce a findings report the user reads first. Use when asked to review, look over, check, critique, or comment on a PR, a branch, or a diff, or to find blockers before merge. Starts by asking for review context (issue, spec, prior threads, known deviations), scales the process to the size of the diff, covers the root repo plus the ee-server and ee-frontend submodule PRs. Posting to GitHub is a separate, opt-in step the user asks for explicitly, never a default.

Review a pull request

Produce findings that survive a challenge from the author, anchored to lines the author can act on, in the voice the user would use. Read the diff as concepts that build on each other, tests first, then report what is worth a thread.

The deliverable is a report file. Nothing reaches GitHub unless the user asks for it after reading the report. A review posted before the user has weighed each finding puts their name on claims they have not checked, and a deleted thread still shows in the author's notifications.

Intake

Ask before reading any diff. Context decides what counts as a finding: a deliberate spec deviation is not a bug, and a product decision already made is not a question. Reviewing cold and then learning the answer costs a deleted thread.

One question, with options:

  1. Links to fetch: GitHub issue, PR, spec, design doc. Fetched with gh issue view, gh pr view, or the doc tool that fits.
  2. Pre-context pasted inline: Slack thread, prior review notes, product decisions, known deviations.
  3. None. Review cold.

Also accept the target as a PR number, URL, or branch name. Default target is the current branch's PR (gh pr view). Never review a PR the user has not named or implied by branch.

Procedure, SHAs, and how to pull existing threads: references/context-intake.md. Read it at the start of every review.

Scale

Size is the sum of additions and deletions across the root PR and both submodule PRs. Thresholds are rough; pick the tier that matches the reading effort, not the number.

TierSizeProcess
Smallunder ~1k linesSingle pass in the main thread. No sections, no subagents. One report file.
Medium~1k to ~8kTwo to five conceptual sections. Subagents optional, one per section when they are used. One report file with a section per concept.
Largeabove ~8kOne subagent per section. Index file with blocker table, one file per section, handoff doc for everything below the bar. If posting is later requested, Blocker and High only.

A small PR touching a migration or an auth path gets the large-tier lenses at small-tier mechanics.

Workflow

  1. Run intake. Record head SHAs for root, server/ee, frontend/ee. Fetch existing review comments on all three PRs so no open thread is duplicated and new findings match the tone already on the PR.
  2. Read the PR description in full. Its claims ("covered by tests", manual checklists) are hypotheses. Verify or refute each and say which.
  3. Read the closest AGENTS.md for every module touched, UBIQUITOUS_LANGUAGE.md, and the maps under .agents/context/ when the PR crosses a system boundary.
  4. Split into conceptual sections (medium and large only). A section is one concept, ordered so each builds on the last: data model, resolver, services, API surface, frontend.
  5. Start every section at its tests. The spec says what the author believes the contract is, the implementation says what it is, the gap is the review. Apply the mutation heuristic from server/docs/testing.md to each new test: break the implementation, and if the suite stays green the test asserts nothing.
  6. Apply the lenses below. Every finding carries file:line verified inside a diff hunk at the recorded head. An unanchored finding is an opinion and stays out.
  7. Consolidate. Two sections finding the same thing is signal, but only one entry carries it. Correct the first pass against what the section reads disproved.
  8. Verify. A fresh subagent, given the report and the head files, tries to refute every finding: the anchor lines, each factual claim, and reachability. A branch that exists but cannot execute (its lookup can never match, a constraint blocks its input) is not a finding; that is the miss a first pass makes most often, because it checks that code is present and not that it runs. Withdraw what fails and say so in the report, with the evidence.
  9. Write the report (Output contract below) and hand the path to the user. Stop there. Each finding is already written as the comment it would become, so posting later is a copy, not a rewrite.
  10. Only when the user asks to post: confirm which findings, re-verify anchors against the current heads, then follow references/posting.md.

Lenses

Cite the repo's own authority in the finding instead of restating the rule. Detail per lens, with what to look for and how to phrase it: references/lenses.md. Read it before the first section.

LensAuthority
CorrectnessSection's own contract, tests, .agents/context/architecture-map.md for cross-boundary flows. Every tenant, environment, edition.
Testsserver/docs/testing.md: mutation heuristic, toMatchObject shape assertions, behavior matrix, boundary rule. frontend/AGENTS.md → Testing (names src/test/README.md; App Builder layer).
Typingserver/AGENTS.md Design principles. No any; precise types or unknown casts.
CommentsExhaustive sweep, one verdict per block the diff adds: DELETE (default), KEEP as one line only when the WHY is not deducible from code, symbol, or test name, AGENTS.md only for a general module rule. Deletion beats relocation.
Designserver/AGENTS.md Design principles: pure calculations out of I/O, stratified design, deep modules. Practical refactors only.
ConventionsClosest AGENTS.md plus the living-docs rule in root AGENTS.md: a changed invariant with no AGENTS.md update is a finding. Glossary terms from UBIQUITOUS_LANGUAGE.md.
API contract.agents/skills/api-design/SKILL.md. Only when server/src/modules/**/controller*.ts, dto/, or external-apis/ are touched.
Securityserver/AGENTS.md Security, frontend/AGENTS.md Security, root AGENTS.md Public/private boundary.

Submodules

The PR is three PRs: root (ToolJet/ToolJet), server/ee (ToolJet/ee-server), frontend/ee (ToolJet/ee-frontend). Cover every file in all three. Every finding records which of the three PRs it belongs to and that PR's head SHA; check the path for the EE marker before matching against the root repo.

The root repo is public. A finding destined for the root PR never quotes private source, private paths, customer data, or private issue context. State the invariant in public terms and point at the EE thread.

Show full SKILL.md (609 more words)Show less

Finding format

Write every finding as the comment it would become, per references/comment-format.md. Read it before drafting the first finding. The opening line differs by tier: plain consequence sentence for small and medium, severity-tagged for large where triage across many threads matters.

Standing tone rules, every finding, every tier:

  • Address the author, "we" voice, suggestion tone. suggestion blocks when the change sits on the anchored lines.
  • Plain English. Short paragraphs, simple words, domain terms from UBIQUITOUS_LANGUAGE.md, anything else explained in plain words on first use. Bullets only for lists the reader scans. A diagram (mermaid or ascii) whenever the point is a flow or two paths converging.
  • An Impact. paragraph, written as the scenario the user or operator hits, whenever the finding reaches past the codebase. Omitted otherwise.
  • No em dashes. No meta-commentary about how the review was done. No praise padding; a decision worth affirming is a finding ("keep X, because Y").
  • One finding per entry. GitHub resolves per thread, so an entry that bundles two findings cannot be posted as is.

Output contract

The report lives under the scratchpad unless the user names another location. Hand the path back with a short summary: blocker count, what was checked and found clean, and any open questions for the user.

Every finding entry carries: target PR and head SHA, path:line (with start_line for a range), the drafted comment body, and a one-line rationale for the severity. That is exactly what posting needs, so the report doubles as the posting queue.

Small and medium tiers: one review.md, findings ordered by severity, then a "checked and clean" list.

Large tier:

  • index.md: blocker table (file:line, one-line consequence, section), cross-cutting themes, and the section list.
  • One file per section with the drafted findings and what was checked and found clean.
  • handoff.md: everything below the posting bar, grouped by section, complete enough to read cold. Lead with the themes that cover most of the list, then the anchored entries.

Posting (opt-in)

Do not post, and do not offer to post, in the same turn as the report. The user decides after reading. When they ask:

  1. Confirm which findings go up (all, or a named subset) and whether a root comment is wanted. Default is inline comments only, no review body.
  2. Re-verify every anchor against the current head SHAs. A head that moved since the report invalidates the lines.
  3. Post per references/posting.md: mechanics, verified gh api calls, and the failure modes that cost a re-post. Read it before the first POST.
  4. Reply with every posted comment as a URL, grouped by PR, and anything skipped and why.

Filing findings as issues

When a finding is out of the PR's scope but worth tracking, file it with the create-issue skill, the only sanctioned path for an agent to open an issue. It targets ToolJet/tj-ee and applies the required Agent and review-pr labels. Always ask the human for explicit approval before creating any issue; being asked to review is not approval to file. Do not call gh issue create directly, and never file to the public repository.

Boundaries

  • Analysis only. Never edit the PR's code, and never fix a finding unless the user separately asks. A requested fix follows the commit and create-pr skills, never --no-verify.
  • The report is the deliverable. Never post to GitHub unless the user asks after reading it, and never to a PR the user has not named.
  • Never quote private submodule source or paths on the public root PR.
  • Do not rate a finding's severity in one place and split threads on that rating in another; the severity comes from the section review and the split follows it.

© ToolJet, AGPL-3.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 4 other files (references) in .agents/skills/review-pr of ToolJet/ToolJet.

  • SKILL.md
  • references/comment-format.md
  • references/context-intake.md
  • references/lenses.md
  • references/posting.md

Open the folder on GitHubat commit 00af063

Compare with similar skills

ToolJet Pull Request Review next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

ToolJet Pull Request Review compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
ToolJet Pull Request Review this skillToolJet/ToolJet41k—~3.1kAutomated safety check: PassAGPL-3.0
PR Babysitteropeninterpreter/openinterpreter69k3 repos~4.2kAutomated safety check: PassApache-2.0
GitHub Review Iterationprisma/orm48k—~2.2kAutomated safety check: PassApache-2.0
PR Review State Fetchprisma/orm48k—~767Automated safety check: PassApache-2.0
PR Finalize Reviewmicrosoft/garnet12k—~3.1kAutomated safety check: PassMIT
Fastlane Pull Request Reviewfastlane/fastlane42k—~550Automated safety check: PassMIT

Similar skills

  • PR Babysitter

    openinterpreter/openinterpreter

    Watches an open GitHub pull request until it merges, handling review comments, diagnosing CI failures and retrying flaky checks along the way.

    69k GitHub starsUsed in 3 repos~4.2k tokens
    DevelopmentAuto-check passed

  • GitHub Review Iteration

    prisma/orm

    Official

    Runs a loop on a GitHub pull request: fetch review state, triage comments into actions, implement them and resolve threads, repeating until nothing actionable is left.

    48k GitHub stars~2.2k tokensUpdated today
    DevelopmentAuto-check passed

  • PR Review State Fetch

    prisma/orm

    Official

    Fetches a pull request's canonical review state as JSON, validates it, and renders markdown, a text summary and triage target files from it using bundled scripts.

    48k GitHub stars~767 tokensUpdated today
    DevelopmentAuto-check passed

  • PR Finalize Review

    microsoft/garnet

    Official

    Checks that a pull request's title and description match its implementation and reviews the code for Garnet best practices, reporting findings without posting them.

    12k GitHub stars~3.1k tokensUpdated today
    DevelopmentAuto-check passed

  • Fastlane Pull Request Review

    fastlane/fastlane

    Reviews a fastlane pull request against its linked issue and the project guides, separating blocking from non-blocking findings and handling vulnerabilities privately.

    42k GitHub stars~550 tokensUpdated today
    DevelopmentAuto-check passed

  • Pull Request Babysitter

    thedotmack/claude-mem

    Keeps watching a pull request, fixing real review and CI problems and resolving stale threads, until it is clean and ready to merge.

    99k GitHub stars~1.1k tokensUpdated today
    DevelopmentAuto-check passed

More from ToolJet/ToolJet

  • ToolJet Marketplace Plugin Builder

    ToolJet/ToolJet

    Turns an API description, such as an OpenAPI file or a Postman collection, into a connector plugin for ToolJet's marketplace and checks it with the repo's validator.

    41k GitHub stars~2.1k tokensUpdated today
    Auto-check passed

  • ToolJet Multi-Repo Commit

    ToolJet/ToolJet

    Commits changes across ToolJet's root repo and its server/ee and frontend/ee submodules, writing messages from the diffs and updating submodule pointers in order.

    41k GitHub stars~1.3k tokensUpdated today
    Auto-check passed

  • ToolJet Pull Request Creator

    ToolJet/ToolJet

    Opens a pull request for the current ToolJet branch, pushing the root repo and the ee submodules, creating submodule PRs first and then the main PR with a generated description.

    41k GitHub stars~3.6k tokensUpdated today
    Auto-check passed

  • ToolJet Release Cutter

    ToolJet/ToolJet

    Cuts a ToolJet release branch, bumps the version and moves feature PRs onto it, or adds more PRs to a release that already exists.

    41k GitHub stars~5.6k tokensUpdated today
    Auto-check passed

  • ToolJet Multi-Repo Merge

    ToolJet/ToolJet

    Merges a source branch into the current branch across ToolJet's root repo and its server/ee and frontend/ee submodules, handling conflicts and submodule order.

    41k GitHub stars~2.1k tokensUpdated today
    Auto-check: warnings

  • ToolJet Skill Manager

    ToolJet/ToolJet

    Decides where a new agent skill belongs in the ToolJet repo, public root or private ee submodule, then wires the symlinks so it loads in Claude Code, Cursor and Codex.

    41k GitHub stars~867 tokensUpdated today
    Auto-check passed

Works with

Categories

Questions about ToolJet Pull Request Review

What does ToolJet Pull Request Review do?

Reviews a ToolJet pull request of any size and writes a findings report for you to read first, scaling the process to the diff and posting to GitHub only on request. Before reading any diff, the agent asks for review context: links to a GitHub issue, PR or spec to fetch, pre-context pasted inline such as Slack threads and known deviations, or none for a cold review. The target is a PR number, URL or branch, defaulting to the current branch's PR, and it never reviews a PR you did not name or imply.

When should I use ToolJet Pull Request Review?

ToolJet Pull Request Review fits situations like: reviewing a ToolJet PR before merge; finding blockers in a branch or a diff; reviewing PRs that include ee-server and ee-frontend submodule changes; turning review notes into a report before any comments are posted.

How do I install ToolJet Pull Request Review in Claude Code?

Run `npx skills add ToolJet/ToolJet --skill review-pr -a claude-code`. Or copy the skill folder (.agents/skills/review-pr in ToolJet/ToolJet) into .claude/skills/review-pr in your project. Claude Code loads it when a task matches its description.

How do I install ToolJet Pull Request Review in Codex?

Run `npx skills add ToolJet/ToolJet --skill review-pr -a codex`. Or copy the skill folder (.agents/skills/review-pr in ToolJet/ToolJet) into .agents/skills/review-pr in your project. Codex loads it when a task matches its description.

Can I use ToolJet Pull Request Review in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add ToolJet/ToolJet --skill review-pr -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/review-pr, .gemini/skills/review-pr, .github/skills/review-pr and .opencode/skills/review-pr in your project.

What does ToolJet Pull Request Review need to run?

Going by SKILL.md and its folder, ToolJet Pull Request Review needs the command-line tools its instructions call (gh). Our summary lists: GitHub CLI (gh), for fetching issues and pull requests.

Does ToolJet Pull Request Review access the network?

SKILL.md contains no URLs. Its commands use gh, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is ToolJet Pull Request Review safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does ToolJet Pull Request Review use?

ToolJet Pull Request Review is published under the AGPL-3.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does ToolJet Pull Request Review use?

About 3.1k tokens (SKILL.md is roughly 12k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 6.6k tokens, read only when the agent opens those files.

What are the alternatives to ToolJet Pull Request Review?

Skills that share tags, products or a category with ToolJet Pull Request Review: PR Babysitter (openinterpreter/openinterpreter, 69k stars), GitHub Review Iteration (prisma/orm, 48k stars), PR Review State Fetch (prisma/orm, 48k stars) and PR Finalize Review (microsoft/garnet, 12k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains ToolJet Pull Request Review?

ToolJet (a GitHub organization) maintains it in ToolJet/ToolJet, which has 41,054 GitHub stars. The repository holds 7 skills in this directory. The repository was last updated on October 9, 2026.

Source: ToolJet/ToolJet on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.