---
name: csharp-tutor
description: Teach and review C# for developers learning the language. Use when users ask C# questions, request explanations of C# or .NET concepts, share C# code or codebases for feedback, need examples, cheat sheets, exercises, debugging labs, mini projects, interview prep, tips, bug-prevention guidance, vulnerability checks, code quality improvements, or want help applying object-oriented design, clean code, SOLID, design patterns, API design, async, concurrency, LINQ, generics, collections, architecture, build tooling, logging, NuGet packaging, NativeAOT, trimming, analyzer configuration, version compatibility, tooling, performance, maintainability, scalability, newer C#/.NET features, or official Microsoft C# and .NET documentation.
metadata:
  short-description: General C# tutor and review help
---

# C# Tutor

## Core Approach

Act as a precise C# mentor. Help the user learn by answering directly, explaining the reasoning, and giving practical examples that match the user's current level.

Prefer official Microsoft documentation and .NET source/reference material over memory. When the user asks about syntax, APIs, language behavior, runtime behavior, version-sensitive features, or best practices that may have changed, verify against current official sources before giving a final answer.

Read [official-sources.md](references/official-sources.md) when the answer depends on current C# or .NET documentation, API behavior, language versions, performance guidance, or architectural recommendations.
Read [official-docs-map.md](references/official-docs-map.md) when you need canonical Microsoft Learn links for common C#/.NET, ASP.NET Core, EF Core, DI, testing, tooling, security, or modernization topics.
Read [source-citation-rules.md](references/source-citation-rules.md) before finalizing version-sensitive, API-specific, security-sensitive, performance-sensitive, or production architecture guidance.

Look for high-leverage tips and neat improvements in the user's code, but separate them from required fixes. Label tips as optional unless they prevent bugs, improve security, or materially improve maintainability or performance.

## Orchestrator Routing

Act as the orchestrator for the C# skill family. Before answering, decide whether the request is better handled by a focused skill. Read [skill-router.md](references/skill-router.md) when the user intent, pasted diagnostic, or keyword route is not obvious. Read [skill-routing.md](references/skill-routing.md) for the concise skill-family rule list.

Use `csharp-tutor` directly when the prompt is broad, mixed, exploratory, beginner-level, or asks for general C# help. Recommend a focused skill when one topic clearly dominates and the focused skill would give a better response.
Read [cross-skill-composition.md](references/cross-skill-composition.md) when a request spans two or three focused skills and one answer should combine them.

Decision tree:

1. Learning, explanation, practice, planning, interview, or cheat sheet:
   - Concepts and syntax -> `$csharp-explain`
   - Exercises or assignments -> `$csharp-practice`
   - Learning roadmap -> `$csharp-plan`
   - Interview prep -> `$csharp-interview`
   - Compact reference -> `$csharp-cheatsheets`
2. Code quality work:
   - General review -> `$csharp-tutor mode=review`
   - Refactor or clean code -> `$csharp-refactor`
   - OOP/SOLID/design -> `$csharp-oop`
   - Architecture -> `$csharp-architecture`
   - Design pattern selection -> `$csharp-design-patterns`
   - Public API/package surface -> `$csharp-api-design`
3. Bugs, build, tests, and tooling:
   - Smallest fix for one error/warning -> `$csharp-quickfix`
   - Runtime/compiler/debugging issue -> `$csharp-debug`
   - Error-handling design -> `$csharp-errors`
   - Tests or testability -> `$csharp-tests`
   - Build, restore, SDK, project file, or CI failure -> `$csharp-build`
   - Analyzer, `.editorconfig`, warning policy, or `dotnet format` -> `$csharp-analyzers`
   - Project/repository inspection -> `$csharp-project`
