Add "review" claude skill and use it in "gitbhub-pr-review"

[abmantis]

Proposed change

This moves some of the review instructions in the PR review skill into a general-purpose review skill.
The PR review skill should still work the same.

This is the first step in trying to create a skill that contributors can also use to review their own PRs before submitting them, aligned with our requirements.

Type of change

• Dependency upgrade
• Bugfix (non-breaking change which fixes an issue)
• New integration (thank you!)
• New feature (which adds functionality to an existing integration)
• Deprecation (breaking change to happen in the future)
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code or addition of tests

Additional information

• This PR fixes or closes issue: fixes #
• This PR is related to issue:
• Link to documentation pull request:
• Link to developer documentation pull request:
• Link to frontend pull request:

Checklist

• I understand the code I am submitting and can explain how it works.
• The code change is tested and works locally.
• Local tests pass. Your PR cannot be merged unless tests pass
• There is no commented out code in this PR.
• I have followed the development checklist
• I have followed the perfect PR recommendations
• The code has been formatted using Ruff (ruff format homeassistant tests)
• Tests have been added to verify that the new code works.
• Any generated code has been carefully reviewed for correctness and compliance with project standards.

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated for www.home-assistant.io

If the code communicates with devices, web services, or third-party tools:

• The manifest file has all fields filled out correctly.
  Updated and included derived files by running: python3 -m script.hassfest.
• New or updated dependencies have been added to requirements_all.txt.
  Updated by running python3 -m script.gen_requirements_all.
• For the updated dependencies a diff between library versions and ideally a link to the changelog/release notes is added to the PR description.

To help with the load of incoming pull requests:

• I have reviewed two other open pull requests in this repository.

[Copilot]

Pull request overview

This PR factors shared review guidance out of the GitHub PR reviewer skill into a new general-purpose review skill, aiming to keep PR-review behavior consistent while enabling reuse outside GitHub PRs.

Changes:

• Added a new .claude skill (review) that defines general code review criteria, verification steps, and an output format.
• Updated github-pr-reviewer to delegate review behavior/instructions to the new review skill while keeping the GitHub-specific workflow steps.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
.claude/skills/review/SKILL.md	Introduces a reusable, general-purpose review skill with guidance and an output format.
.claude/skills/github-pr-reviewer/SKILL.md	Simplifies PR reviewer instructions by referencing the new review skill for review behavior.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

[justanotherariel]

Adding a clause to exclude formatting/lint-only issues is probably also not a bad idea.

[justanotherariel]

Suggested change

	- [CRITICAL] sensor.py:143 - Memory leak
	- [PROBLEM] data_processing.py:87 - Inefficient algorithm
	- [SUGGESTION] test_init.py:45 - Improve x variable name
	- [CRITICAL] rel/path/to/sensor.py:143 - Memory leak
	- [PROBLEM] rel/path/to/data_processing.py:87 - Inefficient algorithm
	- [SUGGESTION] rel/path/to/test_init.py:45 - Improve x variable name

Claude sometimes has the tendency to only write the filename, without the relative path to it. This is annoying because VSCode can detect filenames and can open them via CTRL+LClick, but doesn't know which e.g. __init__.py file to open.

[abmantis]

This was intentional eheh. It was making the summary harder to read when using the full path. Since you usually are working on a specific integration, you don't need the full path for files.

I've changed it now to be a markdown reference, so it still shows up nicely and should allow you to click in vscode (I haven't tested it since I don't use claude in vscode).