Pragmatic Claude Code Usage for C# Developers on Mac

If you're a software developer who opens their RSS feed in the morning, checks YouTube, or reads the latest newsletters, you might get the impression you've accidentally ended up in a particle accelerator: every day, new AI tools, frameworks, and "revolutionary" workflows collide with each other – and each one naturally demands to be tried out immediately. Reality looks different. Between sprint meetings, code reviews, and maintaining existing systems, there's often little time for extended evaluation cycles.

At the same time, AI-assisted development is no longer a passing hype. Teams that effectively use AI coding tools report significant productivity gains – provided the onboarding effort remains manageable. This is exactly where this article comes in: a pragmatic approach that delivers good results with reasonable setup and learning effort. Not "here are 47 tools you all need to know," but a proven setup that has stood the test of daily .NET development on the Mac.

All skills, custom commands, and subagent configurations mentioned in this article are available in the accompanying GitHub repository.

The major coding LLMs were predominantly trained on Python, TypeScript, and JavaScript codebases. You can tell: ask Claude, GPT, or Gemini for a solution, and you'll frequently get idiomatic Python – with C#, however, you occasionally end up with patterns reminiscent of C# 8 rather than C# 14. Particularly current language features like Primary Constructors, Collection Expressions, or the field keyword are not automatically used by coding LLMs unless you explicitly guide them to do so.

The question that established .NET development teams therefore ask: Does AI-assisted development work with our tech stack too? And if so, how well?

The short answer: yes, it works – and better than you might expect. The key lies in providing the LLM with the necessary context about your own code standards, preferred language features, and project-specific patterns. For this purpose, Claude Code provides the right tools with Skills, CLAUDE.md, and Custom Commands (more on this in the following sections).

A pragmatic recommendation for practice: implement applications with long-term maintenance perspective in C# / .NET. For temporary tooling tasks like data migrations, build scripts, or analysis scripts, there's nothing wrong with Python – as long as they're not business-critical. Here you benefit from the stronger LLM training on Python and faster implementation.

We work with VS Code as our IDE on Mac. This isn't mandatory for C# developers but makes sense: the C# Dev Kit with its full feature set is tied to the Visual Studio Marketplace. IDE alternatives like Cursor or Windsurf use an alternative marketplace (without C# DevKit) and therefore don't offer the same .NET tooling convenience. JetBrains Rider is a valid alternative but comes at a higher price point.

The decisive advantage of Claude Code over IDE-integrated AI assistants: it runs in the terminal and doesn't block the IDE. Via Git worktrees, you can continue working on a different branch in the IDE while Claude Code independently implements a feature. In practice, this is a significant productivity gain – you don't have to "watch" the agent work but can use the time productively.

Additionally, Anthropic is often a pioneer in integrating new capabilities. Features like Skills, Agent Teams, or the plugin system were introduced in quick succession and continuously improved. The flexible extension and customization options via MCP servers, Skills, and Custom Commands make it possible to precisely adapt Claude Code to your own workflow – an aspect that isn't available at this depth in many alternatives. Nevertheless, OpenAI's Codex or Cursor from the command line should offer similar convenience and feature scope.

The following experience values are based on several projects; I'd like to focus particularly on a specific project here: an ASP.NET Razor Pages website for a martial arts club. The project is particularly well-suited as a reference because it required remarkable feature density on a limited budget: shop with shopping cart system, invoicing and order management, seminar booking with admin interface, dojo management with OpenStreetMap integration, registration with user profiles, CMS-based content pages via Directus Headless CMS (for which no official C# SDK exists – the client was implemented based on the REST API, partly by ourselves, partly by AI :)), full-text search with vector database, a custom AI assistant ("Karate-Cat") based on Microsoft Extensions AI, blog and news management with comment moderation, and much more.

The time savings from the AI-assisted development approach amount to at least 50%, realistically probably significantly more. This makes projects feasible that without AI support would either not be realized at all or only in a significantly stripped-down form.

Particularly noteworthy: features for which you would typically resort to SaaS solutions (such as a shopping cart system or seminar booking) could be implemented as integrated, tailored solutions. The entire system – from database to deployment – is provided and maintained by a single developer across all layers.

An often underestimated side effect: quick previews become possible, as images, texts, and other content can be generated and provided via AI until final data is available. This significantly accelerates feedback cycles with stakeholders.

With responsible implementation, however, considerable manual effort remains:

