Vigilante issue implementation on dotnet

Vigilante .NET Issue Implementation

Focus

• Read the prompt for detected tech stacks, process hints, and .NET security guidance before changing code.
• Follow the repository's existing .NET workflow, solution or project structure, analyzer configuration, and formatting conventions.
• Keep changes scoped to the issue and do not broaden into unrelated cleanup or package churn.

.NET Tooling Workflow

• Formatting: use the repository's established formatting path. When dotnet format is the standard SDK workflow, run it on the affected project or solution scope before committing.
• Testing: run targeted dotnet test for the affected test project, project, or solution first, then broaden only when the change crosses project boundaries or the repository workflow requires it.
• Analyzers: respect built-in .NET analyzers, nullable warnings, .editorconfig, Directory.Build.props, and repo-defined warning severities. Do not weaken analyzer settings without a narrow, documented reason.
• Package auditing: when dependency changes are involved or package risk is relevant, use the repository's standard NuGet restore or audit flow and review advisories when auditing is enabled.
• Dependencies: prefer framework or standard-library features when they cover the need. Avoid unrelated package version churn.

.NET Coding Style

• Follow existing project patterns for namespaces, file layout, and test structure.
• Preserve nullable reference type correctness and prefer explicit null handling over suppression.
• Prefer straightforward error handling and clear APIs over reflection-heavy or overly abstracted changes unless the issue requires it.
• Keep public API changes minimal and aligned with the issue.

Security

• Do not commit secrets, tokens, certificates, or environment-specific credentials.
• Prefer configuration binding, options patterns, environment variables, or local user-secrets workflows over hard-coded settings.
• In ASP.NET Core code, preserve secure defaults for authentication, authorization, antiforgery or CSRF protections where applicable, HTTPS, and sensitive-data handling.
• Respect security analyzers and dependency advisories when the repository enables them.

Mixed-Language Repositories

• A .NET repository may also include frontend or other non-.NET code in the same checkout.
• Scope .NET validation (dotnet test, dotnet format, analyzers, restore or audit flows) to affected .NET projects or solutions only.
• When the issue also touches another stack, validate that side with its own native tooling rather than assuming dotnet covers the whole repository.
• Do not assume a .NET repository is C#-only; use the prompt's detected tech stacks and process hints.

Workflow

• Follow the base vigilante-issue-implementation workflow for issue comments, validation, push, and PR creation, including stacked base-branch detection (Base branch: directive in the issue body).
• Use vigilante commit for all commit-producing operations. Do not use git commit or GitHub CLI commit flows directly.
• Any commit or amend must preserve the user's existing git author, committer, and signing configuration. Commit on behalf of the user and do not overwrite git config with a coding-agent identity.
• Do not add Co-authored by: trailers or any other agent attribution for Codex, Claude, Gemini, or similar coding-agent identities.
• Repository-specific instructions (AGENTS.md, README.md, CI config, solution-level build props) remain authoritative when they are more specific than the generic .NET guidance in this skill.