diff --git a/src/posts/2025/2025-05-14-azure-locations.md b/src/posts/2025/2025-05-14-azure-locations.md
index d10e0ce7..50266c50 100644
--- a/src/posts/2025/2025-05-14-azure-locations.md
+++ b/src/posts/2025/2025-05-14-azure-locations.md
@@ -2,7 +2,7 @@
 title: azure locations and file crawling
 image:
   src: 2025/azure-locations.jpg
-  alt: "A Linux terminal. There is a fun rainbow flag in ascii art at the top, and then the user has called a command asking Azure for a list of resources applicable to a specific resource type"
+  alt: "A Linux terminal. There is a fun rainbow flag in ascii art at the top, and then the user has called a command asking Azure for a list of locations applicable to a specific resource type. The output is lengthy."
 tags:
   - reference
   - software
@@ -75,7 +75,7 @@ Okay, let's backtrack. From a given Bicep file, we want:
 1. All referenced resource types
 1. All referenced modules
 
-### grep
+### `grep`
 
 Resources and modules both have patterns in how they are declared. Thankfully, they're pretty simple regexes. `grep` will spit out lines in a file that match a given regex.
 
@@ -89,7 +89,7 @@ grep -E "^resource " "$file"
 grep -E "^module " "$file"
 ```
 
-### cut
+### `cut`
 
 From there, let's use `cut` to strip off the parts we don't want.
 
@@ -108,7 +108,7 @@ grep -E "^module " "$file" \
 
 These calls are a little opaque. `-d` sets a **delimiter** (what to split on). `-f` picks a **field** to return, numbered from 1.
 
-### mapfile
+### `mapfile`
 
 We'll save these values to variables. `mapfile` reads a file, putting each line into a new array element. `-t` **trims** newline characters. The `<`s do some redirection, and yes, the space between them *matters*.
 
@@ -120,7 +120,7 @@ mapfile -t modules < <(grep -E "^module " "$file" \
     | cut -d "'" -f 2 -)
 ```
 
-### dirname (& more)
+### `dirname` (& more)
 
 We can't just stop there. We need to search each module in turn. Using `dirname`, we can get the directory of the file we're searching, then append the relative module path.
 
@@ -143,7 +143,7 @@ Additionally, `mapfile` usually writes from index 0 onwards. But with the `-O` a
 
 Finally, we got some recursion going! `get_resources` calls `get_resources` for every module found.
 
-### the get_resources function
+### the `get_resources` function
 
 So far, our code looks like this:
 
@@ -176,7 +176,7 @@ Now we need to use these resource types to get available locations. First, actua
 mapfile -t resources < <(get_resources "main.bicep")
 ```
 
-### sort
+### `sort`
 
 Does sorting matter? Not really, but `sort` has a useful feature, `-u`, which returns **u**nique items (aka, it deduplicates). Looking up the same resource type twice slows us down.
 
@@ -186,7 +186,7 @@ mapfile -t resources < <(get_resources "main.bicep" | sort -u)
 
 `sort` is one reason it helps to have newlines as delimiters - it expects that.
 
-### az
+### `az`
 
 We'll use `az` to list *all* the locations - just to give ourselves a starting point. You could also use the locations for the first resource type.
 
@@ -205,7 +205,7 @@ mapfile -t newLocations < <(az provider show --namespace "$namespace" \
 
 `--out tsv` means we will get a list with no decoration whatsoever - it's vital for programmatic handling of `az` command output.
 
-### cut (again)
+### `cut` (again)
 
 We'll need to get those `$namespace` and `$resourceType` variables. `cut` comes back in handy:
 
@@ -221,7 +221,7 @@ namespace=$(echo "$resource" | cut -d "/" -f 1 -)
 resourceType=$(echo "$resource" | cut -d "/" -f 2 -)
 ```
 
-### comm
+### `comm`
 
 Okay, we can get locations. How do we handle finding their intersection?
 
@@ -248,7 +248,7 @@ then
 fi
 ```
 
-### tee
+### `tee`
 
 We'll print the locations to the shell. We can even use `tee` to print them to a file for good measure:
 
diff --git a/src/posts/2026/2026-01-05-moving-images.md b/src/posts/2026/2026-01-05-moving-images.md
index 11300280..52c451c1 100644
--- a/src/posts/2026/2026-01-05-moving-images.md
+++ b/src/posts/2026/2026-01-05-moving-images.md
@@ -16,7 +16,7 @@ so it's time to move them into year-based folders. Let's talk about how I did th
 
 (want to [skip right to the completed script?](#result))
 
-## find
+## `find`
 
 let's start with the basics: a list of posts. `find` gets us everything under a specific directory - in this case, the `_posts` directory. We can filter out the directories a few different ways, but I piped the `find` output through a basic `grep` looking for `.md` in the filename.
 
@@ -27,7 +27,7 @@ do
 done
 ```
 
