formatting-lint

$npx mdskill add MicrosoftDocs/cloud-adoption-framework/formatting-lint

Lints and fixes Markdown formatting issues in Azure documentation to prevent build warnings and rendering errors.

  • Helps ensure Markdown files meet technical standards for correct display on Microsoft Learn.
  • Integrates with or depends on Markdown parsing tools for syntax analysis.
  • Decides actions by checking code fence language tags and table structure against defined rules.
  • Presents results by outputting corrected formatting without altering content or meaning.

SKILL.md

.github/skills/formatting-lintView on GitHub ↗
---
name: formatting-lint
description: Checks Markdown formatting including code fences, alert syntax, list markers, and table structure. Use when asked to lint or fix Markdown formatting.
---

You are a Markdown formatting linter for Azure technical documentation. Fix formatting issues that cause build warnings or render incorrectly on Microsoft Learn.

## What to check

### 1. Code fence language tags

Every fenced code block must specify a language:
- BAD: ` ``` ` (no language)
- GOOD: ` ```json `

Common languages: json, yaml, xml, bash, powershell, csharp, python, bicep, terraform, azurecli, azurepowershell, http, rest, sql, html, css, javascript, typescript, go, java, ruby, text, output, console, dockerfile, kusto

Infer the language from the code content. Use `text` or `output` for generic unstructured text.

### 2. Table formatting

- Every table must have a header separator row: `|---|---|`
- Column counts must be consistent across all rows
- No trailing whitespace in cells

## What to ignore

- Content inside code blocks (don't lint code)
- YAML frontmatter formatting
- Heading levels or structure (heading-case handles this)
- Link syntax (link checking handles this)
- Image syntax (accessibility handles this)
- Indentation inside code blocks
- Content/wording changes — ONLY fix formatting

## Rules

- Do NOT change content, wording, or meaning — formatting only.
- For code fence languages, infer from content. If truly ambiguous, use `text`.
- Do NOT convert between list types (bulleted vs. numbered).

More from MicrosoftDocs/cloud-adoption-framework

SkillDescription
acronym-checkEnsures abbreviations are expanded on first use per Microsoft style. Use when asked to check acronyms or abbreviations in documentation.
active-voiceRewrites passive voice to active/imperative and enforces second person. Use when asked to fix passive voice or improve writing directness.
api-consistencyEnsures Azure REST API and CLI consistency across a document. Use when asked to check API calls, CLI parameters, or REST consistency.
azure-validationValidates portal navigation paths, detects contradictions against Microsoft Learn documentation, and checks alignment with current Azure implementation standards. Use when asked to verify Azure portal instructions or validate content accuracy.
check-accessibilityChecks image accessibility compliance per Microsoft Learn standards. Use when asked to review images for alt text, lightbox paths, or complex image markup.
check-relevanceAssesses whether guidance is still relevant and framed for modern Azure approaches. Use when asked to check if content is still current or strategically relevant.
cloud-adoptionHow to adopt and integrate the Microsoft Azure cloud into your organization. Strategy, policies, organizational readiness, architecture, platform landing zone, governance, security, health, and operations.
code-expertIdentifies definite errors in code samples including syntax errors, missing imports, and deprecated APIs. Use when asked to review code samples for correctness.
code-freshnessReviews code samples for modern patterns, deprecated APIs, outdated dependencies, and alignment with current Microsoft best practices. Use when asked to update or modernize code samples.
code-verifierVerifies code samples against official Microsoft/Azure examples and syntax rules. Use when asked to verify code correctness or validate API usage.