| name | pr-review-considerations |
| description | Additional iTwin.js PR review heuristics focused on consumer impact, compatibility, invariants, UI evidence, and docs accuracy. |
PR Review Considerations
Use this skill when reviewing pull requests, preparing review guidance, or deciding what GitHub Copilot should pay attention to in this repository.
GitHub Copilot PR review on GitHub.com does not load repository skills directly. To influence GitHub review comments, keep the concise version of this guidance in .github/instructions/pr-review.instructions.md. GitHub's current repository instruction model also means that file can influence other Copilot interactions for matching files, not only PR review.
Review stance
These considerations supplement — not replace — standard code review practices. Continue checking for correctness, security, performance, and readability as you normally would. The guidance below adds iTwin.js-specific domain concerns on top of that baseline.
- In addition to standard review checks, prioritize issues likely to cause runtime regressions, consumer confusion, integration churn, or repeated reviewer back-and-forth.
- Skip pure style-only nits unless they hide a correctness problem or conflict with an established repo pattern.
- Prefer comments that explain why the issue matters to consumers, downstream apps, or maintainers.
What reviewers repeatedly look for
1. Consumer impact and compatibility
- For
package.json, peer dependency, or version bumps, ask whether each bump is necessary and whether the peer range can stay broader.
- Watch for unrelated dependency churn getting folded into a feature PR.
- If a change is declared safe because of fallback behavior, verify the fallback exists and ask for the exact helper or test when the proof is missing.
- For parser, persistence, schema, or serialization changes, check old-data compatibility and roundtrip behavior.