diff --git a/README.md b/README.md
index 2a322fa..e786c52 100644
--- a/README.md
+++ b/README.md
@@ -1,6 +1,8 @@
 # Efficient Development
 Rules to live by. Written using GitLab, git, and Jira terminology, but generalizable to any software development tools.
 
+Efficient development minimizes total pain and suffering across the whole software lifecycle. As such, the return on these behaviors grows as the use of the software grows, in number of use cases, number of users, number of developers and maintainers, number of interfaces to external code and teams, and number of months or years that we expect the software to exist and be relevant.
+
 - Use [trunk based development](https://trunkbaseddevelopment.com/) and avoid multiple persistent branches
 - Integrate early and often (continuously)
 - Give everyone (even people outside your team) developer access and don't attempt to control what they do
@@ -13,13 +15,14 @@ Rules to live by. Written using GitLab, git, and Jira terminology, but generaliz
   - MRs avoid the misinterpretation that often happens when playing telephone through email ➡ chat ➡ Jira ➡ git
   - Jira tickets are useful as a promise to do some work in the future that we don't have time to do now
     - Only if you actually promise to do that work
-  - Clear and comprehensive MR descriptions are far more important than individual commit messages
-    - Updating the MR description costs nothing, work on continuously improving it
-    - [GIFs](https://gifcap.dev/) in MR descriptions are incredibly powerful persistent demos
-- If a Jira ticket exists, reference it in MR description to automatically link and optionally close upon completion
+- If a Jira ticket exists, reference it in the MR description to automatically link and optionally close upon completion
 - Make your work visible
   - Open draft MRs extremely early (even just a README update saying what you're going to go do) to allow early review and course correction
   - Commit and push frequently
+- Clear and comprehensive MR descriptions are far more important than individual commit messages
+  - Updating the MR description costs nothing, work on continuously improving it
+  - Focus on [why (and why not), not how](https://cbea.ms/git-commit/#why-not-how), providing context and [theory](https://pablo.rauzy.name/dev/naur1985programming.pdf) that isn't already visible in the diff
+- Do not publish or burden others with reading something generated that you haven't validated and synthesized yourself
 - Keep MRs small
 - Keep branches short-lived and merge from main frequently
 - Match existing code
@@ -27,7 +30,6 @@ Rules to live by. Written using GitLab, git, and Jira terminology, but generaliz
 - Drive MRs to closure before opening new ones
   - Unless you find a bug that can be spun off and completed via a smaller incremental MR sooner
 - Make time to review teammates' MRs on a recurring basis
-  - Like while waiting on review of your MR and after you finish it before you start the next one
 - Resolve MR concerns efficiently
   - Developers are empowered to resolve threads about typos when they make the fix
   - Larger / open-ended / architectural concerns shall be resolved by the originator of the thread (only)
@@ -43,7 +45,7 @@ Rules to live by. Written using GitLab, git, and Jira terminology, but generaliz
 - Establish coding standards early and automate enforcement
   - Don't spend any time arguing about coding standards that aren't automatically enforced
 - Checklists are useful, only for things that can't be automated
-- Don't build or rely on anything that you aren't willing and able to maintain
+- Don't promote or rely on anything that you aren't willing and able to maintain
   - You aren't able to maintain plain text documentation of source code ... autogenerate it instead
   - You aren't able to maintain complex shell scripts
   - You aren't able to maintain anything that doesn't have tests