Claude Code is still crushing it - My updated workflow

Updated February 2026. Partial update. Added the knowledge base system, custom slash commands, and cross-project workflow that’s become the backbone of how I use Claude Code. Fixed outdated claims about agents, GitHub integration, and thinking triggers. There’s more to cover and I’ll keep updating this post as my workflow evolves.

The AI coding landscape has completely lost its mind since I first wrote this. New tools drop daily, my LinkedIn feed is a graveyard of “revolutionary AI breakthroughs,” and yet here I am, still using Claude Code like it’s my favorite hoodie.

You know, the one you wear even though it has that weird stain from that time you tried to eat spaghetti while coding. Don’t judge me.

Table of contents

Why I’m still team Claude Code (and you probably should be too)

Everyone’s asking if I’ve jumped ship to the latest shiny AI coding tool. Short answer: nope. Long answer: noooooope.

Claude Code is still the best tool in my workflow, even with all the new competition trying to steal its lunch money. I’ve tested most of them - or at least I try to keep up, which is like trying to drink from a fire hose while someone keeps turning up the pressure.

But here’s the thing: when you’re debugging at 2 AM and your server’s throwing errors like confetti at a parade, you need something that actually works. Not something that might work. Not something that works most of the time. Something that just freaking works.

Claude Code just works. But the real shift since I last wrote isn’t a single feature. It’s the system I’ve built around it.

The knowledge base: one repo that powers everything

This is the biggest change to my workflow and the thing I wish I’d set up six months earlier.

I have a private GitHub repo called knowledge-base that holds everything Claude Code needs to know about my work. Client briefs, communication templates, task lists, project specs. It’s just markdown files organized by domain. Nothing fancy.

Here’s roughly how it’s structured (client names changed, obviously):

knowledge-base/
├── claude/
│   ├── commands/          # Custom slash commands (symlinked globally)
│   └── rules/             # Code style, commits, general prefs (symlinked per repo)
├── communication/         # Email templates, tone rules
├── consulting/
│   ├── clients/
│   │   ├── client-a/      # SEO briefs, content calendars, specs
│   │   └── client-b/      # Site migration docs, checklists
│   ├── seo-playbooks/     # Reusable SEO strategies
│   └── n8n-workflows/     # Automation recipes
├── projects/
│   ├── side-project-1/    # Specs, architecture docs
│   └── side-project-2/    # Research, mockups
├── writing/               # Blog editorial calendar, style guide
├── life/                  # Home network docs, personal stuff
├── todos.md               # Cross-project task list
├── CLAUDE.md              # Ecosystem context for every session
└── HOW-TO-USE.md          # How Claude should navigate all of this

Everything is markdown. No database, no app, no SaaS tool. Just files in a Git repo that Claude Code can read and edit.

The magic is in how it connects to Claude Code:

Rules live in knowledge-base/claude/rules/ and get symlinked into every repo’s .claude/rules/ directory. When I open Claude Code in any project, it automatically loads my rules for code style, commit messages, and general preferences. I don’t paste instructions. I don’t re-explain preferences. They’re just there.

Here’s what’s in my rules directory right now:

• code-style.md — No unnecessary comments, minimal changes, don’t over-engineer
• commits.md — Concise messages in imperative mood, don’t push unless I explicitly ask
• general.md — Don’t make big decisions without asking me first, edit existing files instead of creating new ones, check for specs before building anything

Custom slash commands live in knowledge-base/claude/commands/ and get symlinked to ~/.claude/commands/. These are structured prompts that turn Claude Code into different tools depending on what I’m doing.

CLAUDE.md at the root gives Claude my full ecosystem context: which repos exist, what each project is, who the clients are, where to find specs. Every session starts with Claude knowing the whole picture.

The result: I can jump between my blog, a client’s WordPress site, a consulting project, and a personal side project, and Claude Code already knows the context for each one. No re-explaining. No “here’s what this project is about.” It just knows.

Custom slash commands: the tools I actually use

The slash commands are where this system pays off daily. Each one is a markdown file with a structured prompt that tells Claude Code exactly how to approach a specific type of work.

/email and /message — These are the ones that save me from myself. I have a tendency to write emails that are either too blunt or full of jargon nobody outside my head understands. The /email command reads my communication rules and rewrites things so I sound like a professional human instead of a robot who skipped social skills class. I give it the context (“tell Sarah the Figma review is ready”) and it handles the tone. For high-stakes messages, it gives me 2-3 variants so I can pick the one that doesn’t accidentally start a war.

