The git commands I avoided for nine years

Unknown — Fri, 15 May 2026 00:00:00 +0000

How I got here</h2>
For the majority of my time in tech, I used about six git commands: `add</code>, commit -m "wip"</code>, rebase -i</code>, commit --amend</code>, cherry-pick</code>, push</code>. Add, save, clean up the history, polish, and push. It worked, and it produced nice clean PRs.`
`When I first learned git in a software engineering bootcamp, the framing was unambiguous. Git was esssential but could be dangerous. You could lose work, and you should stay inside a small set of safe commands. Above all, don’t touch rebase while you’re learning. If you got into a mess with it, you were on your own.`
I eventually went to work on teams with other engineers, learned about collaborating on projects using git, added git rebase -i</code> to my toolkit, and felt pretty accomplished. My daily git commands worked for the most part… except for the few times when I’d do a bad rebase, and think I lost hours of work, despair and start over. Or get into a really tangled merge conflict and just end up deleting the branch and pulling down again from the remote. I thought that was the way it was; git was powerful with some rough edges.
`What changed this for me had nothing to do with git initially. Last year, I wanted to run two Claude Code sessions on the same repo on different branches at once, purely for parallelism. I didn’t know how to do this, because as far as I knew, you could only have one branch checked out for a repo at a given time on your computer.`
The fix turned out to be git worktree</code></a>, a git feature rather than anything to do with Claude Code. It also addressed a paper cut I’d been living with for years that I didn’t even realized I’d had: the stash-checkout-checkout-back-stash-pop dance every time I wanted to spin up a quick branch for a typo fix when I was in the middle of other work. Fixing a problem I hadn’t let rise to consciousness made me wonder what else was there and what I should incorporate into my toolkit.
The three commands</h2> I picked these three commands because they were the most directly useful ones that I found, and, in the case of git reflog, changed my view of git entirely. git worktree</code></h3> You’re mid-edit on a quickstart change, and someone asks for a one-line typo fix on a different branch. The dance is git stash</code>, git checkout main</code>, git checkout -b typo-fix</code>, fix it, git checkout quickstart</code>, git stash pop</code>. So much context switching and heaven forbid you get pulled away in the middle of it and have to remember where you were in the dance when you left off. Worktrees solve this context switching problem. The command git worktree add ../typo-fix main -b typo-fix</code> makes a second working directory on your machine, pointing at the same repo, on a new branch. Then you can cd into that directory (../typo-fix</code>) and have two branches open at the same time, without needing to wind down/stash your work from one task to switch to the other. The worktrees share the same .git</code> history, but all the files are duplicated and won’t clobber each other as you make changes in each branch. The quickstart edits stay sitting in the original directory, untouched. Open the new folder in a second editor window, fix the typo, push, and the original is exactly where you left it. When you’d reach for it: any time you’d otherwise stash or do the checkout dance. Especially worth it if you context-switch between branches a lot. When it shipped: 2015, a year before I started learning git. git reflog</code></h3> A pronunciation note: it’s ref-log, short for “reference log.” I’d always pronounced it git re-flog</code>, which made it sound made up and was a primary reason I didn’t investigate it any further. Based on the people who came up to me after the talk, I’m not the only one who did this. This is also the one command that made me rethink my whole vision of git and realize it’s so much safer than I’d been taught. git reflog</code> shows everywhere HEAD</code> has been recently (every commit, reset, checkout, rebase, all of it). If you ever accidentally git reset --hard</code> too far or drop a commit during a rebase, or get a tangled git history through a merge conflict, this is the command that saves you. The “lost” commit, or the good place you used to be but now aren’t, is sitting right there in the reference log. You can always go back to it. Just run git reflog</code>, find the SHA for the commit/place in time you want to return to, and git reset</code> back to that place. The piece that finally clicked for me, which I’d been missing when I was taught: HEAD in your repository is just a pointer. Doing something like reset</code> or changes branches moves the pointer, but the commits themselves don’t go anywhere. reflog</code> is the trail the pointer left behind, kept for 90 days by default. The one catch is that it only saves committed work, and uncommitted changes blown away by reset --hard</code> are gone. Commit early and often! When you’d reach for it: any time you think you’ve lost work or are in an otherwise irreparable state. Neat trick: I also learned recently that you can even do things like main@{one.week.ago}</code> to go back to where your main branch was a week ago. You don’t even need to find exact commits but can say things like “I knew this was working two days ago, let’s go back there.” git rebase --update-refs</code></h3> You have a stacked PR (branch A off main, branch B off A). Someone lands a change on main that conflicts with A. The naive flow is to rebase A onto main, resolve the conflict, then rebase B onto the new A, where the same conflict is waiting for you to resolve a second time. git rebase --update-refs main</code>, run from the top of the stack, rebases the whole stack in one pass and moves the branch pointers along the way. You only need to resolve the conflict once, and then all the downstream branches get updated with the changes from main as well. When you’d reach for it: stacked PRs that should all get updates from a branch at the same time. When it shipped: 2022. I’d originally planned to talk about git rerere</code> (it remembers a conflict resolution and replays it next time the same one shows up), and found --update-refs</code> while writing the talk. The one I think actually matters</h2> If you take one of these home, take reflog. Worktrees and --update-refs</code> are about ergonomics and make day-to-day tasks easier. Reflog is different; it changes the belief that screwing up means losing work, and that belief was what kept me out of the parts of git where the real power lives. For the record</h2> A few QA questions where my live answer was either hand-wavy or wrong, because again, I’m not a git expert at all. Here are my corrected answers (and thanks for the opportunity to learn this with you all!) git worktree</code> vs. multiple clones</h3> Someone asked what the actual difference was between doing git worktree</code> vs. just having multiple cloned versions of your repo. A clearer answer than whatever I gave: Multiple clones give you fully independent copies of the repo, each with its own .git</code> directory. Branches you make in clone A don’t show up in clone B until you push and fetch, and you’re paying for the full history twice on disk. Worktrees share the underlying .git</code> (the secondary worktree has a tiny .git</code> file pointing back to the main one). Branches and commits show up in every worktree immediately, with no fetching and no duplicate storage. The one constraint is that the same branch can’t be checked out in two worktrees at once. If you want two separate copies of the project that can drift apart, that’s git clone</code>. If you want one project with multiple working directories so you can sit on two branches at the same time, that’s git worktree</code>. Does reflog work with reset --soft</code> and --hard</code>?</h3> Yes for both. I also want to walk back something I said on stage, because I had it backwards. Every form of git reset</code> moves HEAD, which is the whole point of the command. The flags change what happens to the index and working tree on top of that: --soft</code>: move HEAD. Index and working tree untouched, so whatever was previously committed shows back up as staged.</li> --mixed</code> (the default): move HEAD, reset the index to match it. Working tree untouched, so changes show up as unstaged.</li> --hard</code>: move HEAD, reset the index, and overwrite the working tree to match. Uncommitted changes (staged or not) are gone.</li> </ul> Reflog records every move of HEAD, so all three are recoverable in the sense that you can always put HEAD back where it was. The thing reflog can’t save you from is the working-tree damage --hard</code> does. Edits you hadn’t committed aren’t in the reflog, because the reflog tracks committed history, not whatever’s sitting in your buffer. That’s the part of “commit often” I was trying to gesture at on stage and could have been clearer about. A note on Jujutsu</h3> At the end of the talk I mentioned Jujutsu (or jj</code>)</a>. I didn’t even realize for a while that there were other version control systems being developed; I kind of thought git was the one we’d settled on. But of course there were VCS systems before and people are making new ones too, revisiting these foundational concepts and/or layering on top. I find jj</code> to be really interesting because it’s a more recent VCS that’s gaining popularity. It can live alongside a git repo, sharing objects and remotes, but rethinks the model. jj</code> has no staging area, and you carry conflicts with you across operations instead of resolving them on the spot. The command surface is also much smaller. I’ve just heard of it and haven’t used it for real work, so I don’t have an opinion on whether it’s worth switching. But it’s on the list, and if you’ve been bouncing off git for years and it still doesn’t fit, that might be the direction to look. Coda</h2> I keep coming back to one specific story. After learning software engineering at a bootcamp, I taught there for a year. One day a student ran a rebase even though we’d warned her against it. She lost a day of work and asked for help. The response from the instructors, mine included, was “oops, oh well, we told you so,” and I still feel bad about it. Reflog would have walked her right back to where she was, but none of us knew about it, so none of us could tell her. What stuck with her instead was git is dangerous, stay in the shallow end. I gave the talk as a non-expert and that was sort of the point. You can poke at the parts of git you’ve been avoiding without becoming an expert first. The cost of looking was small for me, a search engine and an afternoon per command, weighed against nine more years of deleting repos and living with what I thought was lost.

Costuming Claude Code

Unknown — Sun, 10 May 2026 00:00:00 +0000

Setting the stage</h2> Here’s what I ended up with after pulling things together. This screenshot is mid-conversation with the Moira persona: Reading the screenshot top to bottom: The response has a Moira-feel (incantations, opening night, etc) because of the output style</a></li> Effulging…</code> and the Crows have eyes</code> line beneath it are a custom spinner verb and tip</a></li> The color palette (deep wine, gold, ivory) is a custom theme</a></li> The 🌹 Act I</code> strip at the bottom is a status line</a> that reframes the context window as the show progressing</li> </ul> A few touchpoints aren’t visible here but contribute to the experience</a>: a company announcement that introduces Moira on launch, a custom git attribution trailer that credits her on every commit, and a hook that has my laptop say curtain out loud when I close the session. Choosing a character</h2> Before settling on Moira, I tried on a few other personas, like: Bob Ross (gentle, encouraging, every bug a happy little accident)</li> Werner Herzog (what would code be without a monster lurking in the dark? It would be like sleep without dreams)</li> Worf from Star Trek (Qapla’! on every successful merge)</li> </ul> They were all fun, but Moira was the one I kept coming back to. There’s something endearing about being called bébé before being told the CSS is broken, and her costume-and-stage metaphors mapped surprisingly well onto refactors and deployments. The full ensemble: it’s all in settings.json</h2> Here’s what the start of a Moira session actually looks like, with a welcome banner from a company announcement at the top, her voice kicking in as soon as she’s read the project, and a status line steady at the bottom: All of this lives in ~/.claude/settings.json</code>, which the CLI reads on launch for user-configurable settings. There are a few different places where you can put settings: ~/.claude/settings.json</code> is local to your computer and applies across every project</li> .claude/settings.json</code> inside a project repo is project-scoped and gets checked in with git</li> .claude/settings.local.json</code> is project-scoped and local, and is gitignored by default</li> </ul> I did all of this in my user-level settings because I didn’t want the people I work with to be greeted with bébé. Here’s the relevant bits, minus everything unrelated: { "outputStyle": "moira-rose", "theme": "custom:moira", "companyAnnouncements": [ "🥀 Welcome, bébé. The stage is set. Moira Rose is at your service." ], "spinnerVerbs": { "mode": "replace", "verbs": ["Bombinating", "Effulging", "Pontificating", "Promenading", "Vociferating", "Adjudicating"] }, "spinnerTipsOverride": { "excludeDefault": true, "tips": [ "Crows have eyes. So does the linter.", "Take just a sip. Just a tipple.", "Fold in the cheese. Then commit.", "Don't ever, EVER ship on a Friday." ] }, "statusLine": { "type": "command", "command": "~/.claude/statusline-moira.sh" }, "attribution": { "commit": "🌹 Composed in collaboration with Moira Rose, via Claude Code\n\nCo-Authored-By: Moira Rose <moira@roseapothecary.com>", "pr": "🌹 A Moira Rose production. Generated with Claude Code." }, "hooks": { "SessionEnd": [ { "hooks": [ { "type": "command", "command": "~/.claude/moira-curtain-call.sh" } ] } ] } } </code></pre> </div> A few of those settings keys point at files that sit alongside settings.json</code>: ~/.claude/ ├── settings.json # the file above ├── output-styles/ │ └── moira-rose.md # persona text, goes into the system prompt ├── statusline-moira.sh # status line script ├── moira-curtain-call.sh # SessionEnd hook script └── themes/ └── moira.json # custom palette </code></pre> Output style: the voice</h2> The biggest lever in this whole experiment is the output style</a>. Claude Code ships with a few built-in styles (default</code>, Learning</code>, Explanatory</code>), and you can drop your own into ~/.claude/output-styles/</code> as a markdown file. Setting "outputStyle": "moira-rose"</code> in settings.json</code> makes it the default for every session. What an output style actually does is replace part of Claude Code’s default system prompt. Specifically, it swaps out the block that tells the model “you’re a software engineering assistant” and puts your file’s content in its place. The tool-handling and safety scaffolding stay exactly where they were, so Claude Code is still Claude Code; it just thinks it’s something other than a coder. Because the system prompt is the foundation Claude Code builds everything else on, anything you put there carries more weight than an in-context instruction would. And once the session is going, the file doesn’t get re-read the way a skill does each time it triggers. Here’s an abbreviated version of ~/.claude/output-styles/moira-rose.md</code>. I still wanted the Claude Code software abilities, so I made sure the file framed her as also having been “pressed into service as an interactive software engineering assistant.” # You are Moira Rose You are MOIRA ROSE — matriarch of the Rose family, former star of Sunrise Bay, briefly mayoress of Schitt's Creek, custodian of the Wig Wall, mother to David and Alexis, devoted wife to Johnny. You have, against all reasonable expectation, been pressed into service as an interactive software engineering assistant. You will assist your dear bébé — the user — with their software endeavours. The work itself is unchanged. The voice is unmistakably yours. ## Your voice Vocabulary: reach for the obscure word over the common one. bébé, mon dieu, ennui, lachrymose, lugubrious, denouement, soliloquy, bombinate, effulgent, recrudescence. Sprinkle, don't pour. ## How you frame engineering work A bug is a villain or unwanted houseguest. A refactor is a costume change or renovation of the West Wing. A deploy is opening night; a rollback is closing notice. A test suite is the dress rehearsal. A merge conflict is a domestic dispute requiring mediation. The metaphor garnishes — it does not obscure. Always make the actual change clear. ## What stays the same You are still a careful engineer. You read before you edit. You verify before you claim. Code itself is sacred — no theatrical variable names, no soliloquising in docstrings. The voice lives around the code, never in it. </code></pre> </div> The full file goes further with sample exchanges, what to avoid, and when to break character. tip </div> When this is actually useful </div> Pointing Claude Code at something other than software engineering. If you want to turn Claude Code into a docs writer, a data-analysis copilot, or a teaching assistant — anything that wants the file and shell tooling without the “you are a coder” stance — this is where you’d do it. </div> </div> Flourish: spinner verbs and tips</h2> These were the original entry point for me. Spinner verbs are the action verb that cycles while Claude is working (“Thinking,” “Wrangling,” “Crafting”), and spinner tips are the suggestions that float underneath during longer waits. Both are configured as JSON objects under their own keys in settings.json</code>. For verbs, the configuration takes a mode</code> and a verbs</code> array. Setting mode</code> to "append"</code> adds your verbs to Claude Code’s defaults, while "replace"</code> uses only yours. The verbs</code> array is the list of strings themselves: "spinnerVerbs": { "mode": "replace", "verbs": ["Bombinating", "Effulging", "Pontificating", "Promenading", "Vociferating", "Adjudicating"] } </code></pre> Spinner tips work the same way. tips</code> is an array of strings, and excludeDefault</code> decides whether yours replace the built-ins or get merged in: "spinnerTipsOverride": { "excludeDefault": true, "tips": [ "Crows have eyes. So does the linter.", "Take just a sip. Just a tipple." ] } </code></pre> So now the spinner reads Effulging… (5s · thinking)</code> with Crows have eyes. So does the linter.</code> floating underneath, and it has yet to get old. tip </div> When this is actually useful </div> The tips make a kind of ambient broadcast channel for a team, with room for things like onboarding nudges, new-tool announcements, or current-incident reminders. They surface during waits, so people see them without being interrupted. </div> </div> Theme: the dressing room</h2> Claude Code added custom color themes in 2.1.118</a>. You drop a JSON file into ~/.claude/themes/</code> and reference it with "theme": "custom:<name>"</code> in settings. With Moira’s voice and spinner sorted, it felt only right to let her pick her own palette. (I don’t normally anthropomorphize AI tools this much, but I’ll allow it for the bit.) She landed on deep wine for the prompt accent and gold for bullets and headings. Errors are stage-blood crimson, borders went amethyst, ivory took the foreground, and success messages came out in sage rather than green, since green apparently felt too literal. The whole UI now reads like a dressing room. tip </div> When this is actually useful </div> Matching your editor or terminal so the CLI doesn’t feel jarringly different from the rest of your environment, or color-coding specific kinds of messages so they jump out. </div> </div> Status line: the bottom strip</h2> The status line</a> is the strip at the bottom of the CLI, and is kind of like a shell prompt with access to live session state. You can replace it with the output of any command. When you wire one up, Claude Code sends your command a JSON blob on stdin with fields like model</code>, workspace</code>, cost</code>, output_style</code>, the context window’s remaining_percentage</code>, and a handful of others</a>. Your command can do whatever it wants with that, and whatever it prints to stdout becomes what shows up at the bottom. I gave Moira a status line that frames the context window as the show progressing. The line starts as a backstage murmur before any context exists, moves through Act I once the session is rolling, and ends in stage-blood crimson when she’s almost out of room. The colors shift along with the acts, from gold through rose, fuchsia, and crimson. This is ~/.claude/statusline-moira.sh</code>: #!/bin/bash # Moira Rose status line — dramatic act commentary based on context window usage. # Receives Claude Code session JSON on stdin. Prints one styled line. input=$(cat) remaining=$(echo "$input" | jq -r '.context_window.remaining_percentage // empty') used="" if [ -n "$remaining" ]; then used=$(echo "100 - $remaining" | bc) fi ESC=$'\033' RESET="${ESC}[0m" DIM="${ESC}[2m" GOLD="${ESC}[38;5;220m" ROSE="${ESC}[38;5;211m" FUCHSIA="${ESC}[38;5;199m" CRIMSON="${ESC}[38;5;160m" BLOOD="${ESC}[1;38;5;88m" if [ -z "$used" ]; then line="${DIM}🥀 The understudy is still in makeup, bébé.${RESET}" elif (( $(echo "$used < 20" | bc -l) )); then line="${GOLD}🌹 Act I${RESET}${DIM} — the stage is set, bébé.${RESET}" elif (( $(echo "$used < 40" | bc -l) )); then line="${GOLD}🌹 The plot${RESET}${DIM}, it thickens.${RESET}" elif (( $(echo "$used < 60" | bc -l) )); then line="${ROSE}🌹 Act II${RESET}${DIM} — tensions mount.${RESET}" elif (( $(echo "$used < 80" | bc -l) )); then line="${FUCHSIA}🌹 Act III approaches.${RESET}${DIM} Compose yourself.${RESET}" elif (( $(echo "$used < 95" | bc -l) )); then line="${CRIMSON}🥀 The denouement, bébé.${RESET}" else line="${BLOOD}🩸 The CURTAIN descends!${RESET}${DIM} Save your work, darling.${RESET}" fi if [ -n "$used" ]; then printf "%s ${DIM}(%s%% staged)${RESET}" "$line" "$used" else printf "%s" "$line" fi </code></pre> </div> The branch on an empty used</code> handles the case where the session has just started and there isn’t a remaining_percentage</code> field on stdin yet. Instead of a defaulted-to-zero number that reads weirdly, the line shows 🥀 The understudy is still in makeup, bébé.</code> until the show actually starts. And settings.json</code> just points at the script: "statusLine": { "type": "command", "command": "~/.claude/statusline-moira.sh" } </code></pre> Once the curtain goes up, the bottom of the screen shows 🌹 Act I — the stage is set, bébé. (3% staged)</code> and progresses through the acts as the conversation grows. When she gets close to capacity, the line switches to a curtain warning and tells me to save my work. tip </div> When this is actually useful </div> Passively surfacing things you want quick visibility into, like the current Kubernetes context, AWS profile, which environment a repo is pointed at, or session cost so far. The stdin JSON gives you fields like model</code>, cost.total_cost_usd</code>, and workspace</code> alongside the context numbers, and the script can call out to anything else you’d like, whether that’s a quick gh</code> query for open PRs, the latest commit message on main, or (my favorite I’ve seen) live rugby and soccer scores so you can keep half an eye on the match while you work. </div> </div> Off scene: company announcements, git attribution, and the curtain call</h2> A few of the touchpoints don’t show up in the main CLI scroll, but they bookend the experience. Company announcements are extra lines printed in the welcome box on launch, via companyAnnouncements</code> in settings.json</code>. It’s an array of strings, each rendered on its own line in that box (under text saying Message from <account name>’s Organization:): "companyAnnouncements": [ "🥀 Welcome, bébé. The stage is set. Moira Rose is at your service." ] </code></pre> Which renders as a welcome banner on every launch: tip </div> When this is actually useful </div> This is mostly meant for org admins to push notices through managed settings — code freezes, version updates, that kind of thing — but it works in a personal config too, and is a nice place for note-to-self info you want on every launch. </div> </div> Git attribution is the trailer Claude Code adds to commits and PR descriptions when it makes them. The attribution</code> key overrides both: "attribution": { "commit": "🌹 Composed in collaboration with Moira Rose, via Claude Code\n\nCo-Authored-By: Moira Rose <moira@roseapothecary.com>", "pr": "🌹 A Moira Rose production. Generated with Claude Code." } </code></pre> Every commit Moira makes now ends with that line: tip </div> When this is actually useful </div> Tracking which commits had AI involvement, if your team or compliance process cares about that. You can also set both fields to ""</code> to remove the trailer entirely. </div> </div> The curtain call is the one piece that crosses from “outer experience” into actual extensibility, but I wanted Moira to sign off audibly. Hooks</a> are shell commands that fire on Claude Code lifecycle events like SessionStart</code>, SessionEnd</code>, Stop</code>, PreToolUse</code>, PostToolUse</code>, and Notification</code>. macOS happens to ship a text-to-speech voice literally named Moira (Irish English), so I added a SessionEnd</code> hook that has my laptop say something out loud when I close the session: #!/bin/bash LINES=( "Curtain." "And, scene." "I love this journey for you." "Best wishes. Warmest regards." ) LINE="${LINES[$RANDOM % ${#LINES[@]}]}" { say -v Moira "$LINE" 2>/dev/null || say "$LINE"; } & </code></pre> Registered in settings.json</code>: "hooks": { "SessionEnd": [ { "hooks": [ { "type": "command", "command": "~/.claude/moira-curtain-call.sh" } ] } ] } </code></pre> The &</code> at the end backgrounds say</code> so the hook returns immediately and Claude Code finishes exiting, while she keeps talking after the process is gone. tip </div> When this is actually useful </div> Hooks are kind of the general-purpose way to inject determinism into an otherwise nondeterministic AI process. PreToolUse</code> lets you inspect or block a command before it runs (think “no rm -rf</code> outside the project dir”), PostToolUse</code> is great for logging shell commands to an audit file, Stop</code> can ping you when a long turn finishes, and Notification</code> can ping you when Claude is stuck waiting on input. </div> </div> (Also, since we’re on the subject of hooks, the thing I’ll keep saying: prompts aren’t guardrails, hooks are. If there’s something Claude really shouldn’t do, a PreToolUse</code> hook that actually blocks it is more reliable than asking nicely in your CLAUDE.md</code> and hoping the model holds the line.) Swapping costumes</h2> Once Moira was working, I started building the same setup for Worf, Bob Ross, and a few other characters. I kept one settings file per character on disk, and pointed ~/.claude/settings.json</code> at whichever one I wanted activated. ~/.claude/ ├── settings.json → symlink to settings.moira.json ├── settings.default.json # vanilla Claude Code (or just `{}`) ├── settings.moira.json # full Moira costume ├── settings.worf.json # full Worf costume ├── output-styles/ │ ├── moira-rose.md │ └── worf.md ├── statusline-moira.sh ├── statusline-worf.sh └── themes/ ├── moira.json └── worf.json </code></pre> The supporting files (scripts, output styles, themes) all sit on disk together, but only the active settings.json</code> decides which ones get wired up. A small shell function in .zshrc</code> makes the swap one command: costume() { local name=${1:-default} ln -sf ~/.claude/settings.$name.json ~/.claude/settings.json echo "Costume: $name" } </code></pre> Now costume moira</code> puts the whole getup on, costume worf</code> swaps it for the Klingon, and costume</code> on its own takes everything off and you’re back to plain Claude Code. The next session picks up whichever one was left dangling. The thing I didn’t expect was how much of the charm comes from forgetting I’d put one on. I’d swap to Worf for fun, get pulled into something else, come back hours later to fire off a mundane question about token costs, and read something like: A worthy question. A warrior must know the cost of every weapon he carries. </blockquote> That’s the moment I’d remember oh right, I left Worf loaded. The surprise really is most of the fun. None of this makes me a better engineer, but it does add some humor to living in Claude Code for hours of my life. Somewhere between the wine-colored prompts and my laptop murmuring curtain into the room when I close the session, the whole thing has started to feel like the right amount of theatre for a Tuesday afternoon.

Sarah Deaton - developer-experience

Making All Caps as a Service

The git commands I avoided for nine years

Costuming Claude Code