-## grep
+## `grep`
 
 `grep` can also help us get image names with the regex `"name:.+jpg|png"`. I add `name:` to the regex because there are *very occasionally* images that aren't the featured image for the post, and those don't fit the pattern of `name: <img>`. Since there's so few of those, I ended up handling them manually.
 
@@ -40,7 +40,7 @@ to make `grep` work with regex, it needs the `-E` flag.
 IMAGE_LINE=$(cat $FILE | grep -E "name:.+jpg|png$")
 ```
 
-## cut
+## `cut`
 
 that output gets us the full line of text that includes the image filename. Let's trim out what we actually want.
 
@@ -62,7 +62,7 @@ with `cut`, we can also get the year of the post:
 YEAR=$(echo $FILE | cut -d '/' -f 2 -)
 ```
 
-## sed
+## `sed`
 
 there's two major things we need to do with the information we've gathered:
 
@@ -77,7 +77,7 @@ by default, `sed` prints to standard output, so we'll tell it to edit in-place i
 sed "s,$IMAGE,$YEAR/&," -i $FILE
 ```
 
-## mving and shaking
+## `mv`ing and shaking
 
 (my mom thinks I'm funny.)
 
diff --git a/src/posts/2026/2026-01-07-intro-to-git.md b/src/posts/2026/2026-01-07-intro-to-git.md
index da6e74d5..a019a32a 100644
--- a/src/posts/2026/2026-01-07-intro-to-git.md
+++ b/src/posts/2026/2026-01-07-intro-to-git.md
@@ -18,12 +18,12 @@ alrighty, this one's a real doozy. Strap in.
 - [problem statement](#problem-statement)
 - [what is git?](#what-is-git)
 	- [where can I use git?](#where-can-i-use-git)
-        - [what is a CLI?](#what-is-a-cli)
+		- [what is a CLI?](#what-is-a-cli)
 	- [where can I use the git CLI?](#where-can-i-use-the-git-cli)
-        - [git for Windows](#git-for-windows)
-        - [WSL](#wsl)
+		- [git for Windows](#git-for-windows)
+		- [WSL](#wsl)
 		- [a few terminal operations](#a-few-terminal-operations)
-        - [edit files](#edit-files)
+		- [edit files](#edit-files)
 - [git version](#git-version)
 	- [a few handy settings](#a-few-handy-settings)
 - [git going](#git-going)
@@ -81,13 +81,13 @@ finally, I wrote this walkthrough primarily with knowledge from using **WSL** [m
 
 that all said, let's get (git?) into it!
 
-## what is git?
+## what is `git`?
 
 `git` is a *version control system*. We can use it to track changes we make to a set of files.
 
 > tip: it's important to understand that despite the examples of MS Office and Google Docs above, `git` *isn't useful* with word documents. `git` shines with plain text files - .txt, .md, or basically any type of code.
 
-### where can I use git?
+### where can I use `git`?
 
 many, many tools interact with `git`:
 
@@ -101,7 +101,7 @@ today we're going to talk about the `git` CLI... technically. But **don't let th
 
 a CLI a way to interact with your computer and with software in text-only form. Rather than using the mouse and clicking on things, you type in commands and see output.
 
-### where can I use the git CLI?
+### where can I use the `git` CLI?
 
 if you want to use the `git` CLI, you'll need a terminal. You've got a couple options here:
 
@@ -112,7 +112,7 @@ if you want to use the `git` CLI, you'll need a terminal. You've got a couple op
 	- I use [Windows Subsystem for Linux, or WSL](https://learn.microsoft.com/en-us/windows/wsl/install){target="_blank" rel="external"}, which gives you a Linux distribution within Windows. It's pretty smooth sailing at this point, but there's some idiosyncracies to conquer - like the fact that your *Windows* files and your *Linux* files are stored in different places. If choosing WSL, [see my usage notes below](#wsl)
 - both of the Windows options listed work with [Windows Terminal](https://apps.microsoft.com/detail/9n0dx20hk701){target="_blank" rel="external"} which offers a nicer-looking terminal experience than the basic command prompt. If you're going to keep working with what you set up today, I recommend it!
 
-#### git for Windows
+#### `git` for Windows
 
 on the "Releases" page, scroll down to "Assets" and pick the `.exe` file.
 
@@ -161,7 +161,7 @@ we'll want to edit files, right? How do we open our editor from the terminal?
 
 there's usually a terminal command for the editor. For VSCode, it's `code`; for Zed, it's `zed`. If we want to open the *current directory* in our editor of choice (and we do!), we'll write `<editor command> .` (note the `.`), where `.` means "the current directory."
 
-## git version
+## `git version`
 
 let's check that you have git installed with `git version`. You might see something like `git version 2.34.1` printed out in response. If you don't get a version number, but instead get an error saying you don't have `git`, [install `git`](https://git-scm.com/install){target="_blank" rel="external"}.
 
@@ -196,9 +196,9 @@ git config --global user.name <your-name>
 git config --global user.email <your-email>
 ```
 
