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 /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:

# 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.