Lint sémantique

VérifiéSûr

Lint sémantique des modifications en cours de staging pour les problèmes que l'analyse statique ne détecte pas : fautes d'orthographe, commentaires obsolètes, etc. Rapport uniquement ; --fix pour les corrections mécaniques sûres.

Spar Skills Guide Bot
DeveloppementIntermédiaire
27/07/2026
Claude Code
#linting#code-review#git-staged#semantic-analysis#python

Recommandé pour

Synthèse automatique

Passe une revue sémantique des modifications indexées dans git pour repérer ce que ruff, black et les formateurs ne voient pas : fautes d'orthographe, commentaires et docstrings désynchronisés du code, documentation obsolète et idiomes maison.

Points forts

  • Cible par défaut le diff indexé (git diff --cached), ce qui s'intègre naturellement à un flux de pré-commit
  • Combine un script de collecte de candidats (scan.sh) et des vérifications réservées au LLM comme la dérive docstring/signature
  • Distingue clairement les corrections mécaniques sûres (--fix) des constats de jugement, jamais appliqués automatiquement
  • Catalogue de contrôles concret : orthographe, f-strings vs .format(), print vs logging, résidus de copier-coller, noms trompeurs

Limites

  • Fortement calibré pour le dépôt Pegasus WMS (exclusion de src/Pegasus/cli/, conventions internes), peu réutilisable tel quel ailleurs
  • Par défaut en lecture seule : sans --fix, aucune modification n'est appliquée, il faut ensuite éditer soi-même
  • Les passes sémantiques reposent sur la lecture du diff par le modèle, donc sujettes aux faux positifs et à la variabilité
Quand l'utiliser

À utiliser juste avant un commit pour relire les changements indexés à la recherche de fautes, de commentaires périmés et d'incohérences de documentation.

Quand l'éviter

Ne pas l'utiliser comme substitut à ruff, black ou aux formateurs, ni sur un dépôt sans le script scan.sh et l'arborescence de plugin attendue.

Analyse de sécurité

Sûr
Score qualité85/100

All shell access is pinned to a single bundled scanner script plus read-only git and codespell invocations; there is no curl|sh piping, no recursive deletion, no credential/token handling, and no obfuscated payloads. The only notable surface is the unpinned `uvx codespell` network fetch and the Edit grant, both of which are conventional and scoped by documentation rather than being destructive or exfiltrating. No meaningful execution risk for listing.

Points d'attention
  • •`uvx codespell` executes a package fetched from PyPI at runtime (network + remote code); it is a well-known linting package on a documented fallback path, but the version is unpinned
  • •Edit tool is granted to a skill described as report-only, though edits are documented as gated behind the explicit `--fix` flag and limited to trivial mechanical fixes
Comment cette analyse est faite

Exemples

Lint staged changes
/lint — check my staged changes for typos, stale comments and docstring drift before I commit.
Fix safe mechanical issues
Run /lint --fix on the staged files and apply only the spelling corrections and trivially safe f-string conversions.
Scope to one file
Lint packages/pegasus-python/src/Pegasus/submitdir.py for comment/code drift and docstring that no longer matches the signature.

name: lint description: Semantic lint of staged changes for things static analysis misses — spelling/typos, comments that no longer match the code, docstring/signature drift, stale docs & manpages, and house-style idioms (f-strings over .format()/%, logging over print). Use when asked to lint, run /lint, check staged changes for typos or spelling, find stale comments/docs, or review changes for issues ruff/pre-commit won't catch. Report-only; pass --fix for safe mechanical fixes. model: sonnet effort: medium allowed-tools: Bash(${CLAUDE_PLUGIN_ROOT}/skills/lint/scan.sh:), Bash(bash ${CLAUDE_PLUGIN_ROOT}/skills/lint/scan.sh:), Bash(git diff:), Bash(git status:), Bash(uvx codespell:*), Read, Edit

/lint — semantic linter for Pegasus WMS

/lint is a semantic reviewer, not another formatter. Pegasus already runs ruff, ruff-format, black/isort/autoflake, google-java-format and mdformat on every commit (pre-commit + the GitLab Lint job). This skill covers what those cannot: defects only a reader catches — misspellings, comments/docs that drifted from the code, and house-style idioms a formatter can't reason about.

