anchor.diff:  
   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.
   
  -## Writing your own Plugin
  -
  -The best place to get started is the [Buildkite Plugins](https://github.com/buildkite-plugins) repository, or [third-party plugins with the `buildkite-agent` tag](https://github.com/search?q=topic%3Abuildkite-plugin&type=Repositories).
  -
  -We mostly write our plugins as shell scripts, so we've created a [plugin tester](https://github.com/buildkite-plugins/plugin-tester) docker image that simplifies writing BATS tests and getting your plugin tested (so meta).
  -
   ## 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. 
  
positive.code:         run: app
  ```
  
  In the 2.x agent, this sort of thing was only possible by either using the limited docker environment variables, or writing a custom script. 
  
  ## 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.
  
  
negative.code:         emojis: 🤡
  ```
  
  This example will install [buildkite-plugins/detect-clowns-buildkite-plugin](https://github.com/buildkite-plugins/detect-clowns-buildkite-plugin) when your pipeline is evaluated and run it for 
  this build step.
  
  A real-life example is the [docker-compose](https://github.com/buildkite-plugins/docker-compose-buildkite-plugin) plugin. It provides an integration with docker-compose that assists with running 
  your builds within a docker environment:
  
  ```yml
  steps:
  