open-edge-platform/anomalib · Archived

python-style

Reviews anomalib Python style, typing, imports, and public API conventions

First seen May 13, 2026

Installation

$ npx skills add open-edge-platform/anomalib --skill python-style

Stronger alternatives

This repository is archived — consider an actively maintained alternative.

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from open-edge-platform/anomalib · top by installs.

npx skills add open-edge-platform/anomalib

Browse all from open-edge-platform/anomalib

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Also listed on

Alternate registries and mirrors of this skill.

Repository health

Stars 6.1K
License LICENSE
Default branch main
Open issues 37
Status Archived

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 2,755 B
  • docs SUMMARY.md 94 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 3 installs

SKILL.md

Anomalib Python Style Review

Use this skill when reviewing Python code in src/anomalib/ or tests/.

Purpose and scope

This skill covers Python style, typing, imports, exports, copyright headers, and basic code hygiene.

Core rules

  • Target the repository's Python baseline.
  • Follow the Ruff-configured line length of 120 characters.
  • Match nearby anomalib code before suggesting stylistic rewrites.
  • Prefer explicit, readable code over clever shortcuts.

Request changes when

  • public APIs are missing type annotations;
  • new code introduces weak typing such as unnecessary Any or untyped public **kwargs;
  • imports or exports drift from nearby package patterns;
  • a touched Python file is missing the expected copyright/SPDX header;
  • error handling becomes less explicit or debug code is left behind.

Typing

  • Public functions, methods, and constructors should have explicit type annotations.
  • Prefer repository-established typing patterns such as X | None, type[...], Sequence[...], TypeVar, and Generic where they fit.
  • Do not weaken types without a strong reason.
  • Flag vague escape hatches such as unnecessary Any, broad untyped **kwargs, or type suppressions that hide real issues.

Imports and exports

  • Keep imports grouped as standard library, third-party, then local imports.
  • Prefer absolute imports inside anomalib.
  • When a public symbol is added to an init.py, verify that all stays accurate.

Copyright and license header

  • Python source files should include the standard Intel copyright and SPDX header used across the repository.
  • For a new file, use the current year only, for example:

- # Copyright (C) 2026 Intel Corporation - # SPDX-License-Identifier: Apache-2.0

  • For an existing file updated in 2026, ensure the year or year range includes 2026.

- Example: update 2024 to 2024-2026. - Example: keep 2026 for a single-year file created in 2026.

Error handling and code hygiene

  • Catch specific exceptions instead of broad or silent failure patterns.
  • Ask for explicit exceptions and informative error messages.
  • Flag debug prints, dead code, commented-out code, and magic values that should be named constants or config.
  • Prefer explicit validation with raised exceptions over fragile assumptions.

Repo-grounded review anchors

  • pyproject.toml defines Ruff, pydocstyle, mypy, pytest, and Commitizen expectations.

Reviewer checklist

  • Check typing on public APIs.
  • Check imports and exports.
  • Check the copyright/SPDX header on touched Python files.
  • Check for obvious code hygiene regressions.