PR Checklist

A short pre-flight before you hit “Create pull request” on a public REX module. It mirrors the PR template the repo itself will show you; this is just the version you can read before opening the PR rather than while filling it out.

Note

Do you actually want to open a PR? Opening a PR is one of two valid paths. If your change is only for your own study, you can keep it on a private fork and pin your extension’s package.json at that fork (no PR required). See Two Paths. The rest of this page assumes you want to upstream the change.

---

The one decision only you can confirm

• I can say in one sentence which module the change belongs in and why that is the right level of generality. Placement is the #1 reason PRs get sent back. If this sentence is fuzzy, pause and re-read Getting Placement Right before opening the PR.

Everything else on this page is something you (and, if you used one, your AI assistant) can confirm together. The placement call is yours.

---

What the PR template will ask you for

When you open the PR, GitHub will pre-fill the description with the project’s PULL_REQUEST_TEMPLATE.md. Have answers ready for:

• Summary: one or two sentences: what does this PR do and why?
• Related issue: link the issue this addresses, if there is one. For anything larger than a small fix, CONTRIBUTING.md asks you to open an issue first.
• Changes: a brief list of what changed.
• Testing: how did you test this? At minimum: you built the module into an extension (rex-demo or your own) and exercised the change in Chrome or Edge.
• AI use disclosure: were AI tools used to write code in this PR? If yes, name the tools and rough scope. The template has checkboxes for both options; pick the one that is true.

---

Things to confirm before you click

• One logical change. If you find yourself writing “and also” in the summary, split it into two PRs.
• You built and tested it. Pointing rex-demo (or your own extension) at your feature branch via package.json, running the build, and loading the unpacked extension. If you cannot say “it works in a real browser,” the PR is not ready.
• No .env files, secrets, plan files, or local file:../... paths in the diff.
• You can explain every line in code review. Especially if you used AI assistance: by checking the AI disclosure boxes in the template, you are confirming you reviewed and understand the generated code.
• You will be around to respond to review. A BRIC maintainer will leave comments. Quick back-and-forth is what makes a PR land; ghosting it does not.

---

What happens after you open the PR

• CLA Assistant will comment on your first-ever PR with a link to sign BRIC’s Contributor License Agreement. It is a one-click sign-in with GitHub, and it covers all your future contributions to any BRIC repo.
• A BRIC maintainer will review. Expect at least one round of feedback. We try to respond within two weeks; if you have not heard back by then, feel free to ping the PR.
• Disagreements are normal. If review asks for a change you do not understand or do not agree with, push back with technical reasoning. You may know something we do not, and vice versa.

---

If you miss something on this list

Almost everything is recoverable in review: the maintainer points it out, you push a fixup commit. The one exception is placement: once a feature ships in the wrong module, moving it later is a coordinated change across every extension that depends on it. That is why placement is at the top of this page and why Getting Placement Right is the document we ask contributors to read first.