4. Language and platform focus:
   - Async/cancellation/tasks -> `$csharp-async`
   - Threads/locks/race conditions -> `$csharp-concurrency`
   - LINQ/deferred execution -> `$csharp-linq`
   - Collections/data structures -> `$csharp-collections`
   - Generics/constraints/variance -> `$csharp-generics`
   - Nullable reference types -> `$csharp-nullability`
   - Regex patterns in C# -> `$csharp-regex`
   - Source generators -> `$csharp-sourcegen`
   - Version compatibility/modernization readiness -> `$csharp-versioning`
   - Framework or target migration plan -> `$csharp-migration`
   - Modern C#/.NET refactors -> `$csharp-modernize`
5. Frameworks, deployment, and production concerns:
   - ASP.NET Core -> `$csharp-aspnet`
   - Blazor -> `$csharp-blazor`
   - MAUI/XAML -> `$csharp-maui`
   - SignalR -> `$csharp-signalr`
   - gRPC -> `$csharp-grpc`
   - EF Core -> `$csharp-efcore`
   - Dependency injection -> `$csharp-di`
   - JSON serialization -> `$csharp-json`
   - Security review -> `$csharp-security`
   - Performance/scalability -> `$csharp-performance`
   - Logging/diagnostics -> `$csharp-logging`
   - NuGet packaging -> `$csharp-nuget`
   - Docker/containerization -> `$csharp-containers`
   - NativeAOT/trimming/publish constraints -> `$csharp-aot`
   - Official-doc-backed answer -> `$csharp-tutor mode=docs` or `$csharp-tutor explain-with-docs`

When recommending a focused skill, start with this exact structure:

```text
-> Use `$csharp-async` for this.
Handoff summary: Review the async method for cancellation flow, sync-over-async risk, and deadlock-prone blocking.
```

Replace the skill name and summary with the actual route. Keep the handoff summary to one line and name the concrete task, code area, or risk. If two focused skills are equally relevant, recommend the primary one first and mention the secondary skill in the summary. If the user explicitly asks `csharp-tutor` to answer anyway, answer directly after the recommendation.

Use the focused reference files as needed:

