docs-impact-classifier

작성자: microsoft

이 스킬을 사용하여 풀 리퀘스트 diff의 문서화 영향을 분류하고, 세 가지 판정(no-change, in-place edit, structural change) 중 하나를 반환합니다.

npx skills add https://github.com/microsoft/apm --skill docs-impact-classifier

docs-impact-classifier

Single responsibility: given a PR diff and the .apm/docs-index.yml corpus map, emit ONE classification verdict.

This skill is the cost gate for the entire docs-sync system. ~70% of PRs should exit at verdict no_change with zero panel spawn.

Architecture

This is a 3-layer funnel inside a single skill invocation:

  • L0 deterministic path gate -- pure file-path matching, no LLM.
  • L1 symbol extraction + corpus grep -- pure text processing, no LLM.
  • L2 LLM classifier -- bounded ~8 KB context envelope, 1 call.

The skill returns the verdict from the earliest layer that can decide.

Step 1: L0 deterministic path gate (no LLM)

Read .apm/docs-index.yml to load no_impact_paths[] and user_surface_paths[]. Get the changed file list from the PR diff (gh pr diff --name-only).

if every changed file matches no_impact_paths AND none match user_surface_paths:
    return {verdict: "no_change", confidence: "high", source: "L0", scope_pages: []}