-## git going
+## `git` going
 
-(no, that's not a real `git` command)
+(no, that's not a real `git` command.)
 
 there's two main ways to start:
 
@@ -207,17 +207,17 @@ there's two main ways to start:
 
 > tip: `git` and associated tooling refer to projects as **repositories**. I'll be sticking with the word project here as I find it a bit friendlier, but you'll probably run across the word repository in the wider world of `git`
 
-### git init
+### `git init`
 
 `git init <project>` will create a new directory named `project` ready to be used with git. We can then use `cd <project>` to enter the directory.
 
 > tip: don't use spaces in your project name!
 
-### git clone
+### `git clone`
 
 `git clone <project URL>` will pull in an existing project. We're not going to talk about this right now; instead, we're going forward assuming with `git init`.
 
-## git status
+## `git status`
 
 before we do anything, let's see what `git` will tell us about our project. Type `git status` and we might see the following:
 
@@ -243,7 +243,7 @@ let's dissect this.
 
 a **commit** is one set of changes made to our work. We get to choose which changes are part of any given commit, and we write a message describing the commit so that future-us knows what we did if for some reason we need to undo something.
 
-### git log
+### `git log`
 
 in an established project, we can use `git log` to look at our **commit history**. By default, one commit will output like this:
 
@@ -304,7 +304,7 @@ Changes to be committed:
 
 *now* we're ready to create a commit!
 
-## git commit
+## `git commit`
 
 if we just write `git commit`, it'll open an editor for us to edit the **commit message** - our description of the changes. This can be handy if we want to write a lengthy description, but if we want to just write a one-liner, we can use `git commit -m "<message>"`. It's quicker and doesn't involve opening an editor.
 
@@ -351,7 +351,7 @@ Changes not staged for commit:
         modified:   file.txt
 ```
 
-### git restore
+### `git restore`
 
 `git restore` is new! That lets us get rid of our changes and go back to the last version of the file committed. Be careful with this - we should only do it if we *really* want to get rid of those changes.
 
@@ -364,7 +364,7 @@ git commit -m "added a new sentence"
 
 again, we can use `git status` or `git log` as needed.
 
-## git revert
+## `git revert`
 
 ooooh... I don't actually like that change. What if I want to undo something?
 
@@ -389,7 +389,7 @@ now we can try `git revert <commit-string>`. It'll open our editor to write a me
 
 I didn't edit the message - we can tell because it just says "Revert" and then the old commit message. But we can edit and add lots of detail about why we're doing it.
 
-## git remote
+## `git remote`
 
 let's try a new command: `git remote`. Hmm, nothing happened... what's a "remote"?
 
@@ -426,7 +426,7 @@ codeberg  https://codeberg.org/inherentlee/git-intro.git (push)
 
 cool! we have a remote set up. What does "fetch" and "push" mean?
 
-### git fetch (and git pull)
+### `git fetch` (and `git pull`)
 
 `git fetch` brings **remote** changes to our local machine. So does a command called `git pull`. Why are there two?
 
@@ -438,7 +438,7 @@ if we're working alone and *from one machine*, we'll pretty much never have to u
 
 for our use case, we can pretty safely stick to `git pull` (if we ever even need to use it!), but if you're working in a larger collaborative project, `git fetch` is your friend!
 
-### git push, take one
+### `git push`, take one
 
 `git push` is the opposite of `git pull` - it takes your local changes and adds them to the remote.
 
@@ -533,7 +533,7 @@ we'll notice that the SSH URL starts with `git@`, whereas the HTTPS URL started
 
 in order for all this to be useful, we need to tell Codeberg about our SSH key. In Codeberg, navigate to [settings, then find the left-hand tab for SSH keys](https://codeberg.org/user/settings/keys){target="_blank" rel="external"}. Choose 'Add key' and paste in the **public** key (if you set up that `sshcat` alias, use it now to output your key for ease of copying). Save and we'll now be set up to authenticate with SSH!
 
-### git push, take two
+### `git push`, take two
 
 we can now call `git push` again and again now without having to repeat our credentials every time. We can also call `git pull` for our private repositories.