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:         emojis: 🤡
  ```
  
  This example will install [buildkite-plugins/detect-clowns-buildkite-plugin](https://github.com/buildkite-plugins/detect-clowns-buildkite-plugin) and run it for this build step.
  
  You could just as easily write your own plugin on GitHub at `myusername/blah-buildkite-plugin` and it would be available as `myusername/blah` in your pipeline.yml.
  
  Another example of something that we use every day is the [docker-compose](https://github.com/buildkite-plugins/docker-compose-buildkite-plugin) plugin. It makes it easy to run docker-compose in your build steps:
  
  ```yml
  steps:
  
negative.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. 
  
  ## Plugin sources
  
  If you refer to a plugin just by name (say `detect-clowns`), it defaults to 
  https://github.com/buildkite-plugins/detect-clowns-buildkite-plugin. If you used 
  `myorg/detect-clowns` it would be https://github.com/myorg/detect-clowns-buildkite-plugin. 
  
  You can also use a fully qualified git repository name like `https://github.com/buildkite-plugins/detect-clowns-buildkite-plugin.git` or `git@github.com:foo/bar.git#v1.3`, which 
  lets you refer to your own private git repositories. Branches, tags and commits 
  are all valid after the `#`. 
  
  We recommend that plugins be pinned to a specific version to prevent behaviour 
  changing unexpectedly. This is done with a git tag of `vX.X.X`. 
  
  ## Developing a 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).
  
  ### 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.
  
  