Many of these points are only relevant when you want to ensure long-term maintenance and don't apply to simple single-use tools created through pure "vibe coding" (usually in Python), e.g., for initial database population, generating video transcripts and thumbnails, etc.

Installing Claude Code itself is straightforward and described in the official documentation. For C# developers on Mac, the following prerequisites are also relevant:

Basic Requirements:

Claude Code Installation and Initial Setup:

The csharp-lsp plugin deserves special mention: it connects Claude Code via the Language Server Protocol with the C# language server, enabling IntelliSense-like functionality that the coding LLM can use for code analysis and generation.

After initial installation, the next step should be populating the CLAUDE.md file with project-specific information and configuring the relevant MCP servers for the project (see sections "CLAUDE.md" and "MCP").

Git Worktree for Parallel Work:

A particularly useful pattern is using Git worktrees to let Claude Code work on a separate branch while you continue developing on another branch in the IDE.

Recently, Claude Code has added native support for this via the --worktree (or -w) parameter:

Claude Code handles the entire management: the worktree is created under .claude/worktrees/<name>/, a branch worktree-<name> is automatically created, and cleanup happens upon exit – with changes, you'll be asked; without changes, the worktree is automatically removed.

The advantage over the manual approach (git worktree add + cd + claude) lies not only in the reduced effort but primarily in the integration with session management: worktree sessions appear in the session picker and can be resumed at any time:

In combination with --tmux, you can run multiple parallel Claude Code sessions in separate terminal tabs – e.g., a feature worktree and a bugfix worktree simultaneously.

Tip: Add .claude/worktrees/ to your .gitignore so the worktree contents don't appear as untracked files. Subagents can also work in their own worktrees automatically via isolation: worktree in their configuration.

Claude Code supports various ways to adapt code generation to your own requirements. The following sections describe the most important levers.

Claude Code distinguishes several configuration levels that are relevant when organizing skills, MCP servers, and settings:

Project Level (.claude/): Checked into the repository and thus available for the entire team. Project-specific skills, custom commands, and MCP configurations belong here.

User Level (~/.claude/): Global settings that apply across projects. Ideal for personal preferences and skills that should be used in all projects (e.g., dotnet-code-standards).

Sharing Between Projects: Skills and agents that you want to share between different projects on your own machine are best placed in ~/.claude/skills/. For sharing with colleagues or the community, packaging as a plugin is recommended (see section "Plugins").

Settings Files: Besides CLAUDE.md and Skills, Claude Code controls its behavior (e.g., hooks, allowed tools, MCP servers) via settings.json files at three levels:

Settings are merged in this order, with more specific levels overriding the more general ones.

CLAUDE.md is the "memory" of the coding LLM for the current project. Opus 4.6 does have a very large usable context window of 1M tokens, but after any moderately complex subtask, it's exhausted and must either be summarized (/compact) or cleared (/clear).

It's therefore essential to have the file updated after implementing each PRD. Otherwise, the coding LLM must perform a token-intensive (and cost-intensive) analysis of the source code state before implementing each PRD. Note: There is currently a study from ETH Zurich that considers the use of a CLAUDE.md as rather counterproductive, but this primarily refers to purely automatically created and overloaded files. This makes the following tip all the more important:

Tip: Instead of packing everything into a monolithic CLAUDE.md, it's recommended to split it with references to additional Markdown files. Claude Code follows file references automatically. This keeps the context overhead low while all relevant information remains available on demand. If a complex CLAUDE.md already exists, ask Claude to split it feature-based accordingly; the actual CLAUDE.md should only contain always-relevant information like tech stack and vertical functionalities.

Claude Code itself provides many configuration options and actions via "slash" commands like /init, /compact, /plugins, etc. (overview with /help). In addition to these predefined commands, it's possible to add your own "custom" commands to provide additional context to your prompt. We use, for example:

More information about the PRD workflow under section "Approach."

Note: In recent Claude Code versions, Anthropic has merged Custom Commands and Skills:

I still consider the conceptual separation between active execution (refining your own prompt via custom command) and providing additional "knowledge" or capabilities for specific areas via "skills" – which are automatically loaded by the agent as needed – to be meaningful, but that's of course up to each individual.

Skills extend Claude Code with knowledge and context about specific tools (e.g., databases, CMS), approach concepts (preferred system architecture, source code organization, file naming), preferred source code formatting, use of specific language features, etc. Each skill consists of YAML metadata (name, description) and detailed instructions in Markdown format within a file skills/skill-name/SKILL.md. Structure per documentation, e.g.:

