README.md in mayday-0.1.1 vs README.md in mayday-0.1.2

@@ -76,10 +76,14 @@
 * `files` limits to files that have an absolute path that matches the provided [globs](http://en.wikipedia.org/wiki/Glob_(programming)). Accepts an array.
   * `warning_regex "Foo!", /^barbaz$/, :files => ["*.h"] do ...`
 * `exclusions` doesn't run on files that have an absolute path that matches the provided [globs](http://en.wikipedia.org/wiki/Glob_(programming)). Accepts an array.
   * `warning :line, :exclude => ["*/Pods/*"] do ...` **Note, Pods are excluded by default by mayday**
 
+## Cookbook
+
+For some ideas on how to start using mayday, see the [cookbook](https://github.com/marklarr/mayday/blob/master/docs/Cookbook.md)
+
 ## Benchmarking
 
 You may be concerned about how much overhead this will add to your build process. To see how quickly your `mayday` checks execute, use 
 
 ```sh
@@ -91,10 +95,9 @@
 * `mayday` uses [sourcify](https://github.com/ngty/sourcify) to write your custom `warning` and `errors` blocks to a build phase, all [gotchas in sourcify](https://github.com/ngty/sourcify#gotchas) apply to your blocks.
 * `mayday` copies your custom blocks, line for line, into a build phase, so all variables inside of them must be of local scope. Anything defined outside of a custom block will not be included in the build phase.
 * Gems cannot be used inside of custom blocks, only vanilla, system Ruby.
 * If your custom blocks have errors in them that aren't found until they're executed (which is done whenever you call `mayday`), the stack trace won't be very helpful in debugging (because there is no source map from the build phase back to your `Maydayfile` code)
 * Generating efficient code to write into the build phase is difficult. The code generated by `MayDay::ScriptGenerator#to_ruby` could definitely be optimized.
-
 
 ## Uninstallation
 
 ```sh
 $ mayday down