From Solo Coder to Orchestrator: How Claude Code in Action Changes Your Daily Workflow

Key Takeaways

• →"Context engineering" — deciding what enters the context window, when, and what gets dropped — is the core operational skill that separates productive Claude Code sessions from frustrating ones
• →The allow/ask/deny permissions in .claude/settings.json take 5 minutes to set up and eliminate most routine approval friction
• →GitHub MCP is the single highest-leverage integration for most teams — replaces browser context-switching with a direct prompt
• →Slash commands in .claude/commands/ turn repeated prompts into one-tap workflows; commit them to git and the whole team inherits your standards
• →Hooks are guarantees, not suggestions — anything that MUST happen (formatting, security scans, tests) belongs in a hook, not in CLAUDE.md

This post is Part 3 of the Claude's Badges series — real-world guides to getting more from Claude.

Introduction

There's a particular frustration that hits developers a few weeks into using Claude Code. They've learned the basics. They understand the agentic loop. They've written a CLAUDE.md. And yet — somehow — their workflow isn't transformed. They're shipping faster on small tasks, sure. But the big stuff still feels like the big stuff.

I had this exact frustration. The gap, it turns out, isn't knowledge. It's operational design.

Knowing how Claude Code works is the easy part. Actually integrating it into your daily workflow — your GitHub processes, your code review rituals, your CI pipeline, your file-system muscle memory — is where the real productivity gains live. And almost nobody talks about this part.

This blog is about closing that gap.

---

The Difference Between a Tool and a Workflow

A tool sits on your desk. A workflow uses the tool to produce results consistently.

Most developers treat Claude Code as a tool. They open it when they need help, ask a question, get an answer, close it. Useful, but not transformative.

Treating it as a workflow means designing the system around it: when does Claude get invoked, by whom, for what, with what context, with what guardrails, producing what output, integrated with what downstream system.

That sounds like overhead. It's actually the opposite — the more deliberate the workflow, the less you have to think about it day-to-day. The setup amortizes over hundreds of invocations.

---

Context Engineering: The Skill Nobody Names

There's a discipline emerging in agentic coding that doesn't have a great name yet. People call it "context engineering." The discipline is: deciding what information goes into Claude's context window, when it goes there, and what gets dropped.

Every byte of context is either helping Claude or wasting attention. Productive sessions = controlled context. Frustrating sessions = bloated context.

Here are the levers:

• →File references over file paste. Don't paste code into the prompt — use @path/to/file and let Claude read it. Same information, better integrated, doesn't pollute the prompt history.
• →Subagents for exploration. If a question requires reading more than 3 files, send a subagent. The subagent reads in its own context, returns a summary, and your main context stays clean.
• →Proactive compaction. Run /compact before you need it, not after. Don't wait until Claude is slow and forgetting things. Compact at natural break points.
• →Save findings to disk. When a session produces important conclusions, have Claude write them to a notes/ folder. Future sessions can reference them without redoing the work.
• →Commit logs as memory. Use CHANGELOG.md as a place where Claude records major changes over time. Future-you (and future Claude) can read the changelog instead of re-deriving context from the codebase.

The pattern across all these: be deliberate about what's in context, intentional about what gets discarded, and persistent about what should survive across sessions.

---

Permissions: The 5-Minute Setup That Saves Hours

The default permission model is "ask before doing anything significant." That's safe but slow — every Bash command needs approval, every file edit pauses for confirmation.

The fix is a 5-minute investment in .claude/settings.json:

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(git status)",
      "Bash(git diff)",
      "Bash(git add *)",
      "Bash(git commit *)"
    ],
    "ask": [
      "Bash(git push:*)",
      "Bash(npm install *)"
    ],
    "deny": [
      "Read(./.env*)",
      "Read(./secrets/**)",
      "Bash(rm -rf:*)",
      "Bash(curl:*)"
    ]
  }
}