This handles:

  • Test-only PRs (tests/**)
  • CI workflow PRs (.github/workflows/**)
  • Doc-only PRs (docs/**) -- out of scope, docs-sync doesn't review docs PRs
  • Primitive-only PRs (.apm/**)
  • Script and meta PRs

Expected hit rate: ~70% of PRs short-circuit here.

Step 2: L1 symbol extraction + corpus grep (no LLM)

If L0 did not exit, extract user-observable symbols from the diff:

  • CLI command names -- grep diff for ^@click.command, ^@cli.command, or any apm <verb> mention in added/removed lines.
  • Flag names -- grep diff for ^@click.option, --[a-z-]+ patterns.
  • Public API symbols -- added/removed def <name> in src/apm_cli/__init__.py or src/apm_cli/api/**.
  • Schema keys -- added/removed keys in apm.yml, apm.lock.yaml, apm-policy.yml parsers.
  • Error strings -- added/removed string literals in user-facing error paths (look for _rich_error, click.echo, raise ... Error().

For each extracted symbol, consult .apm/docs-index.yml#symbol_index to find the documented pages. Collect all hits into candidate_pages[].

Also grep -rn <symbol> docs/src/content/docs/ for symbols NOT in the index (catches drift between index and corpus).

Step 3: L2 LLM verdict (1 call, bounded context)

If L1 found zero candidate pages AND zero schema/CLI/flag changes: return {verdict: "no_change", confidence: "medium", source: "L1", scope_pages: []}.

Otherwise, invoke the doc-analyser persona with EXACTLY this context envelope (must fit in ~8 KB tokens):

  • PR title + body (first 500 chars)
  • Diff stats (gh pr diff --stat output)
  • .apm/docs-index.yml (the whole file; it's ~8 KB seeded, may grow)
  • L1 candidate pages with +/-5 lines of context per hit
  • Path-classification summary from L0
  • pr_doc_diff_paths[]: the list of paths under docs/src/content/docs/** that the PR itself already modifies (drives the in_place_resolved downgrade rule in "In-place-resolved detection" below).

Ask doc-analyser to return JSON matching this schema:

{
  "verdict": "no_change" | "in_place_resolved" | "in_place" | "structural",
  "confidence": "low" | "medium" | "high",
  "scope_pages": ["docs/src/content/docs/..."],
  "structural_proposal": {
    "new_pages": [{"slug": "...", "rationale": "..."}],
    "moved_pages": [{"from": "...", "to": "..."}],
    "toc_changes": "<one-paragraph>"
  },
  "reasoning": "<one-paragraph: what surface changed, what docs are affected, why this verdict>"
}

structural_proposal is populated only when verdict is structural. scope_pages is populated for in_place and structural verdicts.

Verdict semantics

VerdictMeaningPanel sizeCost
no_changeNo user-observable surface changed0 panel spawns~0-1 LLM call
in_place_resolvedDoc impact existed, but the PR's OWN diff already patches every page in scope_pages -- author already did the work0 panel spawns; skill emits NO advisory~1 LLM call
in_placeOne to a few pages need a paragraph or section update; no new pages, no TOC changeN candidate pages x (doc-writer + python-architect) + editorial-owner + growth-hacker + CDO~6-12 LLM calls
structuralA new page is needed, OR an existing page should be split/merged, OR the TOC needs to change to fit a new conceptarchitect first (TOC delta), then in-place panel for affected pages~10-15 LLM calls

In-place-resolved detection (false-alarm killer)

BEFORE returning in_place, intersect your scope_pages[] with the list of files the PR itself touches under docs/** (provided to you by the orchestrator under pr_doc_diff_paths[]). If EVERY scope page already appears in pr_doc_diff_paths, downgrade to in_place_resolved and emit reasoning of the form "Author already patched ". This is the well-behaved-author path; the skill stays silent.

If only SOME scope pages are pre-patched, keep in_place and list the REMAINING (unpatched) pages in scope_pages[]. Note the pre-patched ones in reasoning for transparency.

Rename / breaking-change heuristic (PR 1244 class)

When the L1 layer reports an ADDED public symbol that matches an EXISTING public symbol's name in the corpus (e.g. PR adds apm update but apm update already appears in 9 docs pages with different semantics), this is a RENAME or BREAKING SEMANTIC CHANGE. Bias toward structural (not in_place):

  • the existing page describing the OLD semantics may need to SPLIT into two pages (old verb under new name + new verb keeping old name)
  • the TOC may need a NEW reference page for the renamed verb
  • every passing mention in the corpus needs verification

Do NOT collapse a rename into in_place just because the affected pages already exist. The shape of the work is structural even when no new page is strictly required.

Anti-patterns (verdict shape errors)

  • Returning in_place with empty scope_pages -- invalid; orchestrator will reject.
  • Returning structural without structural_proposal -- invalid.
  • Returning in_place when EVERY scope page is in pr_doc_diff_paths -- should be in_place_resolved.
  • Inflating structural to seem thorough -- the CDO will catch this. Return the minimal true verdict.
  • Missing the rename heuristic above and emitting in_place for a verb-swap PR.
  • Reading the corpus (the .md files themselves) at L2 -- context budget breach. You read the index, not the corpus.

Output contract

Return a SINGLE JSON document matching the schema in Step 3 as the final message of your task. No prose around the JSON. The orchestrator parses your last message.

microsoft의 다른 스킬

oss-growth
microsoft
OSS 성장 해커 페르소나
agent-framework-azure-ai-py
microsoft
Microsoft Agent Framework Python SDK(agent-framework-azure-ai)를 사용하여 Azure AI Foundry 에이전트를 구축합니다. AzureAIAgentsProvider로 지속적 에이전트를 만들 때, 호스팅 도구(코드 인터프리터, 파일 검색, 웹 검색)를 사용할 때, MCP 서버를 통합할 때, 대화 스레드를 관리할 때, 또는 스트리밍 응답을 구현할 때 사용합니다. 함수 도구, 구조화된 출력, 다중 도구 에이전트를 다룹니다.
development
airunway-aks-setup
microsoft
AKS에서 AI Runway 설정 — 빈 클러스터에서 실행 중인 모델까지. 클러스터 검증, 컨트롤러 설치, GPU 평가, 공급자 설정, 첫 배포를 다룹니다. 시기: "AI Runway 설정", "AKS 클러스터 온보딩", "AI Runway 설치", "airunway 설정", "AKS에 모델 배포", "AKS에서 GPU 추론", "AKS에서 KAITO 설정", "AKS에서 LLM 실행", "AKS에서 vLLM", "AKS에서 모델 서빙 설정", "AI Runway 컨트롤러".
devops
appinsights-instrumentation
microsoft
Azure Application Insights로 웹앱을 계측하기 위한 지침입니다. 원격 분석 패턴, SDK 설정, 구성 참조를 제공합니다. WHEN: 앱 계측 방법, App Insights SDK, 원격 분석 패턴, App Insights란 무엇인가, Application Insights 지침, 계측 예시, APM 모범 사례.
devops
applicationinsights-web-ts
microsoft
브라우저/웹 앱을 Application Insights JavaScript SDK(@microsoft/applicationinsights-web)로 계측합니다. Real User Monitoring(RUM) — 페이지 뷰, 클릭, AJAX/fetch 종속성, 예외, 사용자 지정 이벤트, 백엔드 OpenTelemetry 트레이스와 상관관계가 있는 브라우저 측 GenAI 에이전트 트레이스에 사용합니다. SDK Loader Script 및 npm 설정, 프레임워크 확장(React, React Native, Angular), Click Analytics, 텔레메트리 이니셜라이저, 브라우저에서 생성된 에이전트/도구/모델 스팬에 대한 OTel GenAI 의미론적 규칙을 다룹니다.
devops
azure-ai-anomalydetector-java
microsoft
Azure AI Anomaly Detector SDK for Java로 이상 탐지 애플리케이션을 구축하세요. 단변량/다변량 이상 탐지, 시계열 분석 또는 AI 기반 모니터링을 구현할 때 사용하세요.
development
azure-ai-language-conversations-py
microsoft
azure-ai-language-conversations Python SDK를 사용하여 대화형 언어 이해(CLU)를 구현합니다. ConversationAnalysisClient로 대화 의도와 엔터티를 분석하거나, NLP 기능을 구축하거나, 애플리케이션에 언어 이해를 통합할 때 사용합니다.
development
azure-ai-ml-py
microsoft
Azure Machine Learning SDK v2 for Python. ML 작업 영역, 작업, 모델, 데이터 세트, 컴퓨팅 및 파이프라인에 사용합니다. 트리거: "azure-ai-ml", "MLClient", "workspace", "model registry", "training jobs", "datasets".
development