/workflow-mastery

name: workflow-mastery
description: >
  Claude Code workflow mastery for .NET developers. Covers parallel execution
  with git worktrees, plan mode strategy, verification loops, auto-formatting
  hooks, permission setup for dotnet CLI, prompting techniques, subagent
  patterns, and context discipline — token budget management, MCP-first
  navigation, lazy loading, and subagent isolation — all adapted for the
  .NET ecosystem.
  Load this skill when setting up Claude Code for a .NET project, optimizing
  workflows, running parallel sessions, when context is running low or sessions
  feel sluggish, when exploring a large codebase efficiently, or when the user
  mentions "productivity", "workflow", "parallel", "worktree", "plan mode",
  "permissions", "hooks", "10x", "setup Claude Code", "speed up development",
  "context", "tokens", "budget", "running out of context", "too many files",
  or "large codebase".
  Inspired by tips from Boris Cherny (creator of Claude Code) and the Anthropic team.

Workflow Mastery for .NET

Core Principles

1. **Parallel over sequential** — Run 3-5 Claude sessions simultaneously using git worktrees. Build a feature in one, fix a bug in another, run tests in a third. The single biggest productivity unlock. 2. **Plan then execute** — For any non-trivial task, start in plan mode, iterate until the plan is bulletproof, then switch to auto-accept. A good plan means Claude 1-shots the implementation. 3. **Verification closes the loop** — Give Claude a way to prove its work: `dotnet build`, `dotnet test`, `get_diagnostics` via MCP. This single practice 2-3x the quality of the output. 4. **Context is a budget, not a dumping ground** — The context window fills fast: a typical .cs file is 500-2000 tokens, and 50 file reads can burn a large share of the budget. Spend tokens like sprint capacity — deliberately. 5. **Automate the repetitive** — If you do it more than once a day, make it a hook, a slash command, or a subagent. Pre-allow safe permissions. Eliminate friction. 6. **Compound your knowledge** — Every correction becomes a rule in `MEMORY.md` (see `instinct-system` skill). Every PR review adds a learning. Over time, Claude's mistake rate drops because your project's knowledge base grows.

Patterns

Parallel Sessions with Git Worktrees

The biggest productivity multiplier. Each worktree gets its own Claude session, its own files, zero conflicts.

# Create worktrees for parallel work
git worktree add ../my-project-feature origin/main
git worktree add ../my-project-bugfix origin/main
git worktree add ../my-project-tests origin/main

# Start Claude in each (separate terminal tabs)
cd ../my-project-feature && claude
cd ../my-project-bugfix && claude
cd ../my-project-tests && claude

**Practical .NET workflow:**

| Worktree | Task | Claude Session | |----------|------|---------------| | `feature` | Build new endpoint + handler | Main development | | `bugfix` | Fix the failing CI test | Autonomous bug fix | | `tests` | Write integration tests for existing feature | Test generation | | `analysis` | Query the Roslyn MCP, read logs, review architecture | Read-only research |

**Tips:**

• Name your terminal tabs by task so you never lose track
• Use shell aliases (`alias zf='cd ../my-project-feature'`) for one-keystroke switching
• Enable terminal notifications so you know when a session needs input

Auto-Format Hook for .NET

Catch formatting issues on every file write — eliminates the "CI failed on formatting" loop.

// .claude/settings.json
{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "dotnet format --include \"$CLAUDE_FILE_PATH\" --no-restore 2>/dev/null || true"
          }
        ]
      }
    ]
  }
}

Why `|| true`: The hook should never block Claude's workflow. If formatting fails (e.g., on a non-C# file), silently continue.

Pre-Allow Safe .NET Permissions

Stop clicking "allow" for every `dotnet` command. Add these to `.claude/settings.json`:

{
  "permissions": {
    "allow": [
      "Bash(dotnet build *)",
      "Bash(dotnet test *)",
      "Bash(dotnet run *)",
      "Bash(dotnet ef *)",
      "Bash(dotnet format *)",
      "Bash(dotnet restore *)",
      "Bash(dotnet pack *)",
      "Bash(dotnet tool *)"
    ]
  }
}

Check this into git so the whole team gets frictionless workflows.

Plan Mode Strategy

For any task touching 3+ files or involving architecture decisions:

Step 1: Enter plan mode (Shift+Tab twice)
Step 2: Describe the task with full context
Step 3: Iterate on the plan — challenge assumptions, ask "what about edge cases?"
Step 4: Once the plan is solid, switch to normal mode
Step 5: Claude executes with auto-accept — often 1-shots the implementation

**Advanced pattern:** Have one Claude write the plan, then spin up a second Claude session to review it as a staff engineer:

"Review this plan as a staff .NET engineer. Challenge every assumption.
What could go wrong? What's missing? What would you do differently?"

**When things go sideways:** The moment implementation deviates from the plan, STOP. Don't push through. Switch back to plan mode, understand what changed, re-plan, then resume.

Verification Loop for .NET

> For the full 7-phase verification pipeline (build, diagnostics, anti-patterns, tests, security, format, diff review) with structured PASS/FAIL reporting, see the **verify** skill.

Boris's #1 tip: "Give Claude a way to verify its work." The short version: always tell Claude to run `dotnet build`, `dotnet test`, `get_diagnostics`, and `dotnet format --verify-no-changes` before declaring done. The verify skill has the complete pipeline with short-circuit rules and report templates.

Compounding Knowledge via Corrections

For the full correction capture system — detection, generalization, categorized storage, and periodic audits —