anchor.diff:  
   ## Developing a plugin
   
  -The best place to get started is the [Buildkite Plugins] repository, or [third-party plugins with the `buildkite-agent` tag][third party plugins].
  +The best place to get started is the [Buildkite Plugins] repository. You can also find third-party plugins with the `buildkite-agent` tag [on GitHub][third party plugins].
   
   We mostly write our plugins as shell scripts, so we've created a [plugin tester]
   docker image that simplifies writing BATS tests and getting your plugin tested (so meta).
   
   ### Anatomy of a plugin
   
  -Plugins are essentially a collection of hooks with some metadata. The agent parses
  -the plugin configuration and passes it on to the plugin in a slightly normalized form,
  -both as JSON or environment variables.
  +Plugins are essentially a collection of hooks with extra configuration. The agent parses the plugin configuration and passes it on to the plugin in a slightly normalized form, both as JSON or environment variables.
   
   This means that you can write a plugin as a shell script, or as a binary.
   
  -A minimal plugin has a plugin.json at it's root:
  +A minimal plugin has a `plugin.json` at it's root:
   
   ```json
   {
  
positive.code: 
   * Apply special care in plugins to avoid executing arbitrary code passed in by config. As these are just environment variables, anything that can set environment variables can mess with plugin configuration.
  
  For particularly high-security setups, you can disable plugins selectively by removing them from the `BUILDKITE_PLUGINS` variable in your `environment` hook.
  
  ## We love feedback!
  
  Agent plugins are still new, and we are evolving them as we learn more. We'd love feedback on how you use them and how we might make them better.
  
  
negative.code: 
  The agent parses the plugin block and passes the parameters through to the script as environment variables in the form `BUILDKITE_PLUGIN_{NAME}_{KEY}`, or if a list is provided then `BUILDKITE_PLUGIN_{NAME}_{KEY}_{IDX}`.
  
  Plugins are also able to offer `command` and `environment` hooks, which aren't allowed in per-project hooks. This lets plugins change how commands are executed entirely.
  
  ## Security and Reliability
  
  Plugins introduce a third-party dependency in your pipeline. They provide a way to introduce executable code into your pipeline beyond scripts in your repository and access to the `pipeline.yml`.
  
  Security practices that we recommed:
  
   * Always pin to a particular version of the plugin, e.g. `docker-compose#287293c4`. You can refer to any git ref. The agent will check this out the first time it encounters it and then re-use that checked out code.
  
  