It is driven by a candidate-gathering script, ${CLAUDE_PLUGIN_ROOT}/skills/lint/scan.sh, plus LLM-only passes over the staged diff. Default target is the git staged set (git diff --cached). Report-only by default; --fix applies only safe mechanical fixes.

Explicit paths passed to the scanner are relative to the target repo's root, not the plugin.

Run (agent path)

  1. Gather mechanical candidates — run the scanner over the staged set (or pass explicit paths to scope it):

    ${CLAUDE_PLUGIN_ROOT}/skills/lint/scan.sh                                   # staged files
    ${CLAUDE_PLUGIN_ROOT}/skills/lint/scan.sh packages/pegasus-python/src/Pegasus/submitdir.py   # explicit path
    

    It prints grouped path:lineno: snippet sections (spelling, formatting, print). These are candidates — you confirm or dismiss each (see Gotchas for the false positives).

  2. Read the actual staged changes for the semantic passes:

    git diff --cached
    
  3. Triage + run the semantic checks below, then assemble the report (format below).

  4. If invoked with --fix: apply only the mechanical findings (spelling corrections; .format()/% → f-string where the conversion is trivially safe) via Edit. Never auto-apply a semantic/judgment finding — those go in the report only.

Check catalog

Mechanical (scan.sh surfaces, you confirm)

  • Spelling — comments, docstrings, identifiers, user-facing strings, and .rst/.md docs. (codespell; falls back to your reading of the diff if codespell is unavailable.)
  • .format() / % → f-strings — the repo is overwhelmingly f-strings (1000+ vs ~110).
  • print() in library code → logging — src/Pegasus/cli/ is the sanctioned exception and is excluded by the scanner.

Semantic (LLM-only — read the diff; no script can do these)

  • Comment ⇄ code drift — comment/docstring claims X but the code does Y; comment references a renamed variable/param; stale comment left behind after a refactor.
  • Docstring ⇄ signature drift — Google-style :param:/:type:/return don't match the actual args or return; a documented raises that can't happen, or a raised exception that isn't documented.
  • Doc staleness — changed CLI flags/options, class signatures, or behavior not reflected in doc/sphinx/ (autodoc + sphinx_click manpages), the package README.md, or examples. Flag example commands/snippets that would no longer run.
  • Misleading names — get_*/is_* that mutates; a name that says one unit but the code uses another.
  • Error/log quality — message text that contradicts the actual failure; wrong log level (logging.error on a normal path); bare except: pass that swallows.
  • Copy-paste residue — a duplicated block where one variable wasn't updated.
  • Magic numbers/strings — unexplained literals a named constant or comment would clarify.
  • Terminology consistency — the same concept named differently across code and docs.
  • Stale TODO/FIXME — markers referencing work that's already done or removed.
  • Hardcoded paths/URLs/secrets — absolute paths, hostnames, or credentials that belong in config.

Report format

Group by check. One line per finding: file:line — issue — suggested fix. Order high→low confidence. State plainly when a section had no findings. End with a one-line summary count, e.g. Summary: 3 spelling, 1 comment-drift, 0 doc-staleness.

Gotchas

  • codespell isn't installed directly — the scanner runs it via uvx codespell (~1.5s startup). If neither codespell, the codespell_lib module, nor uvx is present, the spelling section prints a degrade notice and you cover spelling by reading the diff.
  • codespell exits non-zero when it finds typos — handled in the script (keys off output, not exit status); don't "fix" that with set -e.
  • %/.format() false positives — many % hits are regex, SQL LIKE, or strftime patterns, not string formatting. The scanner already drops logging-format lines (log.info("%s", x) is correct lazy logging); confirm the rest before flagging.
  • print() under cli/ is fine — those are user-facing CLI tools and are excluded.
  • --fix is mechanical-only — applying a semantic finding without human judgment is how you introduce bugs. Report them; don't edit them.
  • Empty staged set — scan.sh with nothing staged exits cleanly with a hint; stage files (git add) or pass explicit paths.

Du fichier au premier essai

Le téléchargement contient exactement le contenu affiché sur cette fiche. Cette copie peut différer de la dernière version du dépôt source.

Consulter la source et ses fichiers annexes

Ce téléchargement contient uniquement SKILL.md. Les scripts, références, modèles et dépendances éventuels ne sont pas inclus. Récupérez les fichiers nécessaires depuis la source en conservant leur arborescence avant de poursuivre.

