Add an AI review skill to guide users

[ahuang11]

After a user finishes prompting the LLM, prior to creating a PR, they should use this skill to do a quick review, like pre-commit.

[Copilot]

Pull request overview

Adds a new “review” skill intended to help users do a quick AI-assisted code review (pre-PR / pre-commit style) by outlining a short checklist of review heuristics.

Changes:

• Introduces skills/review/SKILL.md with a purpose statement and review checklist.

[Copilot]

Checklist items are written as lower-case sentences, which is inconsistent with the established style in other skills (they generally use "DO"/"DON'T" phrasing and sentence-case bullets). Consider rewriting these bullets to match the existing skills formatting for consistency and readability.

Suggested change

	- [ ] when the attribute is known to be present, do not use `hasattr` & `getattr`
	- [ ] use try/except only on the clause that may raise the exception, not on the whole function
	- [ ] try to pin the exception type in the except clause, do not use a bare except
	- [ ] return or continue early to avoid deep nesting
	- [ ] anything over 3 levels of nesting should be refactored into helper functions
	- [ ] imports should be at the top of the file, not inside functions unless there is a specific reason to do so (slow import, circular import, etc.)
	- [ ] understanding the full changes, is there a more efficient or cleaner way to achieve the same result?
	- [ ] consistent and readable naming conventions, e.g. if FollowUpSuggestion is used, the variable name should be follow_up_suggestion, not followup_suggestion or follow_up_suggestions (plural)
	- [ ] DO avoid using `hasattr` and `getattr` when the attribute is known to be present.
	- [ ] DO apply `try`/`except` only to the clause that may raise the exception, not to the whole function.
	- [ ] DO pin the exception type in the `except` clause; DON'T use a bare `except`.
	- [ ] DO return or continue early to avoid deep nesting.
	- [ ] DO refactor code with more than three levels of nesting into helper functions.
	- [ ] DO place imports at the top of the file; DON'T place imports inside functions unless there is a specific reason (slow import, circular import, etc.).
	- [ ] DO consider the full set of changes and whether there is a more efficient or cleaner way to achieve the same result.
	- [ ] DO use consistent and readable naming conventions, e.g., if `FollowUpSuggestion` is used, the variable name should be `follow_up_suggestion`, not `followup_suggestion` or `follow_up_suggestions` (plural).

[philippjfr]

My overall comment here is that this is definitely useful but I'm not sure it belongs here. holoviz-mcp is currently user facing. We could decide to add developer facing skills but they'd have to be clearly delineated.