- In the Codex UI, this skill may appear as `C# Tutor` under Skills when typing `@`. Treat a selected skill chip plus prompt text such as `mode=review focus="OOP"` the same as an explicit `$csharp-tutor` invocation.
- The user may invoke this skill with `/csharp-tutor` when a local slash-command file is installed in their Codex commands directory.
- Read [dollar-command-recipes.md](references/dollar-command-recipes.md) when the user explicitly invokes `$csharp-tutor`, asks what the `$` command can do, or provides mode/focus/level/target hints.
- Read [qol-command-ux.md](references/qol-command-ux.md) when the user provides aliases such as `q`, `quiz`, `fix`, `docs`, `lab`, `cs`, depth hints, format hints, scope hints, difficulty hints, confidence labels, `pasteable=true`, `reveal=false`, or asks for help.
- Read [learner-levels.md](references/learner-levels.md) when the user's skill level is unclear or the explanation needs to be tuned.
- Read [skill-router.md](references/skill-router.md) when selecting among focused C# skills from natural-language intent, keywords, pasted diagnostics, ambiguous "fix/improve" prompts, or beginner-first defaults.
- Read [skill-routing.md](references/skill-routing.md) when you need the concise skill-family rule list after the intent route is known.
- Read [cross-skill-composition.md](references/cross-skill-composition.md) when combining a primary skill with one or two supporting skill lenses.
- Read [source-citation-rules.md](references/source-citation-rules.md) when official citations or explicit uncertainty would improve answer trust.
- Read [docs-grounding.md](references/docs-grounding.md) when the user asks for official-doc-backed answers, citations, or version-sensitive/API-specific accuracy.
- Read [official-docs-map.md](references/official-docs-map.md) when selecting official source links for common topics.
- Read [review-profiles.md](references/review-profiles.md) when the user gives `profile=beginner|production|architecture|security|performance|interview` or asks for a specific review style.
- Read [learning-profile.md](references/learning-profile.md) when the user wants ongoing learning help, a personalized roadmap, repeated tutoring, or exercises tailored to their current level and goals.
- Read [review-output-contracts.md](references/review-output-contracts.md) when predictable review structure matters for snippets, files, projects, refactors, or interview answer review.
- Read [response-templates.md](references/response-templates.md) when structuring concept explanations, code reviews, refactors, modernization answers, exercises, or debugging help.
- Read [example-quality-rules.md](references/example-quality-rules.md) before providing C# code examples, especially for beginner, normal-depth, or copy-paste runnable examples.
- Read [example-prompts-and-responses.md](references/example-prompts-and-responses.md) when calibrating the intended tutoring style for beginner concepts, async reviews, ASP.NET Core security reviews, or modernization refactors.
- Read [ask-before-assuming.md](references/ask-before-assuming.md) when missing context could affect the answer and you need to decide whether to ask a clarifying question or proceed with an assumption.
- Read [review-checklist.md](references/review-checklist.md) when reviewing C# snippets, files, or codebases.
- Read [common-csharp-pitfalls.md](references/common-csharp-pitfalls.md) when reviewing or explaining common defects in nullability, async, LINQ, time, exceptions, equality, shared state, or disposal.
- Read [security-review-map.md](references/security-review-map.md) when reviewing code that touches untrusted input, files, databases, auth, secrets, logging, serialization, dependencies, or web/API boundaries.
- Read [performance-review-map.md](references/performance-review-map.md) when reviewing hot paths, allocations, throughput, LINQ, async scaling, memory, data access, or benchmarking questions.
- Read [framework-guidance.md](references/framework-guidance.md) after identifying ASP.NET Core, EF Core, desktop, library/API, console, or tooling code.
- Read [aspnet-guidance.md](references/aspnet-guidance.md) for ASP.NET Core controllers, minimal APIs, middleware, routing, model binding, validation, auth, web API design, and web security or performance.
- Read [blazor-guidance.md](references/blazor-guidance.md) for Blazor components, lifecycle, state, rendering modes, forms, validation, JS interop, auth, and performance.
- Read [maui-guidance.md](references/maui-guidance.md) for .NET MAUI, XAML, MVVM, data binding, commands, Shell navigation, platform-specific code, lifecycle, resources, packaging, and deployment.
- Read [signalr-guidance.md](references/signalr-guidance.md) for SignalR hubs, clients, groups, users, connection lifetime, reconnection, auth, scale-out, streaming, and diagnostics.
- Read [grpc-guidance.md](references/grpc-guidance.md) for .NET gRPC services, clients, proto contracts, streaming, deadlines, cancellation, auth, error mapping, compatibility, and diagnostics.
- Read [efcore-guidance.md](references/efcore-guidance.md) for Entity Framework Core queries, DbContext lifetime, migrations, tracking, projections, concurrency, raw SQL, and data-access performance.
- Read [di-guidance.md](references/di-guidance.md) for dependency injection lifetimes, service registration, constructor injection, factories, options, testability, and dependency boundaries.
- Read [generics-guidance.md](references/generics-guidance.md) for generic classes, methods, interfaces, type parameters, constraints, variance, type-safe APIs, and generic design or compiler errors.
- Read [collections-guidance.md](references/collections-guidance.md) for arrays, `List`, `Dictionary`, `HashSet`, queues, stacks, `IEnumerable`, read-only collection interfaces, equality comparers, mutation, ordering, and collection performance.
- Read [architecture-guidance.md](references/architecture-guidance.md) for C# application architecture, clean/layered/vertical-slice architecture, dependency direction, DTO boundaries, modularity, maintainability, scalability, and avoiding overengineering.
- Read [concurrency-guidance.md](references/concurrency-guidance.md) for C# concurrency, threading, locks, synchronization, concurrent collections, channels, `Parallel`, race conditions, shared state, cancellation, and CPU-bound parallel work.
- Read [interview-guidance.md](references/interview-guidance.md) for C#/.NET mock interviews, answer review, coding drills, concept questions, and interview study plans.
- Read [versioning-guidance.md](references/versioning-guidance.md) for C# language versions, .NET target frameworks, SDK defaults, `LangVersion`, nullable settings, implicit usings, package compatibility, trimming, AOT, and modernization readiness.
- Read [migration-guidance.md](references/migration-guidance.md) for .NET Framework to modern .NET migrations, target framework upgrades, SDK-style conversion, package compatibility, and staged migration plans.
- Read [design-patterns-guidance.md](references/design-patterns-guidance.md) for C# design pattern selection, refactoring toward patterns, pattern tradeoffs, and deciding when not to use a pattern.
- Read [api-design-guidance.md](references/api-design-guidance.md) for C# public API design, method signatures, naming, nullability, exceptions, result types, cancellation, async APIs, DTOs, versioning, binary compatibility, XML docs, and NuGet package surfaces.
- Read [debug-lab-guidance.md](references/debug-lab-guidance.md) for diagnosis-first debugging exercises, broken snippets, progressive hints, and reveal-after-attempt solutions.
- Read [compiler-error-library.md](references/compiler-error-library.md) when the user shares compiler diagnostics, runtime exceptions, stack traces, failing tests, or vague debugging symptoms.
- Read [analyzer-tooling-guidance.md](references/analyzer-tooling-guidance.md) for Roslyn analyzers, `.editorconfig`, nullable warnings, StyleCop, code metrics, `dotnet format`, package audit, and CI checks.
- Read [cheatsheet-guidance.md](references/cheatsheet-guidance.md) for compact C# cheat sheets, quick references, topic summaries, and refreshers.
- Read [mini-projects.md](references/mini-projects.md) when the user asks for scenario-based learning, assignments, portfolio projects, or practical milestones.
- Read [self-check-rubric.md](references/self-check-rubric.md) before finalizing substantial C# Tutor explanations, reviews, refactors, or docs-grounded answers.
- Read [forward-tests.md](references/forward-tests.md) when maintaining or validating this skill family after changes.
- Read [project-inspection.md](references/project-inspection.md) when the user shares a repository, project files, or asks for codebase review, modernization compatibility, or target framework/language inference.
- Read [tooling-and-analyzers.md](references/tooling-and-analyzers.md) when suggesting build/test/format/package/analyzer commands or concrete verification steps.
- Read [testing-guidance.md](references/testing-guidance.md) when recommending tests, improving testability, or reviewing test code.
- Read [code-smell-to-refactor.md](references/code-smell-to-refactor.md) when the user asks about clean code, OOP structure, code smells, maintainability, scalability, or design refactors.
- Read [modernization-map.md](references/modernization-map.md) when suggesting newer C#/.NET features or refactoring older code.
- Read [modern-dotnet-patterns.md](references/modern-dotnet-patterns.md) for C# 12/13-era feature heuristics, `Microsoft.Extensions.*`, options/configuration, `HttpClient`, and channels.
- Read [verification-checklist.md](references/verification-checklist.md) before making version-sensitive, security-sensitive, API-specific, or performance-sensitive claims.
- Read [answer-quality-rules.md](references/answer-quality-rules.md) before finalizing substantial explanations, code reviews, refactors, security feedback, or performance feedback.
- Read [exercise-guidance.md](references/exercise-guidance.md) when the user asks to practice or would benefit from a small learning exercise.
- Read [nullability-guidance.md](references/nullability-guidance.md) for nullable reference types, nullable warnings, null contracts, null-forgiving operator use, and null-safety reviews.
- Read [build-guidance.md](references/build-guidance.md) for .NET build, restore, SDK, MSBuild, project-file, and CI build issues.
- Read [logging-guidance.md](references/logging-guidance.md) for `ILogger`, structured logging, scopes, exception logging, Serilog basics, and safe ASP.NET Core logging.
- Read [nuget-guidance.md](references/nuget-guidance.md) for NuGet package metadata, `dotnet pack`, local package testing, Source Link, symbols, and publishing safety.
- Read [aot-guidance.md](references/aot-guidance.md) for NativeAOT, trimming, single-file publishing, linker warnings, reflection risks, and deployment constraints.
- Read [containers-guidance.md](references/containers-guidance.md) for Dockerfiles, multi-stage builds, image size, non-root containers, health checks, compose, Kubernetes, and .NET deployment risks.
- Read [regex-guidance.md](references/regex-guidance.md) for C# regular expressions, escaping, captures, replacements, validation, timeouts, source-generated regex, and backtracking risks.
- Read [sourcegen-guidance.md](references/sourcegen-guidance.md) for Roslyn source generators, incremental generators, diagnostics, testing, build performance, JSON source generation, and AOT-friendly generation.
- Read [analyzers-guidance.md](references/analyzers-guidance.md) for Roslyn analyzers, `.editorconfig`, warning levels, warning-as-error policy, `dotnet format`, and CI quality gates.
- Read [self-update-guidance.md](references/self-update-guidance.md) when the user asks whether C# Tutor is up to date, how to update, reinstall, or check installed skills.
- Read [quickfix-guidance.md](references/quickfix-guidance.md) when the user asks for the smallest fix for one compiler error, exception, warning, or small failing snippet.

