My CTO daily driver

A deep dive into my Claude Code setup that's given me superpowers.

Thanks for being here for the April subscriber edition. As ever, I appreciate your support, and the chat is always open if you want to share thoughts or suggest topics.

In February, I showed you some tools I’d built with AI: a bragdoc generator, a planning tool, and a few others. This month, let’s go even wider and deeper into tooling.

I don’t mean broadening to more individual tools, but zooming out to see the whole system I’ve constructed around them: a personal workspace that’s become central to how I work day-to-day as a CTO. Think of this article as a peek behind the curtain: it’s what my setup actually looks like, how it evolved, and why it makes me more productive than I have ever been.

Here’s what we’ll cover in my Claude Code setup:

• What is a daily driver? How it differs from one-off AI interactions, and why persistence matters.

• How the workspace is organised. Directories, information flow, and the central configuration file.

• The roles. Eleven different personas that Claude can adopt, from Executive Assistant to Sparring Partner, each with distinct behaviours and triggers.

• The integrations. What’s connected and why: Linear, Notion, BetterStack, and more, all working together.

• The workflows. Daily bookends with /morning and /eod, weekly operations reports, and ad-hoc commands for triage and tracking.

• The composability insight. Why the whole is greater than the sum of its parts, and what this enables that separate tools don’t.

• Evolution. How it started, what’s changed, and how to know when to add something new versus just doing it manually.

If you’d like context before diving in, Just build the tools yourself from February covers the topic of using AI to quickly roll your own internal tooling. For related themes, Being in the details explores why staying close to what your teams are building matters, and Should managers still code? tackles the perennial question.

Let’s get into it.

What is a daily driver?

In February’s article, I mentioned that I use Claude Code as my “daily driver”: a unified interface for managing tasks and complex workflows, doing research, drafting documents, and synthesising information from a multitude of external sources.

But I glossed over what that actually looks like in practice. What does a daily driver look like? How is it different from just using Claude Code to interact with Linear or Notion?

At its core, it’s the creation of a continually improving system tailored to you. Consider the opposite: when you use Claude Code for a one-off task, you open a session, do the thing, and close it, and all of that context disappears.

A daily driver is something different: it’s a personalised workspace that has memory, both internally via files and externally via other systems that act as sources of truth. It has your opinions baked in, and it’s less a tool you pick up than an environment you quite literally drive your whole day from, one that only gets better with time.

Here’s what that looks like in practice. On Friday mornings, I run a single command that queries all of our Linear teams for bugs by severity, separating production issues from internal ones. It checks all of our production monitors for uptime across regions, calculates availability percentages, and pulls from our incidents database. It identifies any SLAs at risk of breach, then delivers a formatted briefing based on a template I’ve defined, ready to share.

This is just one of many composite operations the daily driver performs. For example, there’s /morning for a start-of-day briefing, /eod for capturing thoughts before logging off, /triage for processing my inbox into structured tasks, /check-sla for spotting at-risk bug fixes, and /dora-report for deployment metrics. And that’s not mentioning the numerous different roles that help me with analysis, writing, dissecting ideas, and planning.

What used to take an hour of clicking around now takes thirty seconds, and the fact that it is now so easy to think, pull data, derive insights, and be creative is game changing. It’s the result of structure, integrations, and workflows that have accumulated over time. Let me show you how it’s built.

How the workspace is organised

If you haven’t used Claude Code before, here’s the short version: it’s a terminal-based interface to the Claude models, which means it can directly read and write files on your filesystem and connect to external services like Linear, Notion, and monitoring tools via something called MCP (Model Context Protocol).

The key to making it useful isn’t just having access to these capabilities, though; it’s steering Claude’s behaviour so it knows what to do with them. That steering happens through a CLAUDE.md file: a markdown file that defines how Claude should behave, what roles it can adopt, what context it has access to, and what workflows it can execute. When I open a terminal session in my workspace, Claude reads this file first and orients itself accordingly.

The structure is a little like a codebase: you organise it into modules using a file structure that makes sense, then you tell Claude what each part does and how to interact with them. My workspace is organised into distinct zones, and I’ll walk you through some of them before we dig into the details in the rest of this article.

There’s an inbox.md file for quick capture: anything I need to get out of my head goes there first, unstructured and raw. There’s a bragdoc/ directory where wins get logged week by week, a decisions/ directory for significant decisions with their rationale, and a context/ folder containing reference material like team rosters, writing style guides, and even synthesised wisdom from leaders I admire.

Reports flow to reports/, organised by cadence. The structure reflects how I actually think about information: some things are temporary and need processing, some things are permanent records, some things are reference material I’ll query repeatedly. All of my interactions with these modules happen through natural language in the terminal: I don’t click around in different apps, I just ask Claude to do what I need. The whole thing is backed by a private repository on GitHub, which keeps everything in sync and versioned.

One pattern worth highlighting: I deliberately separate quick capture from task tracking. inbox.md is temporary and unstructured; it’s where thoughts go when I need to get them out of my head quickly. Linear is our ticket tracking system at work, and I have a private team on there called CTO that I use as the backing store for all of my todos.

The distinction matters because it removes friction from capture. I can dump anything into the inbox without worrying about whether it’s a real task, what priority it should be, or which project it belongs to. Later, when I run /triage, Claude helps me process the inbox: categorising items as actions, reference, or done, converting the actions into Linear tickets, and clearing out what’s no longer relevant.

The result is a system where information has a natural lifecycle: capture in the inbox, triage into tasks or reference, execution tracked in Linear, wins recorded in the bragdoc, and decisions logged for future reference. The CLAUDE.md file ties it all together, defining not just where things live but how Claude should behave when working with them.

What I find most useful is that it specifies eleven different roles Claude can adopt depending on what I’m doing, from Executive Assistant for routine tasks to Sparring Partner for stress-testing ideas. It defines slash commands that orchestrate complex workflows across multiple systems. And it encodes working principles, so Claude’s default behaviour aligns with how I actually want to work.

At a very high level, this is my information loop:

That’s the architecture at a high level, but I’ve skimmed over a lot of the detail. Through the rest of this article, we’ll dig deeper into how it all actually works: what the roles do and why they matter, how the integrations combine to produce real outputs, and what the daily workflows look like in practice.

The roles

I’ve always liked the idea of having a council of advisors available around the clock: people I can consult when I’m stuck, who can challenge my thinking, help me prepare for difficult conversations, or just sanity-check a decision before I commit to it.

In practice, of course, that’s not how leadership works: your peers have their own priorities, your exec isn’t available at 11pm, and your team shouldn’t be your sounding board for everything. But you can build that council synthetically, and defining roles is how you get there.