Clojure Review
Automate Metabase-aligned Clojure/ClojureScript PR review that flags style-guide violations without noise praise or parenthesis nitpicks.
Overview
clojure-review is an agent skill for the Ship phase that reviews Clojure and ClojureScript diffs for Metabase coding standards and quality issues.
Install
npx skills add https://github.com/metabase/metabase --skill clojure-reviewWhat is this skill?
- Flags Metabase Clojure style guide violations via shared `_shared` references
- Optional cross-check against `CLOJURE_STYLE_GUIDE.adoc` in the working tree
- Explicit anti-patterns: no congratulatory comments, no 'looks good' filler
- Skips missing-parens comments (delegated to linter)
- Allowed tools: Read, Grep, Bash, Glob for repo-scoped review
Adoption & trust: 806 installs on skills.sh; 47.6k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your Clojure PR review is inconsistent—either too noisy with praise or missing Metabase-specific style violations.
Who is it for?
Metabase contributors or agents reviewing Clojure/ClojureScript PRs with Read/Grep access to the codebase.
Skip if: Greenfield feature design, non-Clojure stacks, or reviewers who need automatic merge approval without human judgment.
When should I use this skill?
Reviewing pull requests or diffs containing Clojure/ClojureScript code for Metabase standards, style violations, and quality issues.
What do I get? / Deliverables
You get a violation-focused review comment set aligned with Metabase rules, ready to paste or post on the PR—without redundant linter parenthesis notes.
- PR review comments listing style violations and potential issues only
- Checklist-aligned scan of changed forms and tests per quick review section
Recommended Skills
Journey fit
How it compares
Specialized Clojure PR checker skill, not a generic JavaScript linter or security audit pack.
Common Questions / FAQ
Who is clojure-review for?
Developers and agent workflows reviewing Metabase (or Metabase-style) Clojure and ClojureScript pull requests before merge.
When should I use clojure-review?
During Ship → review whenever a PR or diff contains Clojure/ClojureScript and you need standards enforcement instead of informal chat review.
Is clojure-review safe to install?
It requests read and search tooling on your repo; review the Security Audits panel on this Prism page and restrict Bash/Glob usage in untrusted trees.
SKILL.md
READMESKILL.md - Clojure Review
# Clojure Code Review Skill @./../_shared/clojure-style-guide.md @./../_shared/clojure-commands.md ## Review guidelines **What to flag:** - Check compliance with the Metabase Clojure style guide (included above) - If `CLOJURE_STYLE_GUIDE.adoc` exists in the working directory, also check compliance with the community Clojure style guide - Flag all style guide violations **What NOT to post:** - Do not post comments congratulating someone for trivial changes or for following style guidelines - Do not post comments confirming things "look good" or telling them they did something correctly - Only post comments about style violations or potential issues Example bad code review comments to avoid: > This TODO comment is properly formatted with author and date - nice work! > Good addition of limit 1 to the query - this makes the test more efficient without changing its behavior. > The kondo ignore comment is appropriately placed here > Test name properly ends with -test as required by the style guide. **Special cases:** - Do not post comments about missing parentheses (these will be caught by the linter) ## Quick review checklist Use this to scan through changes efficiently: ### Naming - [ ] Descriptive names (no `tbl`, `zs'`) - [ ] Pure functions named as nouns describing their return value - [ ] `kebab-case` for all variables and functions - [ ] Side-effect functions end with `!` - [ ] No namespace-alias repetition in function names ### Documentation - [ ] Public vars in `src` or `enterprise/backend/src` have useful docstrings - [ ] Docstrings use Markdown conventions - [ ] References use `[[other-var]]` not backticks - [ ] `TODO` comments include author and date: `;; TODO (Name 2025-01-01) -- description` ### Code Organization - [ ] Everything `^:private` unless used elsewhere - [ ] No `declare` when avoidable (public functions near end) - [ ] Functions under 20 lines when possible - [ ] No blank, non-comment lines within definition forms (except pairwise constructs in `let`/`cond`) - [ ] Lines ≤ 120 characters ### Tests - [ ] Separate `deftest` forms for distinct test cases - [ ] Pure tests marked `^:parallel` - [ ] Test names end in `-test` or `-test-<number>` ### Modules - [ ] Correct module patterns (OSS: `metabase.<module>.*`, EE: `metabase-enterprise.<module>.*`) - [ ] API endpoints in `<module>.api` namespaces - [ ] Public API in `<module>.core` with Potemkin - [ ] No cheating module linters with `:clj-kondo/ignore [:metabase/modules]` ### REST API - [ ] Response schemas present (`:- <schema>`) - [ ] Query params use kebab-case, bodies use `snake_case` - [ ] Routes use singular nouns (e.g., `/api/dashboard/:id`) - [ ] `GET` has no side effects (except analytics) - [ ] Malli schemas detailed and complete - [ ] All new endpoints have tests ### MBQL - [ ] No raw MBQL manipulation outside `lib`, `lib-be`, or `query-processor` modules - [ ] Uses Lib and MBQL 5, not legacy MBQL ### Database - [ ] Model and table names are singular nouns - [ ] Uses `t2/select-one-fn` instead of selecting full rows for one column - [ ] Logic in Toucan methods, not helper functions ### Drivers - [ ] New multimethods documented in `docs/developers-guide/driver-changelog.md` - [ ] Passes `driver` argument to other driver methods (no hardcoded driver names) - [ ] Minimal logic in `read-column-thunk` ### Miscellaneous - [ ] Example data is bird-themed when possible - [ ] Kondo linter suppressions use proper format (not `#_:clj-kondo/ignore` keyword form) ## Pattern matching table Quick scan for common issues: | Pattern | Issue | | -----