> [!TIP]
> Before submitting a Pull Request, please consider the following to speed up reviews:
> - 👷‍♀️ Create small PRs. Large PRs can usually be broken down into incremental PRs.
> - 🚩 Do you already have several open PRs? Consider finishing or asking for help with existing PRs first.
> - 🔧 Does your PR reference a discussed and approved issue, especially for personal or edge-case requests?
> - 💡 Is the solution agreed upon? Save rework time by discussing strategy before coding.

## Description

_Describe what your PR accomplishes. Consider walking through the main changes to aid reviewers in following your code, especially if it covers multiple files._

## Related Issues or Discussions

> [!CAUTION]
> If no issue exists yet, create it, and get agreement on the approach (or paste in a previous agreement from chat, etc.) before moving forward. (Experimental PRs are OK without prior discussion, but do not expect to get merged.)

- Closes #

## QA Instructions, Screenshots, Recordings

_Replace this line with instructions on how to test or view your changes, as well as any before/after
screenshots or recordings for UI changes._

### Reviewer Checklist

_Replace the list below with specific features you want reviewers to look at._

*Reviewers, refer to this list when testing features, or suggest new items *
- [ ] Verify new features are functional
  - [ ] Feature A does X
  - [ ] Feature B does Y
- [ ] Verify old features have not broken
  - [ ] Feature Z can still be used
- [ ] Test for edge cases / try to break things
  - [ ] Feature A handles negative numbers
- [ ] Identify opportunities for simplification and refactoring
- [ ] Check for code legibility and appropriate comments