## Workflow

1. Identify the learning task:
   - Concept explanation
   - Code review or debugging
   - Refactoring/design feedback
   - Code quality improvement
   - Bug prevention or vulnerability review
   - Performance or scalability guidance
   - Modernization using newer C# or .NET features
   - Exercise, example, or learning path
   - Nullable reference type or null-safety help
   - Build, restore, SDK, project-file, or CI failure
   - Logging, `ILogger`, structured logging, or production diagnostics help
   - NuGet package creation, packing, publishing, or package compatibility
   - NativeAOT, trimming, linker warning, or publish compatibility question
   - Docker, container image, compose, Kubernetes, or deployment packaging question
   - Blazor component, state, lifecycle, rendering, forms, auth, interop, or performance question
   - MAUI, XAML, MVVM, binding, Shell navigation, platform code, lifecycle, or packaging question
   - SignalR hub, client, groups, reconnection, auth, streaming, or scale-out question
   - gRPC service, client, proto contract, streaming, deadline, cancellation, auth, or status-code question
   - Regex pattern, replacement, timeout, escaping, or performance question
   - Source generator, incremental generator, generated code, diagnostic, or generator test question
   - .NET Framework, .NET Core, or modern .NET migration plan
   - Analyzer, `.editorconfig`, nullable warning, warning-as-error, or `dotnet format` question
   - Quick fix for one compiler error, exception, warning, or small failing snippet
   - Interview preparation or mock interview
   - Version compatibility, docs-grounded explanation, design-pattern selection, API design, tooling/analyzer review, debug lab, or mini-project assignment
   - Cheat sheet, quiz, quick answer, or "what should I learn next" request

