weloom/ss-md-dotnet-engineering

Assess and improve code clarity during implementation, review, or cleanup when intent, names, responsibilities, effects, dependencies, or failure paths are unclear. Use for explicit Clean Code requests or a concrete readability concern. Supplies quality criteria and routes diagnosed decisions to specialist guidance; not a mandatory gateway or a reason for unrelated cleanup.

Clean up comments in requested code: clarify, correct, or remove redundant, obsolete, inaccurate, or change-history comments. Use only when the user explicitly asks to review or clean comments.

Choose and implement domain-grounded solutions when adding features to an existing business domain or changing business rules, concepts, invariants, ownership, or interactions between models. Also use for explicit DDD design or domain-readability reviews. Do not activate for formatting, purely technical changes, or straightforward CRUD without meaningful domain decisions.

Guide .NET architectural changes, especially when adding or moving classes, types, projects, modules, dependencies, services, or persistence boundaries. Use the relevant architecture guidance before proposing structural changes; do not impose layers on simple CRUD.

Apply functional and declarative C# guidance for explicit requests, preservation of established pure calculations, non-mutating inputs, immutable results or separated effects, or diagnosed problems with hidden inputs, mutable intermediate state, composition, or outcome propagation. Can be selected from Clean Code, DDD, refactoring, architecture, or performance findings. A lambda, record, or LINQ expression alone is not a trigger; do not rewrite by default.

Normalize whitespace, blank lines, or formatting in explicitly requested files. Use when the user asks to clean up empty lines, spaces, indentation, or formatting; follow the bundled syntax guide and surrounding code, and avoid unrelated churn.

Design, diagnose, and improve .NET code for speed, latency, throughput, CPU, memory budgets, or workload capacity. Use for explicit performance thresholds, profiling or optimization requests, resource exhaustion, hangs, contention, concurrency or parallelism risks, and overload-related stability or availability. Not for every async call or collection; general failover and disaster recovery need broader reliability analysis.

Diagnose and improve existing code structure while preserving behavior. Use for refactoring, restructuring, extraction, inlining, simplification, duplication, or code smells, and when a feature or bug fix needs structural improvement to avoid a workaround. Examine the surrounding responsibility rather than assume the smallest diff is best. Do not activate for every edit or unrelated cleanup.