I copied a prompt and built a management system in a week

I’d been reading about people building personal operating systems with Claude Code. Someone had started a new CTO role, opened a folder, and asked Claude to make them the best CTO possible. Three weeks later, they had a system that:

processed meetings,
prepared 1:1s,
and logged decisions from markdown files and slash commands.

I read about it on a Tuesday afternoon. I borrowed some of the ideas. By the following Tuesday, I had something of my own.

I’m not a startup CTO. I’m a Director of Software Development at thoughtbot, a consultancy. I manage team leads. They manage developers on client projects I’ve never seen before. My days are meetings, Slack, and decisions. Those decisions ripple through people I trust to make their own calls. I ship code, but the management side was the part I was drowning in. The system I needed wasn’t a cockpit. It was a way to keep track of everything without losing my mind.

Tuesday: seven commits in thirty-five minutes

The first commit landed at 5.08pm. I fed Claude my afternoon’s meeting notes and built a /morning briefing command. I added leadership frameworks from Claire Hughes Johnson’s Scaling People. Claude generated eighteen files of textbook material.

Here’s what /morning looked like at that point. A markdown file that tells Claude what to do when you type the command:

# Morning Routine Command

Start your day with a briefing and sync of overnight activity.

## Instructions

### Step 1: Sync Overnight Meetings

Run the `/meetsync` workflow to process any meeting transcripts
from the last 24 hours that haven't been processed yet.

### Step 2: Get Today's Calendar

Use the Rube MCP to query Google Calendar for today's meetings...

### Step 3: Gather Context

Read the following files to build context:

1. `active/projects/project-tracker.md`
2. `active/hiring/pipeline.md`
3. `logs/meetings/` - Scan recent meeting notes for open action items
4. `team/roster.md` - Note any team health concerns

That’s the entire prompt. You write instructions in plain English, and Claude follows them. No API calls, no configuration. A Markdown file that says, “Read these files and tell me what matters.”

None of it was correct. The first commit generated eighteen files. A DACI decision matrix. A delegation framework. A time management guide. Textbook stuff that had nothing to do with how we actually work. By commit seven, I was ripping it all out:

## Decision Making

### Default: Self-Directed

Most decisions don't need approval. The default is:

1. **Make the call** - You're trusted to decide within your domain
2. **Keep people informed** - Share what you decided and why
3. **Ask for input if unsure** - Consult others when it would help

That replaced a DACI matrix nobody on my team has ever used. The system’s first lesson: the generic version is always wrong. You have to feed it what’s actually true.

Wednesday: the first bug becomes the first feature

I processed two meetings into markdown. The /evening command appeared. I hadn’t planned a daily reflection habit. The day ended, and I wanted to capture what had happened before I forgot it:

# Evening Routine Command

Complete your daily log with end-of-day reflection.

### Step 3: Prompt for Reflection

Ask the user:

1. What did you accomplish today?
2. Any decisions worth noting?
3. Any wins to celebrate?
4. What blocked you or got deferred?
5. What are your top 3 priorities for tomorrow?
6. Energy level (1-10)?

Then Claude misspelt someone’s name. “Agie” instead of “Aji.” I corrected it, then thought, “This will happen again.” By evening, we’d built a /review command. It loads names from the team roster and flags anything unrecognised:

### Step 2: Name Consistency Check

1. Load known names from `team/roster.md`
2. Scan each file for names not in roster
3. Flag potential misspellings using fuzzy matching

Present any unrecognized names with suggestions:
- "Agie" - possible misspelling of "Aji"?

One transcription error produced a feature I use every day. The system was already teaching me what it needed to become.

The transcripts themselves aren’t perfect. Gemini’s summaries are good enough to jog my memory, but I wouldn’t trust them for exact quotes or emotional nuance. Gemini flattens tone. A heated discussion reads the same as a calm one. I’ve learned to add my own notes for anything where the conversation’s tone mattered.

Thursday: the system proves its worth

I had a skip-level 1:1 with someone I’d never met one-on-one. The existing /prep command handled regular check-ins, but this was a first meeting. So I enhanced it. Meeting type detection, purpose framing, tenure-appropriate questions:

## Meeting Posture
- Listen 80%, talk 20%
- Don't make decisions in the moment
- Note patterns across skip-levels, not individual attributions

## Suggested Questions

**For newer team members**:
- How have things been going since joining?
- What's working well on the team? What could be better?
- Do you have what you need to do your job?

The system emerges from the work. I didn’t plan “add skip-level support.” I had a meeting at 12.50pm, and the tool wasn’t ready for it.

I processed four meetings that day. I refactored the daily log template. Version one had “Open Action Items” and “Things Today” as separate sections. They needed to be together:

### Today

**Completed**:

- [x] Team Leads meeting
- [x] Skip-level with Mina

**Work**:

- [ ] Follow up on delivery ownership model
- [ ] Nick 1:1 prep for performance coaching

Three working days. By Thursday evening, I had six tools. Morning briefing. Evening reflection. Meeting notes. Team roster. Project tracker. Review command. I didn’t plan any of it.

Monday: the system starts maintaining itself

Over the weekend, I did nothing. Monday arrived, and I made twenty-eight commits. But they weren’t features. They were infrastructure. Markdown linting. A pre-commit hook. The project tracker got split into individual files.

The most important command appeared on Monday: /retro. Every session ends with it. It reviews what happened and recommends changes to the system:

# Retro Command

Review the current session and identify improvements to
commands, documents, or workflows.

### Step 2: Analyze Existing Commands

- Which commands were used? Did they work well?
- Are any commands stale or no longer needed?
- Are there gaps based on session activities?

### Step 4: Present Recommendations

**Add**: [new command or document + rationale]
**Drop**: [stale item + why no longer needed]
**Refactor**: [existing item + suggested improvement]

/retro is the engine that powers everything else. I rewrote /morning, /evening, /review, and /prep many times. Each time, /retro flagged something that could be better. The system builds itself.

The significant change was architectural. I realised Things (my task manager) should own projects and next actions. The repository holds support material only. I refactored every project file to a minimal format:

# Project Title

**Things project**: [Name of Things project]

## Outcome

[What does "done" look like?]

## Plan

1. Step one
2. Step two

## Reference

- [Link to relevant doc](url)

Three fields. Outcome, plan, reference. Everything else lives in Things. Task manager for what to do. Repository for why and how. That turned out to be the most critical decision of the week.

Tuesday: the unexpected shift

By Tuesday, I’d processed a 1:1 with my boss where we discussed this exact experiment. That evening, I wrote in the wins log:

Knowing AI will capture information makes you articulate things more clearly in calls.

That’s the thing nobody tells you about these systems. The productivity gains are real. I walked into every meeting prepared. Nothing fell through the cracks. Decisions got documented with their rationale. But the unexpected shift was behavioural. When you know the system is listening, you measure your words. You say what you actually mean. The AI captures your work and makes you better at the work itself.

The productivity gains come with a trade-off. Knowing everything creates more work. I notice things I would have missed before. A passing comment in a skip-level that hints at a team dynamic issue. An action item from two weeks ago that nobody followed up on. Whether that’s a net gain depends on whether I needed to notice those things. It feels like I did, but I’ll have better evidence after a few more weeks.

What’s next

The whole repository is private. It contains real team data. But the commands, templates, and formats you’ve seen here? Drop them into your own Claude Code setup today. Start with one command that solves a problem you actually have. The system will tell you what it needs next.