Create or update a feature spec under docs/Features/ with business rules, user flows, system behaviour, verification, and Definition of Done. Use when the user asks for a feature spec, executable requirements, acceptance criteria, behaviour documentation, or a pre-implementation plan for non-trivial behaviour changes.
Plan a human review for a large AI-generated code drop by reading the target area, tracing the natural user and system flows, identifying the riskiest boundaries, and prioritizing the files a human should inspect first. Use when the codebase is too large to review line-by-line and you need a practical review sequence…
Apply ML/AI project delivery guidance for data exploration, feasibility, experimentation, testing, responsible AI, and operating ML systems. Use when the repo includes model training, inference, data science workflows, or ML-specific delivery planning.
Capture or refine non-functional requirements such as accessibility, reliability, scalability, maintainability, performance, and compliance. Use when a feature or architecture change needs explicit quality attributes and trade-offs.
Design or improve observability for application and delivery flows: logs, metrics, traces, correlation, alerts, and operational diagnostics. Use when a change affects runtime visibility, failure diagnosis, SLOs, or alerting.
Apply baseline engineering security guidance: secrets handling, secure defaults, threat modelling references, and review checkpoints for auth, data flow, pipelines, and external integrations. Use when a change has security impact but does not require a full standalone AppSec engagement.
Calculates CRAP (Change Risk Anti-Patterns) score for .NET methods, classes, or files. Use when the user asks to assess test quality, identify risky untested code, compute CRAP scores, or evaluate whether complex methods have sufficient test coverage. Requires code coverage data (Cobertura XML) and cyclomatic…
Use the open-source free cloc tool for line-count, language-mix, and diff statistics in .NET repositories. Use when a repo needs C# and solution footprint metrics, branch-to-branch LOC comparison, or repeatable code-size reporting in local workflows and CI.
Use the free built-in .NET SDK analyzers and analysis levels with gradual Roslyn warning promotion. Use when a .NET repo needs first-party code analysis, EnableNETAnalyzers, AnalysisLevel, or warning-as-error policy wired into build and CI.
Use the open-source free coverlet toolchain for .NET code coverage. Use when a repo needs line and branch coverage, collector versus MSBuild driver selection, or CI-safe coverage commands.
Use the open-source free CSharpier formatter for C# and XML. Use when a .NET repo intentionally wants one opinionated formatter instead of a highly configurable dotnet format-driven style model.
Use the free first-party dotnet format CLI for .NET formatting and analyzer fixes. Use when a .NET repo needs formatting commands, --verify-no-changes CI checks, or .editorconfig-driven code style enforcement.
Primary router skill for broad .NET work. Classify the repo by app model and cross-cutting concern first, then switch to the narrowest matching .NET skill instead of staying at a generic layer.
Create or update an ADR under docs/ADR/ for architectural decisions, dependency changes, data-model changes, or cross-cutting policy shifts. Use when the user asks to write, update, or document an ADR, record a design decision, capture architecture trade-offs, or justify a repo-wide technical policy.
Shape delivery workflow around backlog quality, roles, ceremonies, and engineering feedback. Use when defining how the team plans, tracks work, and turns feedback into durable improvements.
Create or update docs/Architecture/Overview.md as the global architecture map for a solution. Use when bootstrapping a repo, onboarding, or changing modules, boundaries, or contracts. Keep it navigational and use references/overview-template.md for scaffolding.
Design or refine CI/CD workflows, quality gates, release flow, and safe AI-assisted pipeline authoring. Use when adding or changing build pipelines, release stages, IaC-driven environments, or deployment rollback policy.
Prepare for, perform, or tighten code review workflow: PR scope, review checklist, reviewer expectations, and merge hygiene. Use when shaping pull requests, defining review policy, or auditing whether a change is review-ready.
Improve developer experience for multi-component solutions: onboarding, F5 contract, cross-platform tasks, local inner loop, and reproducible setup. Use when the repo is hard to run, debug, test, or onboard into.
Create or refine durable engineering documentation: docs structure, navigation, source-of-truth placement, and writing quality. Use when a repo’s docs are missing, stale, duplicated, or hard to navigate, or when adding new durable engineering guidance.
Use a repo-root .editorconfig to configure free .NET analyzer and style rules. Use when a .NET repo needs rule severity, code-style options, section layout, or analyzer ownership made explicit. Nested .editorconfig files are allowed when they serve a clear subtree-specific purpose.
Use the open-source free ArchUnitNET library for architecture rules in .NET tests. Use when a repo needs richer architecture assertions than lightweight fluent rule libraries usually provide.
Use the open-source free cloc tool for line-count, language-mix, and diff statistics in .NET repositories. Use when a repo needs C# and solution footprint metrics, branch-to-branch LOC comparison, or repeatable code-size reporting in local workflows and CI.
Use the free built-in .NET SDK analyzers and analysis levels. Use when a .NET repo needs first-party code analysis, EnableNETAnalyzers, AnalysisLevel, or warning policy wired into build and CI.