/weekly-review — Scans git activity across all my repos, checks the todo list, and produces a “state of things” report with suggested priorities. I run this every Monday morning.

/seo-brief — Generates a full content brief with target keywords, search intent analysis, SERP gaps, content outline, and internal linking opportunities. I can say /seo-brief bitcoin tax reporting guide and get a brief tailored to a specific client.

/history — The custom history browser I wrote about in my conversation history post. Reads the global history file and shows every conversation across every project in a scannable table.

These commands work in any repo because they’re symlinked globally. I type /seo-brief whether I’m in my Astro blog or a client project, and it loads the same system.

Cross-project task tracking

One more piece of the knowledge base that ties everything together: todos.md.

It’s a single markdown file organized by domain (day job, consulting clients, blog, personal projects, life stuff). Every task has a checkbox, subtasks are indented, completed items get a date stamp. Nothing revolutionary about the format.

What makes it work is that Claude Code can read and update it from any repo. I finish a feature on a side project, tell Claude “mark the dashboard redesign done and add a QA task,” and it edits the file. When I run /weekly-review, it reads the same file to know what’s open, what’s blocked, and what got done.

I also check it from my phone through the GitHub app. Checkboxes are clickable on github.com, so I can mark things done from anywhere without opening a terminal. Between Claude Code on the web for actual coding and GitHub Mobile for task management, I can run my whole workflow from my phone. (Whether I should be doing that during my kid’s water polo practice is a separate conversation.)

The “ultrathink” trick that sounds fake but isn’t

Here’s the simplest productivity hack that sounds like something a YouTube guru made up to sell courses: just add “ultrathink” to your prompts when you’re stuck on something complex.

I was skeptical too. “Ultrathink? Really? What’s next, mega-ultra-super think?” But then I actually checked the documentation¹, and it’s legitimate. When you tell Claude Code to ultrathink, it triggers deeper reasoning. On Opus 4.6 this maps to the effort: "max" setting, which means Claude thinks longer and more thoroughly before responding. It’s like telling your AI to put on its serious pants.

I save this for the real head-scratchers, the ones where Claude Code has already whiffed once or twice. Complex business logic that makes my brain hurt, weird race conditions in state management, that one bug that only happens on Thursdays when Mercury is in retrograde. I wrote a deeper dive on all the thinking triggers and when to use each one if you want the full breakdown.

Plan mode is another one I’m using more. Hit shift+tab twice and Claude Code switches into planning mode where it researches and outlines an approach before writing any code. I’ve always been spec-driven (write a markdown spec, hand it to Claude), but Plan mode does the same thing without the separate file. I use it for anything that touches more than a couple files. Claude maps out the changes, I approve or adjust, then it executes. Way fewer “wait, why did you refactor that?” surprises.

Another small one that’s saving me time: double-tap Escape to edit your previous prompt instead of sending a new message. Keeps your context window cleaner when you need to course correct.

Background tasks: The feature nobody’s using (but should be)

Background tasks in Claude Code, and I’m confused why more people aren’t losing their minds over this.

Before background tasks (aka the dark ages)

My old workflow was basically:

1. Run backend server in separate terminal
2. Error happens
3. Copy error from terminal
4. Paste into Claude Code
5. Get suggestion
6. Repeat until I question my career choices

I was a glorified human clipboard. Copy, paste, repeat. Copy, paste, cry a little. You know the drill.

After background tasks (aka the enlightenment)

Now I just tell Claude Code: “Hey buddy, run the server in the background for me.”

You’ll see this cute little indicator showing “1 bash running,” and suddenly Claude Code has live access to all your server logs. No more copy-paste Olympics. When something inevitably breaks (because let’s be honest, something always breaks), Claude Code just checks the logs itself like a responsible adult.

This is way better than my old workflow from my Claude Code automation experiments where I was literally babysitting AI agents through every step. Now they can actually handle the boring stuff while I focus on the interesting problems.

This completely changed how I debug. If you use Claude Code with any kind of server and you’re not using this, you’re basically choosing to work harder instead of smarter. Stop it. Love yourself more.

Claude Code as your personal research assistant

Here’s something that’s saving me more time than I care to admit: using Claude Code to research complex features before building them.

Example: You need to implement PDF extraction. Instead of spending an hour down the Google rabbit hole reading Stack Overflow answers from 2012, you ask Claude Code to do a web search, find current best methods for PDF OCR extraction, and create a detailed implementation plan in a markdown file.

