undefined

**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

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

{
  "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 *)"
    ]
  }
}

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

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

"Grill me on these changes. Would this pass a staff .NET engineer's code review?
Check for: N+1 queries, missing CancellationToken, exposed domain entities,
missing validation, incorrect service lifetimes."

"Prove this works. Run the tests, show me the output.
Then diff the API response between main and this branch."

"Knowing everything you know now, scrap this and implement the elegant solution.
No hacks, no workarounds."

"Generate the migration, then show me the raw SQL it produces.
I want to verify the migration before applying it."

"Run the code-reviewer agent on my changes before I create the PR."
"Have refactor-cleaner simplify the files I just modified."
"Send the failing CI log to build-error-resolver."

OFFLOAD TO A SUBAGENT WHEN:
- Exploring unfamiliar code (> 3 files to read)
- Research requiring docs or multiple files
- Verbose output (test runs, diagnostics, comparisons)
- Any task where the journey is verbose but the answer is concise

STAY IN MAIN CONTEXT WHEN:
- Modifying a file you've already read
- Quick lookups (1-2 MCP queries)
- Work that builds on the ongoing conversation with the user

PRIORITY 1 — Files you will modify: read fully (exact content needed for edits)
PRIORITY 2 — Contracts you must satisfy: read the interface, skip implementations
PRIORITY 3 — Reference patterns: get_public_api first, read only if insufficient
PRIORITY 4 — General context: subagent summarizes; never read in main context

NEVER READ: entire directories (get_project_graph), test files for context
(get_test_coverage_map), generated files/migrations, configs unless needed

WARNING SIGNS: 10+ files read, 50+ exchanges, forgetting earlier details,
re-reading files you already saw

RECOVERY: summarize what you know in 5-10 lines → subagents for remaining
exploration → MCP-only lookups → suggest a fresh session if still degraded

LARGE CODEBASES (50+ projects): get_project_graph → narrow to 2-3 relevant
projects → find_symbol for key types → get_public_api for interfaces →
read ONLY files you'll modify → subagents for cross-cutting concerns

// BAD — dive straight into a multi-file refactor
"Refactor the Orders module to use DDD with aggregates and value objects"
*Claude modifies 15 files, misses half the invariants, tangles the migration*

// GOOD — plan first, execute after
"Enter plan mode. I want to refactor the Orders module to use DDD.
Let's plan which files change, what the aggregate boundary is,
how value objects map to EF Core, and what the migration strategy is."

// BAD — sequential work in one session
1. Build feature       (20 min)
2. Write tests         (15 min)
3. Fix formatting      (5 min)
4. Update docs         (10 min)
Total: 50 minutes

// GOOD — parallel worktrees
Worktree 1: Build feature     (20 min)
Worktree 2: Write tests       (15 min, started simultaneously)
Worktree 3: Update docs       (10 min, started simultaneously)
Total: ~20 minutes (wall clock)

// BAD — accept mediocre code
Claude: "Here's the implementation" *generic, works but not great*
You: "Looks good, ship it"

// GOOD — push for quality
Claude: "Here's the implementation"
You: "Would a staff .NET engineer approve this?
      What about the service lifetime? Is this N+1 safe?
      Is there a more elegant way using C# 14 features?"

// BAD — "the context window is huge, let's load everything"
Read all 30 files in the Orders module, all 15 test files,
docker-compose.yml, every migration
*80k tokens consumed before writing a single line of code*

// GOOD — minimum viable context
MCP: get_project_graph (solution shape) + find_symbol (locate targets)
Read: the 2-3 files you'll actually modify
Subagent: summarize anything else
*~3k tokens consumed, the rest free for actual work*