Three lists, three behaviors. Allow runs without asking. Ask still pauses for confirmation. Deny rejects outright.

Tune this once per project and the friction disappears. Routine commands flow without interruption. Risky operations still pause. Dangerous patterns are blocked entirely.

One subtle gotcha: wildcards work for native tools but not for MCP tools. Bash(npm *) works. mcp__github__* does not. For MCP, list each tool individually or allow the whole server.

---

MCP: Where Claude Code Stops Being a Code Editor

Most developers' Claude Code setup is files plus terminal. Claude reads files and runs Bash commands. That's the default, and it's already useful.

But there's a whole layer above that called MCP — Model Context Protocol — that lets Claude talk to external systems. Once you wire it up, Claude becomes less of a code editor and more of a development orchestrator.

The high-value MCP servers worth setting up:

• →GitHub MCP — Read PRs, fetch diffs, post review comments, manage issues. The single highest-leverage MCP for most teams. Replaces the "switch to browser, scroll through diff, write feedback, paste back" cycle with a one-shot prompt.
• →Playwright/Puppeteer MCP — Drive a real browser. Take screenshots. Click around. Compare visual output to design mocks. Game-changer for frontend work where "does this look right" is half the question.
• →Database MCP — Query Postgres, MySQL, SQLite directly. Validate data assumptions during debugging. Inspect schema before writing migrations.
• →Sentry MCP — Pull error reports during debugging. Tie crashes to commits.
• →Custom internal MCPs — Wrap your team's APIs. Now Claude can interact with your internal tools natively.

The reframing once you have a few MCPs running: Claude isn't editing code anymore. Claude is running your dev environment, with code editing being one of many things it does.

---

Visual Inputs: The Underused Power Move

Here's something most developers don't try: pasting screenshots into Claude Code.

You don't need to describe a UI bug in words. Drop a screenshot of the broken state and ask "why is this misaligned?" Combined with file references to the relevant components, this often gives faster, better results than any amount of textual description.

Where this excels:

• →Debugging visual bugs — paste screenshot of the wrong state alongside the relevant component file
• →Implementing from designs — paste the design mock, then "implement this component"
• →Explaining errors — paste the error UI from the browser console
• →Layout changes — paste a screenshot of the current state, describe the desired state

Combined with Playwright MCP, the loop becomes: Claude makes a code change → Claude takes a screenshot → Claude compares to the target → Claude iterates until it matches. Manual visual QA becomes automatic visual verification.

---

Custom Slash Commands: Codifying Your Team's Standards

Slash commands are markdown files in .claude/commands/ that turn repeatable prompts into one-tap workflows. The mechanism is dead simple. The leverage is enormous.

If you've typed the same prompt twice this week, it should be a slash command.

Examples worth building:

• →/review — Run git diff, review changes against your team's checklist, flag bugs/security/style issues
• →/pr — Generate a PR description from staged changes
• →/migrate — Apply a class of refactor across multiple files following a specific pattern
• →/debug — Reproduce a failing test, trace the root cause, suggest fixes
• →/audit — Check the project for vulnerable dependencies and propose updates
• →/docs — Generate or update API documentation from the current code

Each command lives as a markdown file:

# /review command

## Steps
1. Run `git diff --staged` to see all changes
2. Review for: bugs, security issues, missing tests, style violations
3. Report findings as: [SEVERITY] file:line — description

## Standards
- All exported functions must have JSDoc
- No console.log in production code
- Database queries must use parameterized statements

Commit .claude/commands/ to your repo. The whole team gets the same workflow, the same standards, the same one-tap invocation.

The compounding effect: as your team builds out 10–15 commands, you've effectively encoded your engineering standards as executable prompts. New hires inherit them automatically. Standards get followed because invoking them is easier than not.

---

GitHub Integration: Two Patterns That Actually Work

There are a lot of ways to integrate Claude Code with GitHub. Two patterns cover most teams' needs.

