diff --git a/.github/workflows/snyk-pull-requests.yml b/.github/workflows/snyk-pull-requests.yml
new file mode 100644
index 0000000..da803e0
--- /dev/null
+++ b/.github/workflows/snyk-pull-requests.yml
@@ -0,0 +1,16 @@
+name: Review Snyk Pull Requests
+
+on:
+  workflow_call:
+
+jobs:
+  assign-pullerbear:
+    if: startsWith(github.head_ref, 'snyk-')
+    runs-on: blacksmith-2vcpu-ubuntu-2404
+    steps:
+      - name: Assign PullerBear for Snyk PR reviews
+        # v0.5
+        uses: nikosmoum/auto-assign-reviewer-team@c75b7f88a2b0ab0b6ca63ba5c49557256a32c6bb
+        with:
+          teamName: "pullerbear"
+          githubToken: ${{ secrets.MELVIN_GH_TOKEN }}
diff --git a/README.md b/README.md
index fd85a3d..3222fdc 100644
--- a/README.md
+++ b/README.md
@@ -1,4 +1,4 @@
-# Expensify Shared GitHub Actions workflows 🔄 
+# Expensify Shared GitHub Actions workflows 🔄
 
 ## What is the repository used for?
 
@@ -18,13 +18,31 @@ jobs:
     with:
       # Repository name with owner. For example, Expensify/eslint-config-expensify
       # Required, String, default: ${{ github.repository }}
-      repository: ''
+      repository: ""
 
       # True if we should run npm run build for the package
       # Optional, Boolean, default: false
       should_run_build: true
 ```
 
+### `snyk-pull-requests.yml`
+
+Assigns PullerBear reviewers when a Snyk bot opens a pull request. Should be triggered when a pull request is opened.
+
+```yml
+on:
+  pull_request:
+    types:
+      - opened
+
+jobs:
+  snyk-pull-requests:
+    uses: Expensify/GitHub-Actions/.github/workflows/snyk-pull-requests.yml@main
+    secrets: inherit
+```
+
+Requires the `MELVIN_GH_TOKEN` secret.
+
 ### `cla.yml`
 
 Used to check if a user has signed the [Contributor License Agreement](./CLA.md), Should be triggered when a PR is opened or updated.
@@ -38,12 +56,13 @@ jobs:
 ```
 
 ## Rulesets
+
 GitHub [org-level rulesets](https://docs.github.com/en/enterprise-cloud@latest/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets#require-workflows-to-pass-before-merging) can be configured to run a workflow check against pull requests in all repos in the org. This is a very powerful feature, but there are some caveats and best practices to be aware of when enabling a ruleset.
 
 - Supported Event Triggers are documented [here](https://docs.github.com/en/enterprise-cloud@latest/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets#supported-event-triggers). However:
-    - When a workflow runs in response to a ruleset, some configs such as `branches`, `paths`, `paths-ignore`, that would normally be valid in a workflow are ignored.
-    - The default activity types for each event will be used. This means that something like `pull_request:comment` will not work - the `pull_request` event will always be triggered for the default activity types listed in the documentation.
-    - If you need to target or exclude specific branches, that can be configured in the ruleset settings.
-    - If you need to target or exclude specific paths, that must be implemented manually in the workflow itself.
+  - When a workflow runs in response to a ruleset, some configs such as `branches`, `paths`, `paths-ignore`, that would normally be valid in a workflow are ignored.
+  - The default activity types for each event will be used. This means that something like `pull_request:comment` will not work - the `pull_request` event will always be triggered for the default activity types listed in the documentation.
+  - If you need to target or exclude specific branches, that can be configured in the ruleset settings.
+  - If you need to target or exclude specific paths, that must be implemented manually in the workflow itself.
 - Due to a GitHub :bug:, PRs that are open when the rule is enabled will get stuck with a pending check that will never get picked up. The easiest way to fix that is to close and reopen the PR. Consider writing a script to close and reopen all open PRs across the org after the check is enabled.
 - It is less disruptive to [configure the ruleset to `Evaluate` first](https://docs.github.com/en/enterprise-cloud@latest/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets#using-evaluate-mode-for-ruleset-workflows), then `Active` once the kinks are worked out.