diff --git a/tips-tricks.md b/tips-tricks.md
index e8a02a2..0a216b0 100644
--- a/tips-tricks.md
+++ b/tips-tricks.md
@@ -3,7 +3,7 @@ pd-lib-builder cheatsheet
 
 # Creating special builds
 
-## building for non-native platform
+## Building for non-native platform
 
 Using pd-lib-builder >=0.6.0 we can define variable `PLATFORM` to specify a
 target triplet for cross-compilation. Assuming a W32 package for Pd is unzipped
@@ -11,7 +11,7 @@ into path `${PDWIN32}`, to build for Windows 32 bit:
 
     make PLATFORM=i686-w64-mingw32 PDDIR="${PDWIN32}"
 
-#### older pd-lib-builder versions
+#### Older pd-lib-builder versions
 
 Using pd-lib-builder < 0.6.0, in the absence of variable `PLATFORM`, you would
 instead override variables `system`, `target.arch`, `CC` and / or `CXX`,
@@ -19,7 +19,7 @@ instead override variables `system`, `target.arch`, `CC` and / or `CXX`,
 
     make system=Windows target.arch=i686 CC=i686-w64-mingw32-gcc STRIP=i686-w64-mingw32-strip PDDIR="${PDWIN32}"
 
-#### toolchains
+#### Toolchains
 
 To build for non-native OS and/or architecture you need a cross toolchain. On
 Linux such toolchains are relatively easy to get. For example Debian Buster
@@ -34,7 +34,7 @@ for a given platform to get the whole toolchain):
 Cross toolchains for OSX/MacOS are not generally distributed. Project
 `osxcross` from Thomas Poechtraeger can create them for Linux.
 
-## building double-precision externals
+## Building double-precision externals
 
 At the time of writing (2018-02) there is no official Pd that supports
 double-precision numbers yet.
@@ -43,24 +43,21 @@ easily build your externals for 64-bit numbers:
 
    make CPPFLAGS="-DPD_FLOATSIZE=64"
 
-## building externals for W64 (64-bit Windows)
+## Building externals for W64 (64-bit Windows)
 
 At the time of writing (2018-02) there is no official Pd that supports
 W64 yet.
 However, if you do get hold of an experimental W64 Pd, you can
 easily build your externals for this environment with
 
-   make CPPFLAGS="-DPD_LONGINTTYPE=__int64" CC=x86_64-w64-mingw32-gcc
-
+    make CPPFLAGS="-DPD_LONGINTTYPE=__int64" CC=x86_64-w64-mingw32-gcc
 
 To build a double-precision external for W64, use something like:
 
-   make CPPFLAGS="-DPD_LONGINTTYPE=__int64 -DPD_FLOATSIZE=64" CC=x86_64-w64-mingw32-gcc
-
+    make CPPFLAGS="-DPD_LONGINTTYPE=__int64 -DPD_FLOATSIZE=64" CC=x86_64-w64-mingw32-gcc
 
 ## TODO universal binaries on OSX
 
-
 # Project management
 
 In general it is advised to put the `Makefile.pdlibbuilder` into a separate
@@ -98,6 +95,7 @@ In short, `git subtree` is the better `git submodule`.
 So here's how to do it:
 
 #### Initial setup/check-out
+
 This will create a `pd-lib-builder/` directory containing the full history of
 the pd-lib-builder repository up to its release `v0.5.0`
 
@@ -109,6 +107,7 @@ This will automatically merge the `pd-lib-builder/` history into your current
 branch, so everything is ready to go.
 
 #### Cloning your repository with the subtree
+
 Nothing special, really.
 Just clone your repository as always:
 
@@ -117,6 +116,7 @@ git clone https://git.example.org/pd/superbonk~.git
 ~~~
 
 #### Updating the subtree
+
 Time passes and sooner or later you will find, that there is a shiny new
 pd-lib-builder with plenty of bugfixes and new features.
 To update your local copy to pd-lib-builder's current `master`, simply run:
@@ -126,6 +126,7 @@ git subtree pull --prefix pd-lib-builder/ https://github.com/pure-data/pd-lib-bu
 ~~~
 
 #### Pulling the updated subtree into existing clones
+
 Again, nothing special.
 Just pull as always:
 
@@ -133,8 +134,8 @@ Just pull as always:
 git pull
 ~~~
 
-
 #### Further reading
+
 More on the power of `git subtree` can be found online
 - https://medium.com/@v/git-subtrees-a-tutorial-6ff568381844
 - https://www.atlassian.com/blog/git/alternatives-to-git-submodule-git-subtree
@@ -142,8 +143,8 @@ More on the power of `git subtree` can be found online
 
 ### ~~`git submodule`~~ [DISCOURAGED]
 
-
 #### Initial setup/check-out
+
 To add a new submodule to your repository, just run `git submodule add` and
 commit the changes:
 
@@ -170,6 +171,7 @@ git submodule update
 ~~~
 
 #### Updating the submodule
+
 Submodules are usually fixed to a given commit in their repository.
 To update the `pd-lib-builder` submodule to the current `master` do something
 like:
@@ -184,6 +186,7 @@ git commit pd-lib-builder -m "Updated pd-lib-builder to current master"
 ~~~
 
 #### Pulling the updated submodule into existing clones
+
 After you have pushed the submodule updates in your repository, other clones of
 the repository can be updated as follows:
 
@@ -213,6 +216,7 @@ git submodule update
 ~~~
 
 #### Drawbacks
+
 `git submodule` has a number of drawbacks:
 - it requires special commands to synchronize the submodules, in addition to
   synching your repository.
@@ -228,4 +232,3 @@ git submodule update
 
 In general, I would suggest to **avoid** `git submodule`, and instead use the
 better `git subtree` (above).
-