For .NET development, we use the following (custom) skills:

Instead of writing skills manually or exclusively using prefabricated skills, skills can be very effectively extracted via Claude Code from an existing codebase with the desired feature. A prompt we practically use is:

The created skill should of course be reviewed and iteratively improved with follow-up prompts.

Prefer Skills Over Subagents – With Exceptions: Skills impose less context overhead than subagents and are sufficient for most specialized tasks. Only deploy subagents when you need autonomous execution across the entire codebase (e.g., security audits, SEO scans), a dedicated model for cost optimization, or a separate tool set. For a concrete comparison of when each approach shines, see section "Subagents → Skills vs. Subagents."

Keep an Overview: Don't clone skill repositories indiscriminately. Each skill extends the context that the coding LLM must process. Focus on skills that are actually needed regularly.

Security with Third-Party Skills: Only use skills from trusted sources. Explicitly check external skills for prompt injection: does the SKILL.md contain instructions that could cause the LLM to perform unwanted actions, e.g., sending data to external URLs or modifying system files? Pay particular attention to hidden instructions in code examples or "invisible" text.

Skill Validation: Use the skill validator to ensure conformity with the skill specification.

Create Skills from Existing Code: This is the most efficient approach. Claude Code analyzes existing implementations and automatically extracts patterns, conventions, and gotchas – significantly faster and more complete than manual documentation.

Meta-Skills: Skill documents can in turn reference other skills, so that, for example, a /finalize-feature skill could call both a code formatting skill and a /document-feature skill.

MCP servers enable the coding LLM to access external resources and software tools, e.g., version control (GitHub, GitLab), databases, documentation, and much more. Although nearly infinite possibilities exist, it's important to note that each MCP server provides access to numerous individual tools (e.g., reading/writing structure and data for a database) – sometimes 30 to 40 individual invocation options for the coding LLM. This can quickly overwhelm an LLM when it must choose between several hundred tools for a specific task. Therefore, select MCP servers judiciously so that a maximum of approximately 100 individual tools is not exceeded.

We use the following MCP servers for .NET development:

MCP servers can be installed in various ways:

Here are examples for installing/removing additional MCP servers in Claude Code:

Hooks are pre- and post-execution scripts that Claude Code automatically runs before or after certain tool invocations. For .NET developers, this is particularly relevant for automatically ensuring code quality. A typical example: automatically running dotnet format after every file change to a .cs file, so that the generated code immediately conforms to formatting specifications.

Hooks are defined in the Claude Code configuration (.claude/settings.json). Details on configuration in the official documentation.

Here's an example hook to automatically run dotnet format after each run:

