---
title: Sixty-six commits and the commands that didn't survive
teaser: 'In week two of building a management system with Claude Code, I created fifteen
  commands in a day. By the end of the week, I''d deleted three of them.

  '
tags: claude code,ai,artificial intelligence,management,gtd,productivity
author: Rob Whittaker
published_on: 2026-04-08
---

## 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][week-1]. That post covered
the foundation:

- meeting transcripts,
- daily logs,
- a `/morning` command 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:

```markdown
# 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][bnw]
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.

[week-1]: https://thoughtbot.com/blog/i-copied-a-prompt-and-built-a-management-system-in-a-week
[bnw]: https://www.bravenewwork.com/