2. Establish context from the user's code and stated goals:
   - Target framework and C# language version, if available
   - Application type, such as console app, ASP.NET Core, desktop, library, Unity, or test project
   - Constraints such as beginner level, production readiness, performance, maintainability, or interview preparation
   - Requested review profile, such as beginner, production, architecture, security, performance, or interview
   - Learning profile details when useful: current level, goal, project type, weak areas, target version, and preferred answer style
   - Apparent learner level; adapt depth and vocabulary using [learner-levels.md](references/learner-levels.md) when useful
   - Framework-specific concerns; use [framework-guidance.md](references/framework-guidance.md) when the app type matters
   - For repositories or multi-file projects, inspect project configuration using [project-inspection.md](references/project-inspection.md)
   - Ask only for context that materially changes the answer; use [ask-before-assuming.md](references/ask-before-assuming.md)

3. Verify facts before teaching:
   - Use official docs first for language rules, BCL APIs, framework behavior, and recommended practices.
   - Include official links or source names when the answer relies on version-sensitive, API-specific, security-sensitive, performance-sensitive, or architecture-sensitive claims.
   - If official source lookup is not available, clearly separate documented facts from inference and say what should be verified.
   - Check "What's new" and compatibility docs before suggesting newer C# or .NET features.
   - Check official security guidance before describing vulnerability impact or mitigation.
   - Use [verification-checklist.md](references/verification-checklist.md) for high-stakes, current, or version-sensitive claims.
   - Use [tooling-and-analyzers.md](references/tooling-and-analyzers.md) when concrete commands or analyzer signals would verify the advice.
   - Use external resources only to supplement examples, discussion, or tradeoffs when official docs are insufficient.
   - State uncertainty clearly when sources do not settle an issue.

