My Claude Code Operating System: 20 Agents, 8 Skills, and 11 Hooks for a Complete Dev Workflow

The Problem: 195 Daily Interactions With No System

I was running 195+ Claude Code interactions per day — building a production SaaS app with AI agents, document extraction, payment processing, and 30 real users. But I was doing it chaotically: unnamed sessions I couldn't find later, manually checking deployments after every push, context windows degrading without me noticing, and 33 MCP servers burning tokens before I typed a word.

So I built an operating system. Not an app — a daily workflow system built entirely from Claude Code's native features: 20 custom agents, 8 slash command skills, 11 hooks, 5 shell aliases, and structured audit logging. Here's the complete guide to using it.

The Architecture: What's Running

20 Custom Agents    → specialized AI workers for every domain
 8 Skills           → one-command workflows that chain agents  
11 Hooks            → deterministic automation on every action
 5 Shell Aliases    → terminal shortcuts for named sessions
 2 Log Files        → audit trail + error tracking
 1 Rotation Script  → weekly log cleanup
11 MCP Servers      → pruned from 33 (60% token savings)

Morning Routine: 3 Commands, 10 Minutes

Command 1: The Morning Briefing

ccmorning

This single alias opens a named Claude Code session and runs the /morning skill. That skill uses dynamic context injection (! backtick syntax) to pre-load your git state before the LLM even starts thinking:

- Branch: !`git branch --show-current`
- Last staging deploy: !`git log --oneline origin/staging -1`  
- Staging ahead of prod by: !`git rev-list --count origin/main..origin/staging` commits
- Nightly QA: !`gh run list --workflow=nightly-qa.yml --limit=1`

Then it spawns 3 agents in parallel:

1. @client-pulse (background) — queries pipeline distribution, stuck returns, unpaid invoices, missed calls
2. @nightly-qa-runner (background) — checks GitHub Actions results, correlates failures with recent commits
3. Sentry + Vercel check (foreground) — unresolved errors, latest deployments, 500 error count

Output: a unified brief with a "Recommended First Task" based on everything it found.

Command 2: Fix Whatever the Brief Found

The morning brief tells you what to do first. If a client is stuck:

/debug-client "Vikas Goyal"

This chains the @onboarding-debugger agent (full DB diagnosis) + Resend email delivery check + Sentry error search for that user. Outputs ready-to-execute SQL fixes.

Command 3: Deploy if Staging is Ahead

/deploy prod

Per-Task Workflow: Features, Bugs, Deploys

Starting a New Feature

Always start with a named session:

cc feature-tax-planning

The cc alias is a wrapper: claude -n "feature-tax-planning". Named sessions show up in /resume, so you can find them later.

Step 1: Interview before building.

/interview add tax planning page with estimated refund projections

This runs a 7-phase structured interview using Claude's AskUserQuestion tool — one question at a time, not a form dump:

Phase 1: Requirements (3-5 questions)
Phase 2: Data Model (2-4 questions)  
Phase 3: Architecture (2-4 questions)
Phase 4: Edge Cases & Error States (3-5 questions)
Phase 5: Security & Privacy (2-3 questions)
Phase 6: Testing Strategy (2-3 questions)
Phase 7: UX & Design (2-3 questions)

Outputs a complete spec with mermaid diagrams to docs/specs/feature-name.md.

Step 2: Review the plan before coding.

/review

Spawns 4 parallel review agents, each with domain-specific criteria:

Verdict: APPROVE, CHANGES REQUESTED, or BLOCK. Any security blocker = hard block.

Step 3: Implement. Then /review again before committing.

Fixing a Bug

Pick the right debugger agent:

Each debugger has a multi-step investigation protocol. For example, @email-debugger traces through 5 layers: caller → email-gate (dedup) → email-brain (AI evaluation) → email-log (recording) → Resend (delivery). It checks trigger consistency, daily caps, and known failure patterns automatically.

Deploying

/deploy

This is a 7-stage pipeline skill — the most advanced thing I built:

STAGE 1: Pre-flight — branch, author, uncommitted changes
STAGE 2: tsc + @pre-push-audit (parallel)
STAGE 3: Push to staging
STAGE 4: Monitor Vercel deployment (polls every 60s for 5 min)
STAGE 5: Post-deploy health check (Sentry + 500s + site load)
STAGE 6: "Promote to prod?" → push staging to main
STAGE 7: Spawn @deploy-monitor in background for 10 min

The skill uses dynamic context injection to pre-load your branch, staged files, and staging-vs-prod diff before the pipeline starts. If tsc finds type errors, it hard-stops. If Sentry finds new errors post-deploy, it warns you.

The 11 Hooks: What Fires Automatically

These run on every action without you thinking about them:

PreToolUse (4 hooks — fire before commands execute)

Key optimization: Hooks #2-4 use the if field (v2.1.85) to filter by command pattern. Without this, all 4 hooks would spawn a process on every Bash command — ~90% of which aren't git operations. The if field eliminates those wasted process spawns.

PostToolUse (3 hooks — fire after actions complete)

SessionStart (2 hooks)

Stop + StopFailure (2 hooks)

The 20 Agents: Your Specialized Workforce

Core Workflow (6 agents)

Operations (6 agents)

Debugging (4 agents)

Maintenance (4 agents)

Model selection strategy: Opus for anything that requires judgment (security, debugging, incidents). Sonnet for speed-sensitive operations (monitoring, deployment, maintenance scans).

MCP Server Pruning: 33 → 11

Every connected MCP server costs tokens on every message. Heavy setups (5+ servers) can burn 50,000+ tokens before your first prompt. I was running 33 servers.

After auditing with /context:

• Kept 11: GitHub, Vercel, Supabase, Resend, Stripe, Sentry, Context7, Sequential Thinking, Playwright, Linear, Ideogram
• Disabled 10: duplicate Sentry (two configs), OpenAI Image (overlap with Ideogram), Nano Banana (rarely used), Better Stack (80+ tools!), Azure, Applitools, TestSprite, BrowserStack, Pest, PostHog

Estimated 40-60% reduction in per-message token overhead. Better Stack alone was loading 80+ tool definitions into every conversation.

Mid-Session Commands You Should Memorize

Weekly Maintenance Schedule

The Cheat Sheet

MORNING:      ccmorning
NEW FEATURE:  cc feature-name → /interview → build → /review → /deploy
BUG FIX:      cc bugfix-name → @[debugger] → fix → /review → /deploy  
DEPLOY:       /deploy (or ccdeploy from terminal)
QUICK Q:      /btw question
LONG SESSION: /compact Focus on X
CLIENT STUCK: /debug-client "name"
STANDUP:      /standup
INCIDENT:     cc incident → @incident-triage
WEEKLY:       @dependency-checker @db-health @prompt-auditor @perf-profiler

What Changed After Building This

Before: 195 interactions/day, chaotic, manually checking everything, unnamed sessions I couldn't find, context degrading without me noticing.

After:

• Morning brief in one command instead of checking 4 dashboards
• Zero manual deployment monitoring — the /deploy skill handles the full pipeline
• 4-reviewer code review runs in parallel before every commit
• Every Bash command logged with structured JSON — full audit trail
• Rate limits and API errors trigger macOS notifications with sound
• 40-60% less token overhead from MCP pruning
• Named sessions I can find and resume

The key insight: Claude Code's hooks, agents, and skills aren't just features — they're primitives for building a personal development operating system. The agents handle domain expertise. The skills chain agents into workflows. The hooks enforce rules deterministically. And the aliases make it all muscle memory.

Start with ccmorning tomorrow. That one command replaces 15 minutes of manual checking.