一键导入
review-pr
// Analyze a GitHub pull request including diff, comments, related issues, and local code context
// Analyze a GitHub pull request including diff, comments, related issues, and local code context
Find and prioritize open GitHub issues by severity, community impact, and maintainer abandonment
Enforces dlt docstring conventions. Use when writing or modifying docstrings, classes, or function signatures in Python files.
Enforces dlt import conventions and ordering. Use when writing or modifying Python imports in dlt/ or tests/.
Use when reading, editing, or creating files in dlt/_workspace/helpers/dashboard/ or tests/workspace/helpers/dashboard/ or tests/e2e/
Create or reuse a git worktree for a pull request or branch so reviews and work happen in isolation
Triage, plan, and implement a fix or feature for a GitHub issue end-to-end
| name | review-pr |
| description | Analyze a GitHub pull request including diff, comments, related issues, and local code context |
| argument-hint | <pr-url-or-number> [-- <optional instructions>] |
Parse $ARGUMENTS to extract the PR identifier and optional reviewer instructions:
-- (or all of it, if there is no --) is the PR identifier (URL or number). Referred to as PR_ID below.-- is reviewer instructions — additional focus areas or context from the caller. If absent, there are no special instructions.Analyze the pull request: PR_ID
Run the following steps. Gather data in parallel where possible.
Resolve the PR number:
gh pr view PR_ID --json number
Use the number to form the worktree name review-pr-<number>.
Invoke the /create-worktree review-pr-<number> --pr <number> skill to create an isolated worktree for this PR. Note the worktree path from the skill output — referred to as WORKTREE below.
Verify that the cwd is now inside the worktree:
pwd
If pwd does not show WORKTREE, run cd WORKTREE and verify again. Stop with an error if the cwd cannot be set. Once confirmed, subsequent Bash calls will run inside the worktree automatically.
Use gh to collect all PR information in parallel:
gh pr view PR_ID --json title,body,author,state,baseRefName,headRefName,number,url,comments,reviews,labels,milestonegh pr diff PR_IDpyproject.tomlIf the PR diff (from step 2) touches pyproject.toml, run the automated dependency checker.
First, fetch the latest devel from origin so the comparison is against the current state:
git fetch origin devel
Then run the script — always compare against origin/devel regardless of the PR's base branch:
python tools/check_dependency_changes.py origin/devel
The script finds the merge-base, simulates a three-way merge (like GitHub), and reports:
[project.dependencies]) — displayed as WARNING (these affect every user)[project.optional-dependencies]) — displayed as WARNING (these affect users of specific extras)[dependency-groups]) — listed for awareness (no impact on end users)pyproject.toml would conflict, the script warns and falls back to showing the PR's intended changesInclude the script output verbatim in the review. If the script exits with code 1 (changes detected), flag dependency changes in the review verdict. If it exits with code 2 (conflicts), flag that pyproject.toml needs conflict resolution.
If pyproject.toml is not in the diff, skip this step.
Use gh pr checks PR_ID to retrieve the CI check results. Look for checks matching lint on all python versions / lint* — these run mypy, ruff, flake8, bandit, and docstring checks across Python 3.9–3.13 (defined in .github/workflows/lint.yml).
gh run view <run-id> --log-failed to identify the specific errors (mypy type errors, ruff violations, etc.).Extract any issue references from the PR body (e.g. fixes #1234, closes #1234, #1234). For each referenced issue, fetch it with:
gh issue view <number> --json title,body,author,state,comments,labelsUnderstand the original problem being solved.
Using absolute paths under WORKTREE:
Some areas of the codebase have rules that are easy to miss in a generic code read. The references below are intentionally not loaded by default — read the linked file ONLY when the PR's diff matches the trigger, and apply its checklist before producing the review.
dlt/destinations/impl/**, dlt/dataset/**, dlt/destinations/sql_client*, code that builds SQL/relations/lineage, or schema-generation paths involving sqlglot or ibis. Covers when raw-string table/column identifiers must pass through the schema's naming normalizer, and how to distinguish first-time normalization from re-normalization.Based on the PR changes, identify what needs to be tested:
Produce a checklist of required test scenarios before evaluating existing tests.
@pytest.mark.parametrize.True/False, different type values), they must be parametrized into one test function.If the PR fixes a bug:
If the PR modifies public API (new parameters, changed behavior, new configuration options, new functions/classes exposed to users):
WORKTREE/docs/website/docs/ for existing documentation covering the topic of the PR.Write a structured analysis covering:
pyproject.toml was modified, include the warnings and listings from step 3. Main and optional dependency changes must appear as yellow WARNING blocks. Omit this section if no dependency changes were found.