README.md in heroku_hatchet-7.2.0 vs README.md in heroku_hatchet-7.3.0

@@ -523,11 +523,11 @@
 end
 ```
 
 In this example, the app would use the nodejs buildpack, and then `:default` gets replaced by your Git url and branch name.
 
-- before_deploy (Block): Instead of using the `tap` syntax you can provide a block directly to hatchet app initialization:
+- before_deploy (Block): Instead of using the `tap` syntax you can provide a block directly to hatchet app initialization. Example:
 
 ```ruby
 Hatchet::Runner.new("default_ruby", before_deploy: ->{ FileUtils.touch("foo.txt")}).deploy do
   # Assert stuff
 end
@@ -628,10 +628,27 @@
 
 Hatchet::Runner.new("default_ruby", before_deploy: before_deploy_proc).deploy do |app|
 end
 ```
 
+You can call multiple blocks by specifying (`:prepend` or `:append`):
+
+```ruby
+Hatchet::Runner.new("default_ruby").tap do |app|
+  app.before_deploy do
+    FileUtils.touch("foo.txt")
+  end
+
+  app.before_deploy(:append) do
+    FileUtils.touch("bar.txt")
+  end
+  app.deploy do
+  end
+end
+```
+
+
 - `app.commit!`: Will updates the contents of your local git dir if you've modified files on disk
 
 ```ruby
 Hatchet::Runner.new("python_default").deploy do |app|
   expect(app.output).to match(/Installing pip/)
@@ -658,10 +675,10 @@
 ```
 
 > Note: If you want to execute tests in this temp directory, you likely want to use `in_directory_fork` otherwise, you might accidentally contaminate the current environment's variables if you modify them.
 
 - `app.in_directory_fork`: Runs the given block in a temp directory and inside of a forked process, an example given above.
-- `app.directory`: Returns the directory of the example application on disk, this is NOT the temp directory that you're currently executing against. It's probably not what you want.
+- `app.original_source_code_directory`: Returns the directory of the example application on disk, this is NOT the temp directory that you're currently executing against. It's probably not what you want.
 - `app.deploy`: Your main method takes a block to execute after the deploy is successful. If no block is provided, you must manually call `app.teardown!` (see below for an example).
 - `app.output`: The output contents of the deploy
 - `app.platform_api`: Returns an instance of the [platform-api Heroku client](https://github.com/heroku/platform-api). If Hatchet doesn't give you access to a part of Heroku that you need, you can likely do it with the platform-api client.
 - `app.push!`: Push code to your Heroku app. It can be used inside of a `deploy` block to re-deploy.
 - `app.run_ci`: Runs Heroku CI against the app returns a TestRun object in the block