1. Télécharger le fichier

Télécharger SKILL.md

Depuis la racine d’un projet de test, enregistrez le fichier sous .skill-downloads/semantic-lint-ms2s7c29/SKILL.md, ou utilisez la commande suivante. Ce dossier sert à examiner la skill avant son installation.

Commande pour macOS/Linux ou WSL : un shell POSIX et curl sont nécessaires. Sous Windows sans WSL, utilisez le bouton de téléchargement et créez le dossier manuellement.

mkdir -p '.skill-downloads/semantic-lint-ms2s7c29' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/semantic-lint-ms2s7c29/download' --output '.skill-downloads/semantic-lint-ms2s7c29/SKILL.md.part' && mv '.skill-downloads/semantic-lint-ms2s7c29/SKILL.md.part' '.skill-downloads/semantic-lint-ms2s7c29/SKILL.md'

2. Vérifier les prérequis

Lisez SKILL.md avant de l’utiliser. Si le fichier cite des scripts ou services externes, examinez-les et préparez les accès nécessaires dans votre environnement de test.

Outils déclarés par l’auteur (à vérifier dans votre agent) : Bash(${CLAUDE_PLUGIN_ROOT}/skills/lint/scan.sh:*), Bash(bash ${CLAUDE_PLUGIN_ROOT}/skills/lint/scan.sh:*), Bash(git diff:*), Bash(git status:*), Bash(uvx codespell:*), Read, Edit

Aucune section de prérequis reconnue dans ce fichier. Cela ne signifie pas qu’il est autonome : les bibliothèques, outils et accès peuvent être cités ailleurs dans le contenu ou dans le dépôt source.

Les plateformes de la fiche sont des indications du catalogue. Les chemins ci-dessous suivent la documentation des outils ; ils ne prouvent pas que cette skill y a été exécutée. Aucune version minimale de ces outils n’est attestée pour cette fiche.

3. Charger la skill

Après vérification, copiez le dossier complet dans le projet avec l’une des commandes ci-dessous, puis ouvrez une nouvelle session de l’outil. La commande s’arrête si un dossier du même nom existe déjà : comparez les fichiers avant de le remplacer.

Claude Code
test -f '.skill-downloads/semantic-lint-ms2s7c29/SKILL.md' && test -s '.skill-downloads/semantic-lint-ms2s7c29/SKILL.md' && mkdir -p '.claude/skills' && test ! -e '.claude/skills/lint' && cp -R '.skill-downloads/semantic-lint-ms2s7c29' '.claude/skills/lint'

OpenSkills

OpenSkills doit déjà être installé. La procédure locale install/read est contrôlée avec OpenSkills 1.5.0, qui exige Node.js ≥ 20.6.0. Aucun slug du catalogue n’est résolu automatiquement.

Installation officielle d’OpenSkills
openskills install './.skill-downloads/semantic-lint-ms2s7c29'

openskills read 'semantic-lint-ms2s7c29'

La lecture doit afficher le contenu du fichier installé et son dossier de base. Elle ne lance ni la skill ni ses dépendances.

Pour un agent qui lit AGENTS.md, synchronisez ensuite l’index. Cette commande modifie AGENTS.md : relisez le diff avant de l’utiliser.

openskills sync

Mode manuel ou autre outil : joignez SKILL.md à une conversation, ou ouvrez-le dans un agent capable de lire les fichiers. Ajoutez les ressources annexes nécessaires. Il n’existe pas de dossier universel reconnu par tous les outils.

4. Faire un premier essai

Utilisez une entrée courte et fictive : un endpoint d’API, un petit document ou un brief d’interface. Dans une nouvelle conversation, joignez le fichier ou donnez son chemin à l’agent, puis adaptez cette demande :

Lis .skill-downloads/semantic-lint-ms2s7c29/SKILL.md et applique ses instructions à cet exemple : [décrire une entrée de test]. Indique les fichiers, dépendances ou accès qui manquent. Produis le résultat demandé par la skill sans inventer de données ni exécuter de script non examiné.

Résultat attendu : une sortie correspondant aux instructions de la skill, ou une liste précise des prérequis manquants. Une simple confirmation de lecture ne valide pas le premier usage. Si une ressource externe est indisponible, ce parcours reste à tester.

Skills similaires