# Docs Changelog

> Reviews anomalib docstrings, documentation updates, and changelog expectations

- Skill: `open-edge-platform/docs-changelog` (Agent Skill)
- Install (CLI): `npx skillmds@latest add open-edge-platform/docs-changelog`
- Raw SKILL.md: https://api.skillmd.com/api/skills/open-edge-platform/docs-changelog/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: open-edge-platform (https://skillmd.com/u/open-edge-platform)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/open-edge-platform/docs-changelog

---


# Anomalib Documentation and Changelog Review

Use this skill when reviewing docstrings, user docs, examples, READMEs, and release-note impact.

## Purpose and scope

Use this skill when code changes may affect user-visible documentation, examples, READMEs, or release notes.

## Request changes when

- user-facing behavior changes without matching docs updates;
- public APIs change without docstring or reference-doc updates;
- a significant user-facing change is missing a `CHANGELOG.md` entry under `## [Unreleased]`;
- examples or README usage snippets no longer match the actual API.

## Docstrings

- Public Python APIs should use Google-style docstrings.
- Use the existing `python-docstrings` skill for docstring formatting details.
- Ask for docstrings when behavior is non-trivial, user-facing, or part of a reusable API surface.
- For tensors, arrays, batches, or structured outputs, ask reviewers to document shapes or field expectations when they matter for correct usage.

## Documentation updates

- If a PR changes APIs, CLI behavior, model behavior, config structure, workflows, or outputs, ask for related documentation updates.
- Review the nearest documentation surface, not just the edited Python file: `README.md`, docs under `docs/source/markdown/`, model-specific `README.md`, examples, or reference pages.
- Prefer small, precise doc updates over broad rewrites.

## Changelog

- Significant user-facing changes should update `CHANGELOG.md` under `## [Unreleased]`.
- Use the existing Keep a Changelog section headings already present in the repo: `Added`, `Removed`, `Changed`, `Deprecated`, `Fixed`.
- Purely internal changes may not need a changelog entry, but reviewers should call out missing entries for behavior, API, docs, or user workflow changes.

## Repo-grounded review anchors

- `CONTRIBUTING.md`
- `docs/source/markdown/guides/developer/contributing.md`
- `.agents/skills/python-docstrings/SKILL.md`
- `CHANGELOG.md`

## Review prompts

- Does the code change require docstring, README, docs page, or example updates?
- Are docstrings informative enough for users to understand behavior and expected inputs?
- Should this change be recorded under `## [Unreleased]`?
- If a public symbol or module changed, is the reference documentation still accurate?

## Reviewer checklist

- Check docstrings for public APIs.
- Check README, docs, and examples for user-facing changes.
- Check `CHANGELOG.md` for significant changes.
- Check that docs match the current API and workflow.