Pattern 1: Local PR Workflow

You're working locally. A slash command does the work:

1. 1./pr runs git diff, summarizes changes
2. 2.Creates a branch (if not on one)
3. 3.Generates commit message + PR description
4. 4.Pushes and creates PR via GitHub MCP

Total time from "I'm done coding" to "PR is up": about 30 seconds.

Pattern 2: Automated Review in CI

Triggered by GitHub Actions on every PR open/update:

# .github/workflows/claude-review.yml
on: pull_request
jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - run: claude -p "Review this PR" --max-turns 5

Claude Code runs headlessly, reads the PR diff, evaluates it against your standards (encoded in CLAUDE.md and slash commands), posts findings as a PR comment.

Combined, these two patterns mean: PRs get reviewed by Claude before humans even look at them. Humans focus on what Claude flagged plus higher-level concerns. Review velocity goes up significantly.

---

Hooks: Making Standards Non-Optional

Prompts say "please." Hooks say "unconditionally." That distinction matters enormously at scale.

The hooks worth setting up early:

• →Auto-format on edit — PostToolUse on Edit/Write → run prettier/black/rustfmt
• →Test runner — PostToolUse on Edit → run affected tests
• →Dangerous command blocker — PreToolUse on Bash → reject rm -rf, chmod 777
• →Secrets scanner — PreToolUse on Write → grep for API keys before file is written
• →Audit log — PreToolUse on every tool → append to a log file with timestamp

The audit log is underrated. Especially for teams using Claude Code on shared codebases, having a record of every tool invocation creates accountability and makes incident review possible.

Two hook gotchas worth knowing:

1. 1.Hooks BLOCK Claude. If your hook hangs, Claude waits. Default timeout is 10 minutes. Customize per hook for slow operations.
2. 2.Test hooks manually before deploying. They're shell scripts. Debug them like any shell script — they're not magic.

---

The Common Anti-Patterns

Things to avoid, learned the hard way:

• →Skipping Plan Mode for non-trivial changes — Plan Mode (Shift+Tab) is free oversight, use it
• →Letting context bloat — run /compact proactively, not after things slow down
• →Putting everything in CLAUDE.md — specialized reference material belongs in Skills, not CLAUDE.md
• →Running with full permissions in a fresh repo — always review what Claude can touch before turning it loose
• →Asking nicely instead of using a hook — "please always format code" is a wish, a PostToolUse hook is a guarantee
• →Using only Bash + Edit, never trying MCP — you're missing the most powerful integration layer
• →Building one giant "do-everything" subagent — subagents are most effective with one focused job

---

The Operational Stack

After enough iteration, productive teams converge on a similar setup:

• →CLAUDE.md for always-relevant project context
• →.claude/commands/ for repeatable workflows (10–15 commands typical)
• →.claude/agents/ for specialized subagents (5–8 typical)
• →.claude/settings.json for permissions and hooks
• →MCP servers for GitHub, browser, database, error tracking
• →Hooks for formatting, testing, security guardrails
• →CI integration for automated PR review

Each layer compounds on the others. The setup pays for itself within weeks and keeps paying every day after.

---

Where to Start (Realistically)

If you're already using Claude Code but want to level up your operational game:

1. 1.Tighten your permissions — 15 minutes, eliminates routine approval friction
2. 2.Add one MCP server (GitHub is the highest-leverage starter)
3. 3.Build three slash commands — pick your three most-repeated prompts
4. 4.Write one hook — auto-formatter is the easiest win
5. 5.Create one subagent — a code-reviewer tuned to your project
6. 6.Set up automated PR review in CI — once the rest is in place, this is a multiplier

Each step is a few hours of work. Together, they transform Claude Code from a useful tool into a workflow that ships.

---

*Inspired by the official Claude Code in Action course — free, takes a few hours, and worth doing if you're past the basics and want to build a serious operational setup.*