diff --git a/README.md b/README.md
index a02b6543..d6e90ac6 100644
--- a/README.md
+++ b/README.md
@@ -101,7 +101,7 @@ _A few notes on `npm` config_:
 
 ## Plugins
 
-There are four steps where you can customize the `semantic-release` behavior using plugins. A plugin is a regular [option](#options), but inside the `package.json` you can pass additional config.
+There are numerous steps where you can customize `semantic-release`'s behaviour using plugins. A plugin is a regular [option](#options), but passed inside the `release` block of `package.json`:
 
 ```json
 {
@@ -151,6 +151,10 @@ This plugins is responsible for verifying that a release should happen in the fi
 
 This plugin is responsible for verifying a release that was determined before and is about to be published. There is no default implementation. It additionally receives `nextRelease`, `lastRelease` and `commits` inside `config`. While `commits` is the same as with analyzeCommits, `nextRelease` contains a `type` (e.g. `'major'`) and the new version (e.g. `'1.0.0'`) and `lastRelease` contains the old `version`, the `gitHead` at the time of the release and the npm dist-`tag` (e.g. `'latest'`). Using this information you could [detect breaking changes](https://github.com/semantic-release/cracks) or hold back certain types of releases. Again: Be creative.
 
+### `getLastRelease`
+
+This plugin is responsible for determining a package's last release version. The [default implementation](https://github.com/semantic-release/last-release-npm) uses the last published version on a npm registry.
+
 ## ITYM*FAQ*LT
 > I think you might frequently ask questions like these