Even better: if you have a Claude Code subscription, you also get Claude desktop with deep research mode. This beast will search hundreds of sources for up to 20 to 30 minutes. It’s like having a research assistant who never complains about the coffee and actually enjoys reading documentation.

My workflow:

1. Use Claude desktop for deep technical research (while I get actual coffee)
2. Copy findings into Claude Code
3. Let Claude Code implement based on the research
4. Ship the feature
5. Take credit for being brilliant

There’s more to it but you get the idea. I’m here to help you think for yourself, not spoon-feed you everything. (But if people want a deep dive on my research workflow, I’ll write about that too. Just ask nicely.)

MCPs: Finally making sense

Remember my post about AI agents having their jQuery moment? MCPs (Model Context Protocol servers) are proving that point. I’ll admit I didn’t fully understand them at first, but now they’re essential to my workflow. One of the reasons I wrote that post - you don’t learn what you don’t research and use.

Context MCP: Your documentation butler

The Context MCP² gives Claude Code instant access to updated documentation. Working with Firebase? Instead of copying docs URLs like some kind of caveman, I just say “make sure you’re using the latest Firebase documentation” and Claude Code pulls it automatically.

It’s like having Alfred from Batman, but for documentation. And it works for practically every framework and library you’re using. No more “wait, is this the v4 or v5 syntax?” moments.

Database MCPs: Direct database access

The Firebase MCP lets Claude Code read and modify my database directly. When a user reports a bug, I can say “Check user X’s data in Firebase” and boom - instant results.

Before MCPs, I’d write JavaScript or SQL commands or manually dig through databases like I was mining for gold. Now Claude Code handles it all. There are MCPs for Firebase, Convex, AWS - basically every major service has one.

Ahrefs MCP: SEO data in your terminal

The newest addition to my MCP setup. The Ahrefs MCP lets me pull keyword data, backlink profiles, and site metrics directly from Claude Code. I used it today to cross-reference search positions across GSC, Ahrefs, and SEMrush data while updating blog posts. Instead of switching between three browser tabs, I asked Claude Code to pull the data and analyze it in one place.

If you do any SEO work, this one is worth setting up. It’s not going to replace the Ahrefs dashboard for deep analysis, but for quick “what’s this keyword’s volume and difficulty?” checks while you’re writing content, it’s fast.

GitHub integration: Your robot code reviewer

As a solo developer, I don’t have a team to review my code. It’s just me, myself, and I. And let’s be honest, I’m terrible at catching my own mistakes. I once spent three hours debugging only to realize I typed “fucntion” instead of “function.” Three. Hours.

Claude Code’s GitHub integration fills that gap. You can create PRs, review code, and manage issues directly from Claude Code using the GitHub MCP server. Setup is through the /mcp command, which walks you through connecting your GitHub account via OAuth. Once it’s connected, Claude Code can read your repos, create pull requests, and review code without you ever opening a browser.

About half the automated review comments are generic fluff, but it’s caught enough real issues to save my bacon multiple times. Memory leaks, uninitialized variables, potential security problems, stuff that would’ve bitten me in production.

For beginners especially, this is gold. It’s like having a senior developer reviewing your code, minus the judgment and passive-aggressive comments. And yes, I have tried GitHub Copilot but it’s not as good and I’m already paying for Claude Code so why add another subscription to my “I’ll cancel this next month” list?

Claude Code on the web: Coding from anywhere

Okay, this deserves its own section because it’s kind of ridiculous how useful this is. Claude Code on the web³ means I can literally code from my iPhone while sitting at my son’s water polo practice.

Picture this: Can’t sleep at 3 AM, brain won’t shut off about a feature idea. Instead of losing it by morning, I grab my phone from the nightstand: ‘Claude, implement that A/B test in PostHog we discussed but with cookie-based persistence.’ Wake up to a pull request from myself.

Done. From my phone. While falling back to sleep.

I’ve fixed bugs during my kid’s water polo practice, updated configurations while in line at the DMV, and even pushed a hotfix from a bathroom stall (we’ve all been there, don’t pretend you haven’t).

Is typing on a phone screen ideal? No. But being able to give Claude Code high-level commands and have it execute them perfectly while I’m away from my desk? That’s the future I was promised in all those sci-fi movies, minus the flying cars.

Why I dictate everything (and you should too)

To be fair, I don’t dictate everything. Sometimes I type like a normal person. But people keep asking about my dictation setup like I’ve got some secret sauce. Ready for the big reveal?

