microsoft-development

Microsoft Development

Optimized for current Microsoft Graph, Entra ID, PowerShell 7.x, and Microsoft 365 integration workflows.

Use this skill when the answer should come from Microsoft documentation rather than memory or third-party summaries.

• Leverage native parallel subagent dispatch and 200k+ context windows where available.

Current MCP Reality

Microsoft's Learn Docs MCP server is publicly documented and currently exposes these core tools:

• microsoft_docs_search
• microsoft_docs_fetch
• microsoft_docs_extract_code_examples
• microsoft_docs_search_by_product

Microsoft's getting-started docs also describe installation through npx -y @microsoft/learn-docs-mcp.

Activation Conditions

Use symptom -> action triggers: when one matches, apply this skill and verify with the protocol below.

• Verifying Azure SDK usage, limits, or configuration
• Looking up .NET, Graph, Windows, or Microsoft 365 APIs
• Pulling official code examples before implementation
• Checking product-specific guidance for Azure, Power BI, or Power Platform

Recommended Workflow

1. Search first with microsoft_docs_search.
2. Narrow by product with microsoft_docs_search_by_product when results are broad.
3. Fetch the relevant page with microsoft_docs_fetch for details.
4. Extract code examples with microsoft_docs_extract_code_examples if the user needs working snippets.
5. Prefer official code and limits over recollection.

Query Patterns

• "Azure Container Apps scale rules"
• "BlobClient UploadAsync Azure.Storage.Blobs"
• product="power-bi" query="row level security dax"
• product="microsoft-graph" query="send mail application permissions"

Guardrails

• Use Microsoft Learn MCP for Microsoft-specific answers before browsing elsewhere.
• Treat package versions, quotas, and service capabilities as time-sensitive.
• If Learn MCP is unavailable in the current client, use the included scripts and references as local fallbacks, then browse official docs.

Cross-Client Portability

This skill is written to stay usable across GitHub Copilot, Claude Code, and Codex.

• GitHub Copilot: keep the folder in a Copilot-visible skill path or wrap the workflow in project instructions when folder discovery is unavailable.
• Claude Code: keep the folder in a local skills directory or a compatible plugin source.
• Codex: install or sync the folder into $CODEX_HOME/skills/microsoft-development and restart Codex after major changes.

MCP Availability And Fallback

Preferred MCP Server: Microsoft Learn Docs MCP

• Fallback prompt: "Use the Microsoft Development skill without MCP. Follow the documented local or manual fallback, show the selected tool surface, and report the verification evidence."
• Use Microsoft Learn in a browser and local SDK or CLI documentation when the docs MCP server is unavailable.
• Verify generated commands or samples with the native toolchain (dotnet, az, PowerShell, etc.) before shipping them.
• Do not claim an MCP operation was used when the active host does not expose it.

Anti-Patterns

• Changing infrastructure before inspecting the current state: Cloud drift and hidden dependencies make blind edits risky.
• Hardcoding credentials or environment assumptions: Rollouts stop being reproducible and secrets become harder to rotate.
• Skipping rollback, observability, or validation planning: You only notice the missing safeguards after the deployment is already live.

Verification Protocol

Before claiming "skill applied successfully":

1. Pass/fail: The Microsoft Development implementation names the target runtime, framework version, and affected files.
2. Pass/fail: Build, lint, test, or equivalent local validation is run for the changed surface.
3. Pass/fail: Edge cases for errors, dependency drift, and environment differences are addressed or explicitly out of scope.
4. Pressure-test scenario: Apply the workflow to a change that passes happy-path tests but fails one boundary condition.
5. Success metric: Zero untested success claims; every implementation claim maps to a command or artifact.

Before and After Example

# Before
az deployment group create `
  --resource-group app-rg `
  --template-file main.bicep

# After
$deploymentName = "api-$(Get-Date -Format yyyyMMddHHmmss)"
az deployment group create `
  --name $deploymentName `
  --resource-group app-rg `
  --template-file main.bicep `
  --parameters environment=prod `
  --what-if

Moves from an opaque deployment command to a traceable and reviewable workflow with named deployments, explicit parameters, and a preflight diff.

Common Pitfalls

• Treating vendor examples as drop-in production code: Official snippets usually prove an API, not your project’s retry, logging, or auth requirements.
• Skipping service-specific limits and permissions review: Azure and Microsoft 365 failures often come from quotas or scopes rather than syntax.
• Relying on memory instead of current docs: Microsoft SDK behavior and surface area change often enough that stale recall is risky.

References & Resources

Documentation

• Azure Services Quick Reference - Common Azure services, SDK packages, and decision points
• .NET Patterns - Practical .NET design and dependency-injection patterns
• Microsoft Learn MCP - Current tool names, install command, and query workflow

Scripts

• Azure Health Check - Validate Azure login and inspect common resource health in a resource group

Examples

• Azure Function API Example - Example serverless API workflow tied back to official Microsoft docs

Related Skills

• azure-integrations: Use it when the workflow also needs Azure deployment and infrastructure automation.
• powerbi-modeling: Use it when the workflow also needs Power BI semantic model design and DAX work.
• sql-development: Use it when the workflow also needs SQL query, schema, and performance tuning work.
• documentation-authoring: Use it when the workflow also needs drafting structured technical or product documents.