How do I install the Saleor Pr Checklist skill?

Run npx skillmds@latest add saleor/saleor-pr-checklist in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Saleor Pr Checklist safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Saleor Pr Checklist?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Saleor Pr Checklist free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Saleor Pr Checklist?

saleor (@saleor) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Saleor Pr Checklist by saleor — Agent Skill

Name: Saleor Pr Checklist
Author: saleor

Saleor Pr Checklist

Final self-review gate before opening or updating a Saleor pull request — CHANGELOG placement, pre-commit, schema regen, and a pass over the review standards that reviewers most often enforce. Use when finishing a change and about to request review.

saleor Updated Sep 17, 2026

File contents

Saleor PR checklist

Run this before opening or updating a PR. It catches the process/hygiene issues and the recurring review comments that otherwise cost a round trip. (For schema-specific and migration-specific work, also use saleor-graphql-api-change and saleor-migrations.)

Process gate

Run pre-commit and fix everything it flags (formatting, lint, mypy). PRs regularly bounce for this alone.
Ensure new/changed tests pass locally before requesting review (see AGENTS.md for how to run tests).
Remove debug/test scaffolding (stray str(...) casts, prints, unused imports).
If you touched the GraphQL schema, regenerate schema.graphql.
For dependency changes, use the pinned uv version and change only the target dependency so uv.lock doesn't churn.

CHANGELOG

Add an entry under the correct section/heading — don't blind-append to the end of the file.
Never add or edit a CHANGELOG entry for an already-released version. Released fixes surface via the release description; a re-added entry is noise. (This is a frequent porting mistake.)
Keep the changelog diff scoped to your change — don't drop unrelated entries. Proofread the prose.
Add a migration-guide entry for any behavior change that could be breaking for some API consumers, even one intended as a feature.

Self-review against the standards reviewers enforce

Skim your own diff for the top recurring review comments (all detailed in AGENTS.md):

Tests: exact-value assertions (no > 0 / assert not errors); negative tests assert the side effect didn't happen; no asserting a value the test just set; design tests so a shared input can't mutate the expected value, rather than papering over it with an expensive copy.deepcopy; real fixtures over mocked internals; the fix has a regression test reproducing the real bug.
Layering: business logic in the domain layer, not the mutation; no graphql-layer imports from non-GraphQL code; validate at the point of production.
DB / scaling: no N+1 in loops; bulk update/delete; only-needed columns; on_commit for task scheduling; no blocking in request threads.
Naming: no cryptic abbreviations; positive booleans; legacy_ prefix on deprecated-behavior flags.
Error handling: specific exceptions (not bare Exception); retryable vs terminal distinguished; precise, field-attributed messages.
Dead code / types: delete code a refactor made dead; fix types at the source instead of cast().

PR description

Explain why, and for anything non-obvious (a deprecation path, a deferred cleanup, a concurrency decision) state it explicitly so a reviewer doesn't have to ask.
Link tracked follow-up issues for any deferred work (column drops, legacy removals).

---name: saleor-pr-checklistdescription: Final self-review gate before opening or updating a Saleor pull request — CHANGELOG placement, pre-commit, schema regen, and a pass over the review standards that reviewers most often enforce. Use when finishing a change and about to request review.---# Saleor PR checklistRun this before opening or updating a PR. It catches the process/hygiene issues and the recurringreview comments that otherwise cost a round trip. (For schema-specific and migration-specific work,also use `saleor-graphql-api-change` and `saleor-migrations`.)## Process gate- **Run pre-commit** and fix everything it flags (formatting, lint, mypy). PRs regularly bounce for this alone.- **Ensure new/changed tests pass locally** before requesting review (see AGENTS.md for how to run tests).- Remove debug/test scaffolding (stray `str(...)` casts, prints, unused imports).- If you touched the GraphQL schema, **regenerate `schema.graphql`**.- For dependency changes, use the pinned `uv` version and change only the target dependency so `uv.lock` doesn't churn.## CHANGELOG- Add an entry **under the correct section/heading** — don't blind-append to the end of the file.- **Never add or edit a CHANGELOG entry for an already-released version.** Released fixes surface via the release description; a re-added entry is noise. (This is a frequent porting mistake.)- Keep the changelog diff scoped to your change — don't drop unrelated entries. Proofread the prose.- Add a migration-guide entry for any behavior change that could be breaking for some API consumers, even one intended as a feature.## Self-review against the standards reviewers enforceSkim your own diff for the top recurring review comments (all detailed in AGENTS.md):- **Tests:** exact-value assertions (no `> 0` / `assert not errors`); negative tests assert the side effect didn't happen; no asserting a value the test just set; design tests so a shared input can't mutate the expected value, rather than papering over it with an expensive `copy.deepcopy`; real fixtures over mocked internals; the fix has a regression test reproducing the *real* bug.- **Layering:** business logic in the domain layer, not the mutation; no `graphql`-layer imports from non-GraphQL code; validate at the point of production.- **DB / scaling:** no N+1 in loops; bulk `update`/`delete`; only-needed columns; `on_commit` for task scheduling; no blocking in request threads.- **Naming:** no cryptic abbreviations; positive booleans; `legacy_` prefix on deprecated-behavior flags.- **Error handling:** specific exceptions (not bare `Exception`); retryable vs terminal distinguished; precise, field-attributed messages.- **Dead code / types:** delete code a refactor made dead; fix types at the source instead of `cast()`.## PR description- Explain *why*, and for anything non-obvious (a deprecation path, a deferred cleanup, a concurrency decision) state it explicitly so a reviewer doesn't have to ask.- Link tracked follow-up issues for any deferred work (column drops, legacy removals).

Frequently asked questions