Mac accessibility settings. That’s it. That’s the tweet.

Your Mac already has voice features built in. Why pay for something when Tim Apple already gave it to you? Go to System Settings > Accessibility > Voice Control. Boom. You’re welcome.

Quick sidebar: If you’re using the Claude desktop app (Mac or Windows), you can dictate directly into it. No setup needed. Just talk to it like you’re having a conversation. But Claude Code in the terminal? That’s a different beast. You need either Mac’s accessibility features or a third-party tool to dictate there. The desktop app has its own voice input built in, but when you’re in terminal-land, you’re on your own.

I’ve seen others use Whisper Flow and swear by it. Maybe it’s better. I’ll try it eventually when I’m not busy using the free thing that already works perfectly.

The real value of dictation isn’t the tech - it’s that you naturally give more context when speaking. Explaining a bug verbally is like calling your mom versus texting her. The call has all the emotion, the context, the “well, first this happened, then this other thing…” that makes the problem clear.

But real talk: if you stop typing, you’ll lose that skill. Remember that MIT study I wrote about in Your brain on AI? They found we’re losing critical thinking and problem-solving skills by over-relying on AI. Balance is key - use dictation for brainstorming, but keep those typing muscles active.

Aliases: Small optimization, big impact

I see people buying clipboard manager apps to store frequently-used snippets when their terminal already does this for free. You can save anything you type often as an alias. This productivity tip will make you feel like a command-line wizard: aliases in your .bashrc or .zshrc file.

I type ‘claudeblog’ and Claude Code opens right in my blog repository with the right Node version. No navigation, no typing paths, no remembering which Node version this project needs.

# Open project and Claude Code
alias claudeblog="cd ~/Code/astro-blog/ && nvm use 22.20.0 && claude"

# Open project and start dev server
coderun() { code "$1" && cd "$1" && npm run dev }

# Watch Star Wars Episode IV in ASCII art via telnet (classic easter egg) 
alias starwars="telnet towel.blinkenlights.nl" 

# Text-to-speech joke command (macOS say command) - phonetic humor
alias fuh="say pho the face" 

# Reload zsh configuration without restarting terminal 
alias start="source ~/.zshrc" 

# Quick navigation to home directory (alternative to just 'cd' or '~') 
alias home="cd ~"

Why do I have these? Because I’m lazy in the best way possible. The Star Wars one is for when I need a 10-minute break but want to feel productive. The “fuh” command makes my 12-year-old laugh every single time (I’m not proud, but I’m not sorry either).

Key things to remember: Keep aliases short but memorable. Avoid overriding existing important commands (learned that one the hard way). Document complex aliases with comments so future you doesn’t hate current you.

When you’re juggling multiple projects, these small optimizations add up fast. I see developers using expensive third-party services to record shortcuts and I’m like… your terminal already does this for free. If people want a deep dive on my entire alias setup and how it saves me probably 30 minutes a day, let me know. I’ll write that post.

Custom agents and subagents: Actually useful now

I wrote in the original version of this post that agents were “fine, not revolutionary.” I’m eating those words.

Claude Code now has a full subagent system where you can spawn specialized agents that run in their own context window with custom tools and permissions. I use them for code review, codebase exploration, and running parallel research tasks while I keep working in the main session. Each subagent gets its own system prompt and tool access, so you can give a reviewer agent read-only permissions while your implementation agent can edit files.

You can also create custom agents with .md files that define behavior, tools, and even persistent memory across sessions. My iOS agent (for Swift projects) and a code review agent are the two I reach for most. The difference from a year ago is that these actually work reliably now instead of feeling like a demo.

The little things that matter

I switched from macOS Terminal to iTerm2 and it’s one of those “why didn’t I do this sooner” changes. Terminal’s text formatting was always slightly off with Claude Code output, stuff getting garbled or hard to scan. iTerm2 renders everything cleanly. But the real win is notifications: when Claude Code needs me to approve something or answer a question, the dock icon bounces. No more coming back from a coffee break to find Claude’s been waiting on me for 10 minutes. Small thing, huge difference when you’re running background tasks.

Custom status lines are surprisingly useful. Below Claude Code’s input box, I see my current Git branch and time since last commit. It’s like a gentle parent reminding you to clean your room, except the room is your codebase and cleaning means committing.

