PR rewords, new images

custom-dictionary.txt

@@ -44,4 +44,6 @@ mimecast
 slugified
 dlist
 DEPENDENCYID
-MTTR
+MTTR
+terrapatch
+Terrapatch

docs/2.0/docs/patcher/concepts/patches.md

@@ -42,7 +42,7 @@ Patcher will suggest changes to your codebase in order to keep your infrastructu
 
 Here is an example of what your PR will look like, after being generated by Patcher:
 
-** insert image of PR screenshot **
+![Patcher PR Example](/img/patcher/pr-example.png)
 
 ### Update Push Strategy
 
@@ -51,7 +51,7 @@ Using the GitHub action, PRs will be opened against your codebase on a cadence s
 The intention with this GitHub action is to leave the repo owner in full control of your upgrade cadence. 
 
 <details>
-  <summary>The example configuration is long. Click to expand!</summary>
+  <summary>GitHub Actions Workflow Example</summary>
 
   ```yaml
 name: Update Dependencies
@@ -140,7 +140,7 @@ jobs:
 </details>
 <br/>
 
-Also, check out our guide on [promotion workflows](../guides/promotion-workflows), so that updates can proceed from `dev` to `stage` to `prod` (or any other environment sequence) to mitigate risks around upgrades. 
+Also, check out our guide on [promotion workflows](/2.0/docs/patcher/guides/promotion-workflows), so that updates can proceed from `dev` to `stage` to `prod` (or any other environment sequence) to mitigate risks around upgrades. 
 
 ### Update Pull Strategy
 
@@ -149,11 +149,11 @@ The first step is to run `patcher update` within the repo in which updates are d
 When `patcher update` is run, the default mode is to click through the updates **interactively**. 
 In this mode, available updates are found, and the details of those updates are presented to you:
 
-** insert image here **
+![Patcher Update Interactive Mode](/img/patcher/interactive-update.png)
 
 You can choose to run in `--non-interactive` mode, which will modify the codebase and present results about what the program did at the end. 
 
-Interactively nor not, by default, a PR will _not_ be opened with the changes.
+By default a PR will _not_ be opened with the changes.
 However, the changes should be visible within the version control system. At that point, you may make a PR or apply the changes using your IaC system.
 
 ### Examples Running `patcher update`
@@ -162,7 +162,7 @@ Here's the easiest way to run this command:
 
 ```bash
 $ cd <repo-root-directory>
-# give me ALL the patches for ALL the things
+# Show what patches are available for everything in the current directory and all it's children
 $ patcher update ./
 ```
 
@@ -173,7 +173,7 @@ If more fine-grain controls are desired, the following example has those:
 $ patcher update --update-strategy next-safe --non-interactive --publish --pr-branch grunty/update-via-patcher --pr-title "[Patcher] Update All Dependencies to Next Safe"
 ```
 
-More details on the available options included in `patcher update` can be found in the [reference section](../../../reference/patcher/index.md#update). 
+More details on the available options included in `patcher update` can be found in the [reference section](/2.0/reference/patcher/index.md#update). 
 
 ## For Module Authors
 
@@ -182,7 +182,7 @@ With patches, module authors include a patch YAML file that automatically update
 Doing so allows module consumers to use patches to enable their modules consumers to automatically update consuming code to adopt breaking change.
 
 In a Patcher ecosystem, the resolution to such a change is written once, in a patch, and distributed to all consumers. 
-Although your release will succeed with or without a patch, downstream consumers of your breakig change will praise you thoroughly for your advance work. 
+Although your release will succeed with or without a patch, downstream consumers of your breaking change will praise you thoroughly for your advance work. 
 
 In theory, you may write whatever command execution steps you want to perform patch steps. 
 For example, there are many cases where validating tool versions are required, or using `sed` to find and replace certain values.