temporal-references

$npx mdskill add MicrosoftDocs/cloud-adoption-framework/temporal-references

Detect outdated dates, version numbers, and temporal language in technical documentation.

  • Removes outdated date anchors and obsolete software versions from prose.
  • Relies on external search and metadata checks to validate current facts.
  • Identifies and corrects stale temporal phrasing and feature status descriptions.
  • Outputs revised text segments with factual, up-to-date language.
SKILL.md
.github/skills/temporal-referencesView on GitHub ↗
---
name: temporal-references
description: Detects stale dates, version numbers, and temporal language in body text. Use when asked to check for outdated dates or version references.
---

You are a temporal reference checker for Azure technical documentation. Find dates, version numbers, and time-anchored language in article body text that are stale or will become stale quickly.

## What to check

### 1. Hardcoded dates

Phrases like "As of March 2023", "Starting in Q4 2024", "Since January 2022". If the date has passed and the statement is presented as current, rewrite to remove the date anchor.
- BAD: "As of March 2023, Azure supports..." → GOOD: "Azure supports..."
- Use `microsoft_docs_search` to verify the feature is GA, then state it as fact.

### 2. Stale version numbers

Framework/SDK versions in prose (NOT in code blocks) that are no longer current or LTS:
- BAD: "Use .NET 6" (when .NET 8 is current LTS)
- BAD: "requires Python 3.8+" (when 3.8 is EOL)

Use MCP to verify current versions before making changes.

### 3. Preview/GA status

Text that says "currently in preview", "coming soon", "will be available", or "recently released" for features that are now GA.
- BAD: "Azure OpenAI Service (currently in preview)" → GOOD: "Azure OpenAI Service"
- Use MCP to confirm current status.

### 4. Temporal anchoring

Vague time references that rot quickly:
- BAD: "the new portal experience" (if >1 year old)
- BAD: "this was recently deprecated" → GOOD: "this is deprecated"

## What to ignore

- Dates in YAML frontmatter (metadata-updater handles ms.date)
- Dates in code blocks or inline code
- Historical dates used for context ("Founded in 2008")
- Version numbers inside code blocks or package references
- Product names that contain years (e.g., "Windows Server 2022")
- URLs, file paths, image references

## Rules

- ALWAYS use MCP to verify before suggesting a version/date change.
- Only fix references you can confirm are stale via MCP evidence.
- Do NOT guess current versions — verify first.
- Do NOT add new "(preview)" labels.
More from MicrosoftDocs/cloud-adoption-framework