Type /statusline and tell Claude Code what you want. I keep it simple - project name, branch name, Node.js version, and last commit time. Some people add weather updates and stock prices. Those people have different priorities than me, and that’s okay.

And if you’re constantly context-switching between projects?(Like this guy here) I wrote an entire post about using the /history command to find and resume any conversation from your entire Claude Code history - not just your last 3 sessions. Lifesaver for “wait, how did I fix that last week?” moments.

What I’m adopting next

I recently went through a workflow guide from the creator of Claude Code and compared it against my setup. Humbling exercise. Out of his 13 tips, I was fully doing 3, partially doing 2, and completely missing 8. Here’s what’s on my list.

Verification feedback loops. This is the one that hit hardest. The idea: give Claude a way to verify its own work before it tells you it’s done. Run the build, run the tests, check the output. His claim is that this 2-3x the quality of results. I have nothing like this set up. For my Astro blog it’d be astro check && astro build as a verification step. For other projects, maybe a subagent that reviews the output against a checklist. I’ve been the verification loop this whole time, and that’s… not scalable.

Inline bash in slash commands. My slash commands are pure markdown prompts. His use $() to pre-compute context before the model even starts thinking. So instead of /weekly-review telling Claude “go check git logs across all my repos” (which burns 5-6 tool calls gathering info), the command itself runs those git commands and hands the results to Claude ready to analyze. One shot instead of a scavenger hunt. My /weekly-review and a /commit command are the obvious first candidates.

Hooks. Claude Code can run shell commands automatically after every file edit, every tool call, whatever trigger you want. He uses a PostToolUse hook that auto-formats code after Claude writes it. Claude gets ~90% of the formatting right, the hook handles the last 10%. I have one hook (ESLint on a specific project) but haven’t thought about it beyond that. A Prettier hook for my projects, build checks or tests are the obvious wins here.

Permission pre-allowances. Every time Claude Code wants to run a build command or check git status, I click “allow.” Every. Single. Time. Turns out you can pre-allow safe commands in a .claude/settings.json file, check it into git, and never see those prompts again for stuff that’s obviously fine. Build commands, test runners, linters, git status. No idea why I’ve been clicking through these manually for months.

GitHub Action for Claude. You can tag @.claude on pull requests and it’ll review the code, suggest changes, even update your CLAUDE.md as part of the PR. Even as a solo dev, that creates a feedback loop where lessons from code review get captured automatically instead of living in my head. I haven’t set up any GitHub Actions on any of my repos, so this one’s a bigger lift, but the payoff compounds over time.

I’ll update this post as I actually implement these. No point writing about things I haven’t battle-tested yet.

I’m also deliberately slower than most people to hand Claude the keys. Part of it is that I don’t want my own skills to atrophy (see: that MIT study I keep referencing). Part of it is that I still don’t fully trust it. I have co-workers who’ve given their Claude a name. Like a pet. I’m not there yet, and I’m not sure if that makes me cautious or just behind. Where do you draw the line?

Real talk: Is Claude Code worth it?

After months of daily use, here’s my unfiltered verdict:

Claude Code is still the best AI coding tool available. Full stop.

The combination of background tasks, MCPs, GitHub integration, and genuine context understanding makes it indispensable. I’m shipping faster, catching bugs earlier, and spending less time on the boring stuff that makes me question my life choices.

For engineering teams, it’s an obvious win. For solo developers like me, it’s like having a brilliant intern who never needs sleep, never steals your lunch, and occasionally surprises you with solutions you didn’t think of.

Is it perfect? No. Does it sometimes do weird stuff that makes me go “what the hell, Claude?” Absolutely. But it’s still leagues ahead of everything else I’ve tried.

What’s next?

The pace of change is absolutely bonkers - just look at my monthly tech chaos roundups if you want proof of how insane things have gotten. By the time you read this, Claude Code might have three new features I haven’t discovered yet. That’s both exciting and exhausting.

I’ll write another update in a few months when Claude Code inevitably adds something else that changes how I work. Until then, I’m focused on shipping code, breaking things in interesting ways, and pretending I know what I’m doing.

If you’ve got Claude Code workflow tips, hit me up on LinkedIn. I try to respond to everyone, though my response time ranges from “immediately” to “sorry, just saw this from 3 months ago.”

Want me to write about the AI tools that didn’t make the cut? There’s definitely a post brewing about alternatives that made me appreciate Claude Code even more. Spoiler: Some of them were rough.

Until next time, keep shipping and remember - if your code works on the first try, you probably forgot to run it.

Links: