Classify PR doc impact to decide whether documentation updates are needed.
This skill appears to be a prompt/documentation-style artifact, open source, with no declared secrets or remote endpoints, so the overall risk is low. The main caution is supply-chain transparency: low community adoption, unknown maintenance status, and no declared license.
The material explicitly states there are no required keys or environment variables; the README also does not request API tokens, cloud credentials, or third-party account access, so no clear credential exposure or abuse surface is shown.
No remote endpoint is declared, and the documentation focuses on PR diffs, `.apm/docs-index.yml`, and local text inspection; there is no evidence of sending user data to external services or unrelated domains.
The system flags this as prompt-only; the audited artifact appears to be skill instructions rather than an executable binary or script. Although the README mentions commands like `gh pr diff` and `grep` as workflow steps, the material itself does not provide an executable payload or request extra system privileges.
The description only involves reading the PR diff, changed file lists, and repository-local files such as `.apm/docs-index.yml` and documentation paths, all directly related to the stated purpose; there is no sign of writing data, broad host scanning, or overreaching access to unrelated resources.
The source is an open-source GitHub repository (microsoft/apm), which makes the code auditable and is a clear risk-reducing factor; however, the provided metadata shows 0 stars, unknown maintenance status, and no declared license, so supply-chain maturity and ongoing maintenance confidence still warrant caution.
Copy the install command and let the AI configure it · recommended for beginners
Please install the "docs-impact-classifier" skill from askskill: 1. Download https://raw.githubusercontent.com/microsoft/apm/main/.apm/skills/docs-impact-classifier/SKILL.md 2. Save it as ~/.claude/skills/docs-impact-classifier/SKILL.md 3. Reload skills and tell me it's ready
Classify the documentation impact of this pull request diff. Return only no-change, in-place edit, or structural change, plus a brief reason. Do not read the full docs corpus; use .apm/docs-index.yml only as the docs map.
A documentation impact verdict with a short rationale to decide whether to continue the docs sync flow.
You are docs-impact-classifier. Analyze this diff for documentation impact, then output verdict and reason. If it is no-change, explicitly say no downstream docs panels or sync tasks should be started.
A routing result the orchestrator can use directly, saving LLM cost when no docs work is needed.
Review the following code changes and determine whether they require structural documentation updates, such as a new module, major interface rename, or information architecture change. Choose from no-change, in-place edit, or structural change, and explain why.
A judgment on whether the change is structurally significant for docs, helping the team scope the required updates.
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.
This is a 3-layer funnel inside a single skill invocation:
The skill returns the verdict from the earliest layer that can decide.
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:
tests/**).github/workflows/**)docs/**) -- out of scope, docs-sync doesn't review docs PRs.apm/**)Expected hit rate: ~70% of PRs short-circuit here.
If L0 did not exit, extract user-observable symbols from the diff:
^@click.command, ^@cli.command, or any apm <verb> mention in added/removed lines.^@click.option, --[a-z-]+ patterns.def <name> in src/apm_cli/__init__.py or src/apm_cli/api/**.apm.yml, apm.lock.yaml, apm-policy.yml parsers._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).
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):
gh pr diff --stat output).apm/docs-index.yml (the whole file; it's ~8 KB seeded, may grow)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 | Meaning | Panel size | Cost |
|---|---|---|---|
no_change | No user-observable surface changed | 0 panel spawns | ~0-1 LLM call |
…
Audit an entire docs corpus against code and propose precise fixes.
Improve CLI output, logs, errors, and terminal diagnostic user experience.
Triages bug batches and drives related PRs to a mergeable state.
Plan doc TOC changes and outline stubs when PRs require structural updates.
Plan Python architecture, refactor class hierarchies, and design multi-file code changes.
Guide APM positioning, release communication, and breaking-change strategy decisions.
Assess PR documentation impact and produce actionable update guidance every time.
Turn docs impact verdicts into page-by-page, section-level sync task briefs.
Run a multi-expert advisory review for labelled microsoft/apm pull requests.
Write complete, evidence-backed PR descriptions for microsoft/apm pull requests.
Guide users to co-author docs, proposals, and specs through iterative refinement.
Run multi-model reviews for code changes, PRs, and risky edits.