code-style

name

code-style

description

Use when writing or editing code in this org's Python or JS/TS, especially before committing or opening a PR — and proactively the moment a diff adds an import, an except/catch, or any logging. Enforces the style rules Claude gets wrong by default: import grouping, error-wrapping (no bare except / empty catch), no leftover debug prints, explicit over clever. Runs scripts/check_style.sh (ruff, mypy --strict, eslint + grep guards) which exits nonzero so it drops into a pre-commit hook or CI.

Code Style

Overview

Claude writes code that passes a default linter and still violates this org's style — because the violations live in the gaps linters don't fail on out of the box: a print() left in from debugging, except Exception: pass, imports in the wrong group, a clever one-liner where an explicit loop belonged. This skill makes those rules enforceable instead of aspirational. The single source of truth is scripts/check_style.sh, which wraps the real tools (ruff, mypy strict, eslint) and adds grep guards for the things those tools ignore by default. It exits nonzero on any violation, so the same script that you run locally is the one CI runs.

This is a "don't state the obvious" skill: it does not re-teach you Python or JavaScript. It only calls out the non-default rules and pushes Claude off its defaults.

When to Use

Use this when:

• About to commit, push, or open a PR with Python or JS/TS changes.
• A diff adds or reorders imports, adds an except/catch, or adds logging — these are where the default-vs-org gap shows up most.
• Setting up a repo's pre-commit hook or CI lint step (wire the script in once).

Do NOT use this when:

• You want a behavioral/design critique of the change — that's adversarial-review.
• You're evaluating test quality (deterministic, behavior-not-implementation) — that's testing-practices.