anchor.diff:  
   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}`.
   
  -This lets a script supplement the [standard environment variables] that the agent provides to any script with structured configuration from the plugin definition.
  -
   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
   
  -One issue with plugins is that they introduce a third-party dependency in your pipeline. They provide a new way to introduce executable code into your pipeline beyond scripts in your repository and access to the pipeline.yml.
  +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`.
   
  -The practices that we follow are:
  +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.
   
  
positive.code: 
  ## 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].
  
  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.
  
  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:
  
  ```json
  {
  
negative.code: 
  # Buildkite Agent Plugins
  
  Plugins provide a way to extend the functionality that Buildkite natively offers. They act as a external repository of [Hooks][hooks] that are referenced from your `pipeline.yml` file, downloaded and run as part of your builds.
  
  Plugins can be hosted on GitHub, BitBucket or a private git repository, and are automatically fetched as required.
  
  Buildkite offers a [collection of useful plugins][Buildkite Plugins]
  to get you started, including a [docker-compose plugin] and a plugin for [secure secrets storage][s3-secrets plugin] on Amazon S3.
  
  <%= toc %>
  
  ## Using a plugin
  
  Plugins are only available for [pipelines] using `pipeline.yml` files.
  
  Plugins can be used in two ways:
  
  * as a standalone step, performing an operation
  * as a library, making commands available to that step's script 
  
  An example of what a plugin might look like in your code:
  
  ```yml
  steps:
    - plugins:
        detect-clowns#v2.0.0: ~
  ```
  
  This example will install the `buildkite-plugins/detect-clowns-buildkite-plugin` when your pipeline runs this build step.
  
  Plugins are automatically fetched from where they are hosted, based on the name of the project. See [Plugin sources] for how you can host your own.
  
  A real-life example is the [docker-compose plugin]. It provides an integration
  with docker-compose that assists with running your builds within a docker environment:
  