$ ~/registry/skill/microsoft-apm-skills-docs-impact-localizer

SKILL

docs-impact-localizer

Name: docs-impact-localizer
Author: microsoft

Turn docs impact verdicts into page-by-page, section-level sync task briefs.

Stars

★ 3,163

Source

GitHub

Updated

2026-07-10

// securityCaution

Prompt only, no code
Open source

Summary

This appears to be an open-source, prompt-only documentation planning skill with no declared secrets, remote endpoints, or executable components, so the overall risk is low. It is intended to process PR diffs and document content, but the provided materials show no standalone data exfiltration, code execution, or over-privilege red flags.

CredentialsLow risk

The materials explicitly state there are no required secrets or environment variables, and the README does not request API tokens, account credentials, or third-party authentication; no obvious credential collection, storage, or abuse path is shown.

Network egressLow risk

No remote endpoint is declared; as a prompt-only skill, the documentation does not state that PR diffs, page contents, or other user data are sent to external hosts, and no concrete egress red flags are present.

Code executionLow risk

The material is system-classified as prompt-only, with no executable script, install command, or local process-launch logic provided. References such as `gh pr diff` and `grep` appear to be workflow examples or context, not execution privileges explicitly granted to the skill itself.

Data accessCaution

The README says the skill works from `scope_pages[]`, PR diffs, and `.apm/docs-index.yml` to localize edits within documentation pages, so its intended workflow does touch repository docs and change data. For this skill type, that is routine minimum-necessary data handling, and there is no evidence of write/delete behavior or overbroad access to wider system resources.

Supply chainCaution

Positive factors include a GitHub-hosted open-source repository that is auditable, and the `microsoft/apm` ownership improves source credibility; however, the license is unspecified, stars are 0, and maintenance status is unknown, so community adoption and ongoing stewardship signals are weak and warrant basic repo and commit-history review before adoption.

Recommendations

Before adoption, verify repository ownership, recent commits, and release practices to confirm it is the intended `microsoft/apm` project.
If used in automation, restrict inputs to only the necessary PR diff and documentation paths to avoid exposing unrelated repository content.
Review license status and maintenance signals, and confirm internal compliance suitability before production use.

Audited by: gpt-5.4 · 2026-06-17

// install

Copy the install command and let the AI configure it · recommended for beginners

Please install the "docs-impact-localizer" skill from askskill:
1. Download https://raw.githubusercontent.com/microsoft/apm/main/.apm/skills/docs-impact-localizer/SKILL.md
2. Save it as ~/.claude/skills/docs-impact-localizer/SKILL.md
3. Reload skills and tell me it's ready

// download

Download SKILL.mdInstall manifest ↗

// examples

Generate a docs sync task breakdown

Prompt

docs-impact-classifier has returned verdict=in_place. Using the candidate page list, read each page, identify the specific affected sections, and output a per-page task brief including page name, sections to update, reason for change, and recommended action.

Expected

A page-organized task list showing the exact sections to update and recommended actions.

Narrow the documentation change scope

Prompt

For this set of candidate documentation pages, do not mark entire pages for updates. Inspect the actual page contents, narrow the impact down to specific headings, paragraphs, or note blocks, and produce the smallest actionable per-page update plan.

Expected

A precise update scope that avoids full-page rework and supports panel fan-out execution.

Prepare per-page briefs for the panel

Prompt

Convert the in_place verdict into page task briefs that the docs-sync panel can use directly. Based on the candidate pages and their contents, explain for each page what to change, why it changes, and the boundaries of the edit.

Expected

Per-page briefs ready for downstream panel fan-out, including edit locations, reasons, and boundaries.

// docs

docs-impact-localizer

Single responsibility: given a list of candidate pages from the classifier, produce a per-page task brief the docs-sync panel can fan out against.

You are NOT the verdict-maker (classifier owns that). You are NOT the writer (doc-writer owns that). You are the work planner.

When to invoke

The docs-sync orchestrator invokes you ONLY when the classifier returned verdict: in_place. For no_change you don't run. For structural the architect runs first; you may run after, scoped to existing pages that need amendment.

Inputs

scope_pages[] from the classifier
The PR diff (gh pr diff $PR)
.apm/docs-index.yml (per-page metadata)
Optional: the structural architect's TOC delta (if you run after the architect on a structural verdict)

Step 1: load page contents

For each path in scope_pages[], read the file. Pages are typically 3-10 KB; total budget for this step is bounded by the candidate count (the classifier should have kept it to <= 6).

Step 2: narrow scope inside each page

For each page, identify the SPECIFIC section(s) that need to change:

Read the page's H2/H3 structure
For each diff symbol from the classifier output, find the section most directly documenting it
Capture line ranges: lines 120-145 not the whole page

The output is a sections_to_edit[] per page, where each entry is:

page: docs/src/content/docs/consumer/install.md
sections_to_edit:
  - section: "## From Git"
    line_range: [120, 145]
    diff_symbol: "--no-cache flag"
    edit_kind: add | modify | remove
    rationale: "the new --no-cache flag is documented nowhere; section already lists other flags so this is the natural home"

Step 3: detect cross-page conflicts

If two pages document the same symbol and the diff changes the symbol's behaviour, BOTH pages need an edit AND they must stay consistent. Flag this in the brief so the CDO synthesizer knows to cross-check coherence between the two redrafts:

cross_page_constraint:
  pages: [path1, path2]
  shared_symbol: "apm install --target"
  consistency_required: "both pages must reflect the same default value"

Step 4: emit the per-page task brief

Return JSON with this shape (one entry per page in scope_pages[]):

{
  "tasks": [
    {
      "page": "docs/src/content/docs/consumer/install.md",
      "persona_owner": "consumer",
      "promise": 1,
      "sections_to_edit": [
        {
          "section": "## From Git",
          "line_range": [120, 145],
          "diff_symbol": "--no-cache flag",
          "edit_kind": "add",
          "rationale": "..."
        }
      ],
      "verify_claims": [
        {"claim": "the flag is named --no-cache", "verify_with": "apm install --help"},
        {"claim": "the flag is documented in click.option decorator", "verify_with": "grep -n no-cache src/apm_cli/commands/install.py"}
      ]
    }
  ],
  "cross_page_constraints": [
    {"pages": [...], "shared_symbol": "...", "consistency_required": "..."}
  ],
  "estimated_panel_calls": 8
}

The verify_claims[] per page is consumed by the python-architect panelist -- it tells the verifier WHICH claims need a S7 tool-call check (run apm install --help, grep the source) rather than prose-trusting.

Output contract

Return a SINGLE JSON document matching the schema in Step 4 as the final message of your task. No prose around the JSON.

Anti-patterns

Selecting whole pages when one section suffices (inflates context per panelist).
Skipping verify_claims[] -- that's the S7 tool-bridge hook; the verifier needs it.
Inventing pages not in scope_pages[] -- that's the classifier's job, not yours. If you think the classifier missed a page, return an extra field localizer_concern instead of expanding scope unilaterally.