If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/Azure/azure-sdk-for-net shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across the board

• Last commit today
• 29+ active contributors
• Distributed ownership (top contributor 40% of recent commits)
• MIT licensed
• CI configured
• Tests present

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live Azure/azure-sdk-for-net repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/Azure/azure-sdk-for-net.

What it runs against: a local clone of Azure/azure-sdk-for-net — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in Azure/azure-sdk-for-net | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 30 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of Azure/azure-sdk-for-net. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/Azure/azure-sdk-for-net.git
#   cd azure-sdk-for-net
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of Azure/azure-sdk-for-net and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "Azure/azure-sdk-for-net(\\.git)?\\b" \\
  && ok "origin remote is Azure/azure-sdk-for-net" \\
  || miss "origin remote is not Azure/azure-sdk-for-net (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f ".github/CODEOWNERS" \\
  && ok ".github/CODEOWNERS" \\
  || miss "missing critical file: .github/CODEOWNERS"
test -f ".github/PULL_REQUEST_TEMPLATE.md" \\
  && ok ".github/PULL_REQUEST_TEMPLATE.md" \\
  || miss "missing critical file: .github/PULL_REQUEST_TEMPLATE.md"
test -f ".config/dotnet-tools.json" \\
  && ok ".config/dotnet-tools.json" \\
  || miss "missing critical file: .config/dotnet-tools.json"
test -f ".editorconfig" \\
  && ok ".editorconfig" \\
  || miss "missing critical file: .editorconfig"
test -f ".github/copilot-instructions.md" \\
  && ok ".github/copilot-instructions.md" \\
  || miss "missing critical file: .github/copilot-instructions.md"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 30 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~0d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/Azure/azure-sdk-for-net"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Azure SDK for .NET is the official client library suite for accessing Azure cloud services from .NET applications. It provides standardized, service-specific packages (e.g., Azure.Storage.Blobs, Azure.Identity) that handle authentication, retries, logging, and HTTP transport according to Azure SDK Design Guidelines, enabling .NET developers to interact with Azure resources like storage, databases, and compute without managing low-level service details. Monorepo organized by Azure service: /sdk/{service-category}/{service-name}/ contains client libraries (e.g., sdk/storage/Azure.Storage.Blobs, sdk/identity/Azure.Identity). Core infrastructure lives in /sdk/core/Azure.Core (shared authentication, retry, logging, HTTP transport). Each service package is independently versioned NuGet package. .github/skills/ contains AI agent definitions for automated PR analysis and code generation workflows.

