Sixty-six commits and the commands that didn’t survive
Last week, I wrote about building a management system with Claude Code in a week. That post covered the foundation:
- meeting transcripts,
- daily logs,
- a
/morningcommand that pulls everything together.
By the end of week one, I had something useful. Week two is where I found out what “useful” actually meant.
Sixty-six commits in seven days. Fifteen commands created. Three deleted. The system grew, then pruned itself.
Tuesday: the explosion
Tuesday was the most productive day I’ve had with this
system. I made twenty-eight commits. The morning started
with refactoring my goals into concrete project files. By
lunchtime, I’d created /inbox, a command to process my
Things inbox one item at a time, following the GTD
clarify-and-organise workflow.
The /inbox command was ambitious. It identified whether
an item was a project or a single action. It created
Things tasks, support files, and Trello cards in one
operation. It detected duplicates. It had a --dry-run
flag. By the afternoon I’d:
- added single-item processing,
- an “already-actioned” flow for items I’d dealt with but hadn’t tracked,
- and inline project creation, so I didn’t have to break out of the processing loop.
Then came /delegate, a Slack-based delegation command
that sent a message, created a waiting task, and set a
follow-up deadline. And /waiting, a simpler version for
things that didn’t need a Slack message.
Here’s what /waiting looked like:
# Waiting Command
Create a "Waiting for" task to track a delegated
item or pending response.
## Arguments
- `<person> <topic>`: Create a waiting task
- No arguments: Prompt for person and topic
## Instructions
### Step 1: Parse Arguments
If arguments provided:
- First word = person
- Remaining words = topic
### Step 2: Gather Optional Details
1. Deadline: When to follow up if no response?
Default: 1 week from today
2. Project: Add to a project?
### Step 3: Create Waiting Task
Use `mcp__things__add_todo` with:
- title: "Waiting for [person] to respond RE: [topic]"
- tags: ["Waiting"]
- deadline: Selected deadline
Twenty lines of instructions. That’s all it takes to codify a GTD pattern that I repeat several times a week. The command doesn’t do anything clever. It only makes sure the task title, tag, and deadline are consistent every time.
Wednesday: real work surfaces real needs
Wednesday brought four meetings: a candidate interview,
two 1:1s, and a scheduling sync. The meeting transcripts
needed processing. The Coverage Sync document needed
updating. I built /covsync, a command that scans recent
meeting notes and extracts topics for the weekly Coverage
Sync document.
The difference between /covsync and /inbox lies in
their origins. /covsync emerged because I was sitting in
front of a Coverage Sync document that I needed to fill
out. /inbox emerged because I should have a command for
it.
The weekend: Brave New Work
On Sunday, I read Aaron Dignan’s Brave New Work and started applying it. I created project files for three initiatives:
- defining Fusion’s purpose,
- improving investment time visibility,
- and AI ethics guidelines.
Each one started with a tension, something that felt wrong about how the team operated, and a plan to address it through the team, not for the team.
That was the system doing something I hadn’t planned. It wasn’t only tracking my work. It was giving me a place to think about the kind of leader I wanted to be. A project file that starts with “the team will define their own purpose” is a different artefact from a task that says “write a purpose statement.”
Monday: the pruning
By Monday, I had too many commands. /inbox was the worst
offender. It tried to handle the full GTD workflow in a
single skill and had become unwieldy. I deleted it. I
deleted /project too. Both tried to codify processes
that worked better as conversations.
I also rewrote the commit message guidelines. The old
version said, “focus on why, not how.” The new version
gave a specific structure: Before, We wanted, We
did. Every commit since has followed this pattern. It’s a
small thing, but it lets me read the git history like a
journal.
What I learned
The commands that survived week two share a trait: they do
one thing, and I repeat it often enough to want
consistency. /waiting creates a task with the right
title format, tag, and deadline. /covsync gathers
meeting notes into a specific document format. /morning
assembles a briefing from five data sources.
The commands that died tried to be clever. /inbox tried
to handle every possible inbox item. /project tried to formalise something that worked
better as a conversation. They were frameworks for
hypothetical work rather than tools for actual work.
Sixty-six commits in a week is a lot. But the system is smaller now than it was on Tuesday. That feels right. The value isn’t in the number of commands. It’s in knowing which ones to keep.
If you’re building something like this, start with the commands you’d use today. Not the ones you think you’ll need.