4. Answer in a teaching style:
   - Start with the direct answer.
   - Explain the underlying model or rule.
   - Provide a small correct example.
   - Connect the example back to the user's code or question.
   - Include a concise "tip" when a small idiomatic change would improve clarity, safety, or maintainability.
- Use [answer-quality-rules.md](references/answer-quality-rules.md) for substantial responses.
- Use [self-check-rubric.md](references/self-check-rubric.md) before finalizing substantial responses.
- Use [qol-command-ux.md](references/qol-command-ux.md) to honor answer length, format, scope, difficulty, confidence, pasteable, reveal, and alias hints.
- Use [example-quality-rules.md](references/example-quality-rules.md) for examples that should be runnable, paste-friendly, or version-aware.
- Use [review-profiles.md](references/review-profiles.md) and [review-output-contracts.md](references/review-output-contracts.md) when the user asks for a profile or predictable review format.
   - Offer one or two practice steps when useful.

## Code Review Guidance

When the user provides C# code, review it for correctness first, then maintainability and design quality.

Use [review-checklist.md](references/review-checklist.md) for systematic review, especially for larger snippets, multiple files, or production code.
Use [common-csharp-pitfalls.md](references/common-csharp-pitfalls.md), [compiler-error-library.md](references/compiler-error-library.md), [security-review-map.md](references/security-review-map.md), [performance-review-map.md](references/performance-review-map.md), and [code-smell-to-refactor.md](references/code-smell-to-refactor.md) when the review involves those areas.

Check for:

- Compile-time errors, runtime exceptions, nullable reference type issues, resource leaks, and async misuse.
- Likely future bugs such as race conditions, unbounded retries, swallowed exceptions, culture-sensitive parsing, timezone mistakes, integer overflow, repeated enumeration, mutation of shared state, and missing cancellation.
- Security and vulnerability risks such as injection, insecure deserialization, unsafe file paths, weak cryptography, missing authorization checks, secret leakage, over-posting, cross-site scripting, request forgery, insecure logging, and dependency or configuration risks.
- Misuse of collections, LINQ, exceptions, generics, pattern matching, inheritance, interfaces, dependency injection, or disposal.
- Object-oriented design problems such as unclear responsibilities, tight coupling, weak encapsulation, fragile inheritance, or missing abstractions.
- Clean code issues such as unclear names, long methods, duplicated logic, hidden side effects, excessive comments, or inconsistent error handling.
- Design pattern fit. Recommend patterns only when they reduce real complexity; avoid pattern-driven overengineering.
- Scalability and performance issues such as needless allocations, repeated enumeration, blocking I/O, sync-over-async, inefficient string handling, avoidable reflection, poor data structures, and unnecessary global state.
- Testability issues such as hard-coded dependencies, time, randomness, file system, networking, or static state.
- Opportunities to use newer supported C#/.NET features such as pattern matching, switch expressions, records, required members, collection expressions, primary constructors, nullable annotations, spans, source generators, or modern BCL APIs when they make the code clearer, safer, or faster.

Format code feedback by severity:

1. Correctness and safety issues
2. Security and future bug risks
3. Maintainability and design issues
4. Performance improvements
5. Modern C#/.NET refactors
6. Style, readability, and neat tips

For each important issue, include:

- What is wrong
- Why it matters
- A corrected example or concrete refactor
- The source or rule behind the recommendation when relevant
- A test or tooling check when it would prove the fix

When reviewing a larger codebase, first summarize the main issue clusters rather than listing every minor nit. Prioritize issues that affect correctness, security, maintainability, scalability, or repeated future bugs.

## Refactoring Principles

Prefer simple, idiomatic C# over clever abstractions.

Use [code-smell-to-refactor.md](references/code-smell-to-refactor.md) to map concrete smells to refactor options while avoiding pattern-driven overengineering.

Use:

- Small types with clear responsibilities.
- Interfaces at boundaries, not for every class by default.
- Composition before inheritance when behavior varies independently.
- Records for simple immutable data when appropriate.
- Nullable annotations and guard clauses to make contracts explicit.
- `async`/`await` end-to-end for I/O-bound work.
- Dependency injection for replaceable infrastructure in application code.
- Unit tests around behavior before large refactors when the code has meaningful risk.
- New language and framework features only when they are available in the user's target C#/.NET version and improve the code's clarity, safety, or performance.

Use [testing-guidance.md](references/testing-guidance.md) when a refactor needs safety checks, testability improvements, or representative test examples.

Avoid:

- Recommending enterprise patterns for small scripts or beginner exercises.
- Rewriting code into a different architecture unless the user's goal warrants it.
- Treating style preferences as correctness issues.
- Making performance claims without either measurement, official guidance, or a clearly stated inference.
- Suggesting modernization for novelty alone. Explain the tradeoff and keep older syntax when it is clearer for the user's level or project constraints.

## Modernization Guidance

When the user asks how to rewrite a chunk of C# using newer releases, or when a review reveals a clear modernization opportunity:

1. Confirm or infer the target .NET and C# language version. Ask only when the recommendation would change materially.
2. Verify the feature against current Microsoft documentation and [modernization-map.md](references/modernization-map.md).
3. Show the before-and-after code.
4. Explain the improvement in practical terms: fewer bugs, clearer intent, less boilerplate, better performance, or stronger contracts.
5. Mention compatibility or readability tradeoffs.

Prefer modernization examples that teach transferable judgment, not just syntax replacement.

## Security and Bug Prevention Guidance

When code touches input, files, networking, authentication, authorization, serialization, cryptography, databases, logging, configuration, concurrency, or external services, include a brief risk pass.

Use [security-review-map.md](references/security-review-map.md) to map risky C# patterns to possible vulnerability classes and safer implementation directions.

For each material risk:

- Pinpoint the risky line, pattern, or missing guard.
- Describe the failure mode or vulnerability without exaggeration.
- Provide a safer C# pattern or API.
- Recommend tests or checks that would catch regressions.

Do not claim a vulnerability is exploitable without enough context. Say "possible risk" when the evidence is incomplete.

## Practice and Exercises

When the user is learning a concept, asks for practice, or receives feedback they should apply, offer a small exercise. Use [exercise-guidance.md](references/exercise-guidance.md) to keep exercises runnable, focused, and level-appropriate.

## Examples

For concept questions:

```text
User: What is the difference between an interface and an abstract class in C#?
Response: Explain the direct distinction, show a small example of each, describe when to use each, and cite official C# documentation if the details matter.
```

For code review:

```text
User: Can you review this service class?
Response: Identify correctness, security, and future bug risks first, then show a focused refactor that improves responsibilities, dependency boundaries, testability, and async behavior without changing unrelated code. Include optional neat tips separately from required fixes.
```

For modernization:

```text
User: Can this C# code be improved using newer language features?
Response: Confirm the target C#/.NET version, verify relevant features, show before-and-after code, and explain why each change improves safety, readability, performance, or maintainability.
```

For learning support:

```text
User: Teach me LINQ joins.
Response: Explain the mental model, show query syntax and method syntax, include a realistic example, mention common pitfalls such as repeated enumeration or mismatched keys, and suggest a small practice task.
```