.NET developers (C# primarily) building applications that consume Azure cloud services. This includes both application developers integrating Azure capabilities into their apps and Microsoft engineers maintaining the official SDK packages. Contributors span service teams at Microsoft adding new service clients and community members reporting issues or submitting fixes.

Highly mature, production-ready repository. The SDK is officially published and recommended for production use via NuGet, with extensive Azure service coverage organized in /sdk subdirectories. Strong CI/CD infrastructure (Guardian baseline configs, 1espt pipeline automation) and active development indicated by the structured .github skills and agent workflows. This is a core Microsoft offering, not experimental.

Low operational risk for consumers (GA packages are stable), but moderate maintenance burden for contributors: the monorepo structure spans 421MB of C# across dozens of service clients with complex interdependencies (see 'Architecture' for dependency patterns). The presence of .gdnbaselines and Guardian security configs suggests strict compliance requirements. Breaking changes can affect the entire .NET ecosystem depending on Azure.Core version updates.

Active development with AI/agentic workflow integration: .github/skills/ shows recent work on automated APIView feedback resolution, CI failure analysis, and local SDK generation. The repository uses GitHub agents and event processors (.github/event-processor.config) for automation. TypeSpec and Bicep language support (132KB + 172KB in file counts) indicates adoption of code-generation-first service definition patterns alongside traditional OpenAPI specs.

git clone https://github.com/Azure/azure-sdk-for-net.git
cd azure-sdk-for-net
dotnet build
# Or target a specific service:
cd sdk/storage/Azure.Storage.Blobs
dotnet build

Use dotnet CLI (implicit from C# dominance and .config/dotnet-tools.json). See individual service /sdk/{service}/README.md files for service-specific setup.

Daily commands: Per-service: dotnet build sdk/{service}/Azure.{Service}.{Resource} then dotnet test in that directory. Monorepo-wide build: likely dotnet build at root (standard MSBuild behavior for .sln files, inferred from repo scale). See .devcontainer/devcontainer.json for VS Code dev container setup, which auto-installs tools.

• .github/CODEOWNERS — Defines code ownership and required reviewers for different parts of the SDK—essential for understanding who maintains each service area.
• .github/PULL_REQUEST_TEMPLATE.md — Documents the pull request submission process and expected contribution quality standards for all contributors.
• .config/dotnet-tools.json — Specifies the shared .NET tooling versions and dependencies required for local development and CI/CD.
• .editorconfig — Enforces consistent code style and formatting rules across all C# files in the repository.
• .github/copilot-instructions.md — Provides AI-assisted development guidelines and context for automating common SDK development tasks.
• .devcontainer/devcontainer.json — Defines the standardized development environment container, ensuring all contributors work in the same configuration.
• .github/event-processor.config — Configures GitHub event processing and automation workflows for CI/CD and issue/PR triage.

Add a New Azure Service SDK

1. Create a new service folder under /sdk/[servicename]/ with the standard project structure ((implied /sdk/ directory structure))
2. Add a README.md in the service folder documenting authentication, usage examples, and getting started ((implied /sdk/[servicename]/README.md))
3. Update .github/CODEOWNERS to assign service maintainers and required reviewers (.github/CODEOWNERS)
4. Create or update SDK generation config in tspconfig.yaml following the azsdk-common-generate-sdk-locally skill reference (.github/skills/azsdk-common-generate-sdk-locally/references/customization-workflow.md)
5. Add security baseline exemptions if needed via Guardian configuration (.config/guardian/.gdnbaselines)

Configure a New Release or Publish Workflow

1. Define release plan metadata following the azsdk-common-prepare-release-plan skill pattern (.github/skills/azsdk-common-prepare-release-plan/references/release-plan-details.md)
2. Create release automation task in the sdk-release skill if custom release logic is needed (.github/skills/azsdk-common-sdk-release/tasks/release-basic-001.yaml)
3. Configure CI/CD triggers and event routing in the central event processor (.github/event-processor.config)
4. Document release process in copilot instructions for consistency (.github/copilot-instructions.md)

Establish Code Quality Standards for a Service

1. Define C# code style rules in the shared editor config (.editorconfig)
2. Set up service-specific code owner groups with required review counts (.github/CODEOWNERS)
3. Configure Guardian security scanning baselines for the service area (.config/guardian/.gdnbaselines)
4. Add custom analyzer and validation tasks in the generate-sdk-locally skill (.github/skills/azsdk-common-generate-sdk-locally/tasks/analyzer-errors.yaml)

Automate API Review and Feedback Resolution

1. Configure APIView integration in the apiview-feedback-resolution skill (.github/skills/azsdk-common-apiview-feedback-resolution/SKILL.md)
2. Define feedback resolution patterns and automation triggers (.github/skills/azsdk-common-apiview-feedback-resolution/references/feedback-resolution-steps.md)
3. Add custom triggers and evaluations for service-specific review concerns (.github/skills/azsdk-common-apiview-feedback-resolution/evals/eval.yaml)
4. Link GitHub hooks to route APIView comments automatically (.github/hooks/hooks.json)

• .NET & C# — Primary SDK implementation language for Azure services, targeting cross-platform .NET Core/Framework compatibility.
• GitHub Actions — Native CI/CD automation integrated with repository workflows, pull request validation, and automated releases.
• Guardian & 1ES Pipeline — Enterprise-grade security scanning and compliance baseline enforcement for production SDK releases.
• APIView — Dedicated API review and feedback tool for ensuring consistent, safe API surface design across all SDKs.
• TypeSpec / TSP — SDK code generation from service specifications ensures consistency and reduces manual boilerplate.

• Monorepo structure (all services under /sdk/)

  • Why: Centralizes governance, shared tooling, and cross-service standards; enables coordinated releases and reuse of common utilities.
  • Consequence: Higher coordination overhead, slower per-service iteration cycles, but stronger consistency and security auditing.

• Skill-based automation (agentic workflows) for release and generation

  • Why: Reduces manual error, standardizes complex multi-step processes, allows AI-assisted task execution.
  • Consequence: Requires upfront skill definition and maintenance; may limit edge-case flexibility and increase learning curve for new tasks.

• Mandatory code review via CODEOWNERS

  • Why: Ensures expert oversight, knowledge sharing, and adherence to service-level SLAs.
  • Consequence: Potential bottleneck on contributor throughput; requires maintaining current CODEOWNERS file as services evolve.

• Centralized Guardian security baseline

  • Why: Applies consistent security scanning rules across all SDKs; tracks and exempts known issues systematically.
  • Consequence: May block contributions temporarily if baseline is stale; requires periodic synchronization with threat landscape.

• Does not generate SDKs for non-Azure services or third-party APIs.
• Does not serve as a package management system; publishes to NuGet only.
• Does not provide runtime API execution or service hosting—only client SDKs.
• Does not manage cloud infrastructure provisioning; integration tests assume pre-existing Azure resources.
• Not a real-time system; release cycles follow scheduled batches, not continuous deployment.

1. Service-specific dependencies: Some clients (e.g., Storage, CosmosDB) require Azure resource credentials at runtime; tests use Azure DevOps managed identities, not local secrets. 2. Guardian baseline locks: Security scanning is strict; new dependencies and code patterns must pass .gdnbaselines checks in .config/guardian/, or PRs are blocked. 3. TypeSpec adoption variance: Older services use OpenAPI YAML; newer ones use TypeSpec (/sdk/{service}/api.tsp). Code-gen outputs differ; know which pattern your service uses. 4. Monorepo build gotchas: .NET projects inherit Directory.Build.props settings repo-wide; unexpected version conflicts can arise. Run dotnet nuget locals all --clear if NuGet cache causes issues. 5. 1espt pipeline requirements: The repo uses internal Microsoft 1espt CI; local dotnet build may pass, but pipeline may fail on compliance or signing checks.

• Azure.Core shared library pattern — Every service client in this repo depends on Azure.Core for retry policies, authentication, and HTTP transport; understanding the shared abstractions (RetryPolicy, HttpPipeline, TokenCredential) is essential to implementing new service clients correctly
• TypeSpec code generation — Newer Azure services in this monorepo use TypeSpec (a Microsoft DSL) to define APIs and auto-generate client code; understanding TypeSpec is critical for contributing to services adopting this pattern (Azure.Data.Tables, Azure.Messaging.EventHubs, etc.)
• Credential chain / TokenCredential abstraction — All Azure SDK clients use an extensible credential pattern (DefaultAzureCredential chains environment variables, managed identity, interactive login) defined in Azure.Identity; understanding this pattern is essential for authentication in SDK consumers
• Exponential backoff retry strategy — Azure.Core provides RetryPolicy with jittered exponential backoff; SDK clients inherit this automatic retry behavior, and contributors must understand retry semantics to avoid infinite loops or excessive delays
• Monorepo versioning & release coordination — This large monorepo coordinates independent service client versions while maintaining a single Azure.Core version; understanding semantic versioning constraints and breaking change policies across the repo prevents accidental API breakage
• Guardian security baseline scanning — All PRs are scanned against baseline configs in .config/guardian/; contributors must understand compliant patterns for credentials, dependencies, and code to avoid CI blocks
• APIView versioning and APIView-driven design review — Public API changes in this SDK go through APIView (a Microsoft tool) for human review before release; understanding how API surfaces are evaluated prevents design feedback loops late in development

• Azure/azure-sdk-for-java — Parallel official Azure SDK implementation in Java; shares design guidelines, patterns, and service coverage scope
• Azure/azure-sdk-for-python — Parallel official Azure SDK implementation in Python; identical service lineup and shared TypeSpec/code-gen infrastructure
• Azure/azure-rest-api-specs — Canonical OpenAPI/TypeSpec definitions for all Azure services; consumed by SDK code-gen pipelines to produce client libraries
• dotnet/runtime — Upstream .NET runtime; Azure SDK depends on stable .NET 6+ features; runtime issues impact SDK stability
• Azure/azure-sdk-tools — Shared tooling for SDK generation, validation, and release (APIView, TypeSpec compiler, etc.); consumed by this repo's CI

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Implement comprehensive skill evaluation tests for GitHub Copilot agentic workflows

The repo contains multiple AI skill definitions in .github/skills/ with eval.yaml and fixtures, but many skill directories lack complete trigger and edge-case task definitions. The azsdk-common-apiview-feedback-resolution and azsdk-common-generate-sdk-locally skills have partial eval.yaml structures. Contributing comprehensive test cases and trigger validation tasks would improve reliability of automated workflows that assist contributors.

• [ ] Review .github/skills/azsdk-common-apiview-feedback-resolution/evals/tasks/ and .github/skills/azsdk-common-generate-sdk-locally/evals/tasks/
• [ ] Expand trigger_tests.yaml with additional negative test cases (e.g., malformed API review comments, invalid TypeSpec configurations)
• [ ] Add fixture files for edge cases (e.g., .github/skills/azsdk-common-generate-sdk-locally/fixtures/invalid-tspconfig.yaml)
• [ ] Document expected behavior for each skill in corresponding SKILL.md files with concrete examples

Add CI workflow validation for .config/1espt/PipelineAutobaseliningConfig.yml configuration

The repository uses 1ES Pipeline Templates for CI/CD (evidenced by .config/1espt/PipelineAutobaseliningConfig.yml), but there's no visible validation workflow to catch misconfigurations early. A GitHub Action that validates the YAML schema and checks for common misconfiguration patterns would prevent CI pipeline failures.

• [ ] Create .github/workflows/validate-1espt-config.yml that runs on changes to .config/1espt/
• [ ] Implement YAML schema validation using a linter (e.g., yamllint configured in .github/)
• [ ] Add checks for required pipeline fields specific to Azure SDK builds (e.g., required pool definitions, template references)
• [ ] Document validation rules in a new .github/1espt-config-guide.md file

Create integration tests for devcontainer setup and toolchain verification

The .devcontainer/devcontainer.json exists but there's no automated validation that the devcontainer configuration produces a working development environment. New contributors often struggle with environment setup. Adding a CI workflow that spins up the devcontainer and runs basic build/test commands would catch configuration drift.

• [ ] Create .github/workflows/validate-devcontainer.yml using GitHub's devcontainer CLI
• [ ] Add test commands that verify: dotnet SDK version matches .config/dotnet-tools.json, build succeeds for at least one SDK package, and unit tests run successfully
• [ ] Document devcontainer troubleshooting steps in a new DEVCONTAINER_SETUP.md at repo root
• [ ] Include checks for tool availability specified in .devcontainer/devcontainer.json (e.g., required extensions, formatters)

• Add missing XML documentation comments to public APIs in a service package (e.g., sdk/{service}/src/*.cs). Many public types lack ///<summary> tags required by analyzer rules. Start with a single service (e.g., Azure.Storage.Blobs.BlobClient) to learn the doc pattern, then submit a batch fix.
• Write integration tests for error scenarios in a small service client (e.g., Azure.Data.Tables). Current test coverage focuses on happy paths; add tests for auth failures, rate-limit retries, and malformed responses to increase robustness.
• Update stale CHANGELOG.md or README.md files in /sdk/{service}/ directories with recent feature additions or deprecated APIs. Many service folders have outdated version notes that confuse consumers.

The Azure SDK for .NET repository demonstrates generally good security practices with proper disclosure policies (SECURITY.md) and infrastructure for security scanning. However, several areas require attention: (1) Agentic workflow and GitHub Skills configurations need auditing for exposed sensitive data, (2) No dependency manifest was provided for vulnerability analysis of NuGet packages, (3) Internal configuration files (.copilot-instructions.md, .event-processor.config) should be reviewed for credential exposure, (4) Guardian baseline exceptions should be regularly reviewed. The repository follows Microsoft security standards with clear vulnerability reporting procedures and appears to use 1ES Pipeline Templates for secure CI/CD. Recommend implementing automated SAST/dependency scanning and conducting a comprehensive audit of GitHub automation configurations.

• Medium · Agentic Workflows Configuration Exposure — .github/agents/, .github/aw/. The repository contains agentic workflow configurations (.github/agents/agentic-workflows.agent.md and .github/aw/actions-lock.json) that may contain sensitive automation rules, API endpoints, or workflow definitions that could be exploited if misconfigured. Fix: Review agentic workflow configurations to ensure no sensitive endpoints, API keys, or internal automation logic is exposed. Consider restricting access to these files and implementing least-privilege access controls.
• Medium · GitHub Skills and Evaluation Fixtures — .github/skills/*/fixtures/, .github/skills/*/evals/. The .github/skills directory contains evaluation fixtures (.github/skills/*/fixtures/) and test configurations that may inadvertently expose test data, API credentials, or sensitive configuration examples used in CI/CD workflows. Fix: Audit all fixture files and evaluation configurations to ensure no real credentials, API keys, or sensitive test data are included. Use placeholder values and document expected formats instead.
• Low · Missing Package Dependency Manifest — Project root (*.csproj, packages.config, Directory.Packages.props). No package dependency file content was provided for analysis. This prevents comprehensive dependency vulnerability assessment of the .NET SDK project. Fix: Provide package manifest files for dependency scanning. Implement automated dependency scanning using tools like Snyk, WhiteSource, or GitHub's Dependabot to identify outdated and vulnerable NuGet packages.
• Low · Copilot Instructions Exposed — .github/copilot-instructions.md. The .github/copilot-instructions.md file may contain internal development guidelines, automation rules, or workflow patterns that could be used to understand internal processes. Fix: Review the copilot instructions file to ensure it doesn't contain sensitive internal procedures, API endpoints, or security-related automation details. Consider restricting visibility to trusted contributors only.
• Low · Event Processor Configuration — .github/event-processor.config. The .github/event-processor.config file may contain webhook configurations, event routing rules, or API endpoints that should be treated as sensitive. Fix: Ensure the event processor configuration does not contain hardcoded credentials, API keys, or internal endpoint URLs. Use GitHub Secrets for sensitive values and validate all webhook configurations.
• Low · Guardian Baseline Files — .config/guardian/.gdnbaselines. Guardian baseline files (.config/guardian/.gdnbaselines) may contain exceptions to security scanning rules that could mask vulnerabilities if not properly maintained. Fix: Regularly review guardian baselines to ensure exceptions are justified and not masking real vulnerabilities. Implement a process to periodically reassess and minimize baseline exceptions.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.