Subagents are autonomously operating, specialized agents for specific tasks. Claude Code uses its own subagents for code analysis (via Haiku, as it's faster and more efficient) and planning tasks (/plan mode, e.g., via Opus). The advantage over skills: subagents can be assigned a dedicated model (Haiku, Sonnet, Opus – e.g., for cost optimization) and specific, selected tools (MCP servers) for the respective task.

However, coordination between subagents and the main agent must be considered. The main agent has no insight into the exact workflow within the subagent and only sees the final results. Two possible approaches:

Conceivable use cases for subagents in .NET projects would be, for example, frontend development focused on a specific UI framework like Tailwind CSS, SEO analysis and implementation, security auditing, code review, or code formatting and documentation. The accompanying repository contains examples:

From experience so far, most specialized tasks can be implemented more simply with skills, as the assignment of a specific model is rarely truly necessary. However, there are cases where the distinction matters – as the following section illustrates.

The question "skill or subagent?" comes up regularly and deserves a clear framework. The short version: skills provide knowledge, subagents perform work. A skill is a reference document that the main agent reads and applies inline – like a colleague handing you a checklist. A subagent is an autonomous worker that gets its own context window, executes a procedure independently, and returns structured results – like delegating a task to a specialist.

To make this concrete, let's look at OWASP security hardening for .NET, a domain where both approaches have clear roles:

The practical sweet spot is often both combined: the skill ensures that newly written code follows OWASP patterns from the start (reactive, inline), while the subagent performs periodic full-project sweeps to catch issues across the codebase that no single coding session would cover (proactive, autonomous). The subagent's instructions reference the skill for canonical pattern definitions, avoiding knowledge duplication.

Decision heuristic: If the knowledge needs to flow into code as it's being written – use a skill. If you need an autonomous scan, a dedicated tool set, or a structured report across the entire project – use a subagent. If both apply – use both, with the subagent referencing the skill.

Agent Teams is still a new feature and marked as "experimental" at the time of writing this article. Agents within an Agent Team differ from subagents in that they don't work in isolation but communicate with each other and with the main agent. This works via multiple separate Claude Code instances in separate terminal windows with separate context windows. They specifically address the weakness of subagents mentioned above: the lack of communication.

A good introduction (besides the official documentation) can be found here. We haven't tested this in production yet; the advantage is clearly the ability to realize extensive projects significantly faster. The disadvantage, however, is reported to be the relatively high token consumption (and thus costs) as well as the sometimes inadequate synchronization of agents.

Plugins are "packaged" bundles of skills, agents, hooks, and MCP servers for easy distribution. Packaging is done by providing them in a dedicated directory [my-plugin] with a subdirectory .claude-plugin containing metadata in the form of a JSON file plugin.json. The name [my-plugin] then also serves as a namespace for the contained skills etc., so that different plugins don't conflict in naming. Invocation e.g., /my-plugin:my-skill.

The advantage is easy distribution among colleagues, in marketplaces, etc. (via plugins or connectors in Claude Desktop settings or the /plugin slash command in Claude Code). Detailed description see here. Sharing skills, agents, etc. on one machine between different projects can also be done via configuration directory (see section "Configuration Levels").

Tip: Claude Code provides prefabricated plugins via /plugins. For C# developers, the csharp-lsp plugin (Language Server Protocol – an open protocol for communication between editors or, in this case, Claude Code and a language server, e.g., for IntelliSense) is particularly interesting. There are also many other interesting plugins that won't be discussed further here.

Claude Code is billed either via the Anthropic API or an Anthropic plan. Costs depend primarily on the chosen model and task complexity when using the API. Opus 4.6 delivers the best results for complex .NET tasks but is also the most expensive model. With plan usage, there's a specific included token volume, both per 5-hour window and per week.

For orientation:

For cost control (see article Manage Cost effectively at Anthropic):

Resume Sessions with /resume: After a /clear or when restarting Claude Code, the previous context is gone. With /resume, a past session can be resumed – including the entire conversation history. This is particularly useful when you want to continue working on a task the next day or accidentally closed the terminal.

Undo Last Action with /rewind: If Claude Code went in the wrong direction – e.g., chose an inappropriate solution approach or wrote code to the wrong file – you can undo the last action with /rewind and enter a new prompt. The keyboard shortcut ESC + ESC does the same thing, just faster. This is significantly more efficient than manually correcting the error or completely discarding the context with /clear.

Set Up the System Manually Initially: The basic structure of a new project should be consciously set up "by hand." This ensures that the structural specifications are correct and the coding LLM finds consistent patterns from the very first PRD that it can follow.

Use Directory.Build.props / Directory.Packages.props: Unified settings/package versions for all projects within a solution make life a bit easier for an LLM too.

Improve Iteratively: Skills, CLAUDE.md, and PRD templates are not static artifacts. If you notice that the coding LLM repeatedly makes certain errors or doesn't follow patterns, that's a signal to supplement the corresponding skill or CLAUDE.md. The investment pays off with every subsequent feature.

Language: Prefer English for code, comments, CLAUDE.md, and skills. The LLM training data is predominantly English, and the quality of output is measurably better.

Model Choice: Use Claude Opus 4.6 for coding tasks. The quality difference to Sonnet is noticeable for more complex .NET tasks. Sonnet or Haiku are well-suited for subagents with clearly bounded tasks.

More Skills: A curated collection of skills for various use cases can be found at skills.sh.

Besides Claude Code, additional AI tools have proven valuable in daily work that meaningfully complement the development workflow:

Image Generation with Gemini: Google's Gemini Nano Banana Pro (Pro is important) currently delivers the best results for generating images to be used in web projects – from hero images to illustrations to placeholder images for previews – particularly because of the correct and consistent text output in images.

UI Prototyping with Aura.build: For quick UI prototypes and landing pages, Aura.build has proven helpful. It generates functional web interfaces from text descriptions that can serve as a starting point for the actual implementation – in plain HTML format that can easily be converted into ASP.NET Razor templates.

Also good: Readdy.ai – but here the generation has been switched from HTML to React, which is powerful but also harder to use for .NET developers.