anchor.diff:    </tr>
     <tr>
       <th><code>BUILDKITE_PULL_REQUEST_REPO</code></th>
  -    <td>The repository URL of the third-party pull request. <p class="Docs__api-param-eg"><em>Example:</em> <code>"git://github.com/acme-inc/my-project.git"</code>, or <code>""</code> if not a pull request.</p></td>
  +    <td>The repository URL of the pull request. <p class="Docs__api-param-eg"><em>Example:</em> <code>"git://github.com/acme-inc/my-project.git"</code>, or <code>""</code> if not a pull request.</p></td>
     </tr>
     <tr>
       <th><code>BUILDKITE_REBUILT_FROM_BUILD_ID</code></th>
  
positive.code:     <td>The commit of the build. <p class="Docs__api-param-eg"><em>Example:</em> <code>"83a20ec058e2fb00e7fa4558c4c6e81e2dcf253d"</code></p></td>
    </tr>
    <tr>
      <th><code>BUILDKITE_JOB_ID</code></th>
      <td>Internal UUID Buildkite uses for this job. <p class="Docs__api-param-eg"><em>Example:</em> <code>"e44f9784-e20e-4b93-a21d-f41fd5869db9"</code></p></td>
    </tr>
  
negative.code: optional: variables set on a step in the UI or in a pipeline.yml file by you
  optional: variables set on a pipeline in the Pipeline Settings page by you
  
  - these are merged together in the following order of precedence:
  (maybe put an image or example code here)
  bk env (most important, not overridden by the following bits) > build > step > project (least important, can be overridden by everything else)
  
  - more details on setting vars in a pipeline.yml (update the image/example to add more info on the step bit of the process - pipeline.yml shared > step level):
  - there are two places in a pipeline.yml file that you can set env vars:
    - in the `env` attribute of command or trigger steps
    - at the top of the yaml file, before you define your pipeline's steps (this will set the defined variable on each of the command steps in the pipeline, and is equivalent to setting the `env` attribute on every step)
  
  - more details on setting vars in a Trigger step:
    - env vars set in a trigger step end up as build-level env on the newly created build
    - you can take advantage of interpolation to set vars for your trigger step's build that are already set in your current build 
  ```
  env:
  - FOO=bar
  steps:
  - trigger: some-pipeline
    build:
      env:
      - FOO=$FOO # triggered build will have `FOO=bar`
  ```
    - NOTE: the 'all steps env' from the top of a pipeline.yaml isn't applied to trigger steps, the only env that applies to trigger steps is what you choose to set in that trigger step's `env` attribute (which ends up as build env in the new build)
  
  ### Agent environment
  