Clojure Programmer Skill

Target Clojure 1.12.3+ (current stable as of September 2025). Version history at https://github.com/clojure/clojure/blob/master/changes.md.

This skill provides judgment frameworks and philosophical grounding for expert-level Clojure development. It assumes you understand functional programming and Lisp basics from training, focusing instead on Clojure-specific philosophy, when/why guidance, and retrieval triggers for avoiding common mistakes.

<core_philosophy>

Core Philosophy: Simple Made Easy

For foundational software engineering principles, see the software-engineer skill. For general FP principles, see the functional-programmer skill—this skill provides Clojure-specific guidance that supersedes those general patterns.

Rich Hickey's foundational distinction: "Simple" means one thing, one concept, one task. "Easy" means familiar, near at hand. Always choose simple over easy.

This philosophy permeates every Clojure decision:

• Maps over classes (simple: just data vs easy: familiar OOP)
• Data orientation over objects (simple: transformations vs easy: encapsulation)
• Immutability by default (simple: values don't change vs easy: mutation in place)
• Runtime contracts over types (simple: validate what you need vs easy: compile-time guarantees)

The critical insight: Simplicity enables change. Easy rots into complexity. When facing a choice between "this feels familiar from Java/Python/JavaScript" and "this is the Clojure way," choose the Clojure way. The unfamiliarity is temporary; the simplicity compounds.

"Programs must be written for people to read, and only incidentally for machines to execute." — Hal Abelson, SICP

Code as Ontology: The Open-World Assumption

From Rich Hickey's Spec-ulation: Clojure's design was inspired by RDF's open-world assumption. Code is an ontology of a solution. Names create enduring semantic commitments.

Open Systems Enable Growth

"If I put on a hat, it does not change what my family is." — Rich Hickey

Maps are collections of keys, not the stuff inside the keys. Extra keys don't change identity:

;; These are the same entity with different knowledge
{:user/id 123 :user/name "Alice"}
{:user/id 123 :user/name "Alice" :user/email "[email protected]"}

;; Identity preserved, knowledge accreted

This is RDF's open-world assumption:

• You don't know everything about an entity upfront
• New facts can always be added
• Systems should tolerate unknown information
• Prohibition ("no other keys allowed") turns growth into breakage

Spec Embodies Open-World Reasoning

"Spec is about what you CAN do, not about what you CAN'T." — Rich Hickey

Why spec doesn't allow closed maps:

;; If you could say "only these keys"
(s/def ::user (s/closed-keys :req [::id ::name]))

;; Then adding ::email later would BREAK everything
;; Every consumer would need updating
;; Growth becomes breakage
;; Cascading changes up the dependency tree

The open-world discipline:

• Always presume you might receive more than you know about
• Select the keys you need: (select-keys user [::id ::name])
• Don't blindly display everything (might expose sensitive data)
• Ignore what you don't understand
• Never prohibit growth

Levels and Scopes: Don't Conflate

Each level is a collection with two operations: add or remove.

• Functions — require args, provide return
• Namespaces — collections of vars (adding vars = growth, removing = breakage)
• Artifacts — collections of namespaces (adding namespaces = growth, removing = breakage)

"My family doesn't change when I put on a hat." A function changing (putting on a hat) doesn't change the namespace (the family). Don't version the namespace because a function changed. Don't version the artifact because a namespace changed.

Accretion Over Breakage

Growth happens through accretion:

• Provide more (return additional keys)
• Require less (make parameters optional)
• Add new functions alongside old ones (foo and foo-2 coexist)

Breakage happens through:

• Requiring more (mandatory parameters)
• Providing less (removing return keys)
• Removing functions
• Changing semantics under the same name

The discipline: Turn breakage into accretion. Don't remove foo, add foo-2. Don't require new parameters, make them optional. Don't remove keys from returns, add new ones.

Knowledge Representation Connection

For knowledge engineers: This is why Clojure feels natural for ontology work. The language's data model mirrors RDF's assumptions:

• Open-world reasoning — Unknown facts might exist
• Monotonic knowledge growth — Add facts, don't retract (in public APIs)
• Identity vs. information — Entity identity (qualified keywords) separate from information (map values)
• Schema evolution — Adding predicates doesn't break existing queries
• Namespace = vocabulary — Like RDF namespaces, prevents collisions

Write Clojure code the way you'd design an ontology: Open to extension, explicit about semantics, preserving meaning over time. </core_philosophy>

<repl_driven>

REPL-Driven Development: Living in Your Program

The REPL isn't just a tool—it's how you think about Clojure development. Stuart Halloway: "You're living in your program invoking your tools, instead of living in your tools invoking your program."

The Fundamental Shift

Traditional development: Write code → Compile → Run → Debug → Repeat REPL-driven development: Start program → Develop features while running → Test immediately → Never restart

What this means practically:

• Launch your application once and keep it running for days
• Develop features by evaluating forms directly in namespaces
• Test functions as you write them with real data
• Debug production by connecting a REPL to running systems
• Explore APIs interactively rather than reading docs
• Build features incrementally without compile/restart cycles

The Comment Block Pattern

Standard practice for preserving REPL experiments:

(comment
  ;; REPL-driven development workflow
  (def test-user {:user/id 123 :user/name "Alice"})
  (create-user test-user)
  (db/query {:user/id 123})

  ;; These forms don't execute in production
  ;; But preserve your development process
  ;; And serve as executable documentation
  )

Why this matters: The comment block captures your development thinking. Future you (or other developers) can see how you explored the problem space. This is executable documentation of the design process.

My Limitations with REPLs

I cannot use IDE-integrated REPLs (CIDER, Calva). Terminal-based REPL invocation hangs the bash tool. I work differently:

• Evaluate individual forms via command-line tools
• Write code that's immediately testable without REPL state
• Design for composability and pure functions
• Test interactively when you run the REPL

This is actually good discipline: Code that works without complex REPL state is more robust, testable, and maintainable. </repl_driven>

<data_oriented>

Data-Oriented Design: Just Use Maps

Rich Hickey's guidance: "Just use maps." This isn't laziness—it's profound design insight.

The Philosophy

Separate code from data:

• Data is generic, code is specific
• Systems transform data, they don't encapsulate it
• Open systems beat closed abstractions
• Information wants to be discoverable

Why maps are the default:

• Flexible: add/remove keys freely without schema changes
• Composable: generic functions (assoc, dissoc, update, select-keys) work everywhere
• Discoverable: You can see what's there (keys, vals)
• Open: Consumers take what they need, ignore the rest
• Evolution-friendly: Adding data doesn't break existing code

Qualified Keywords Prevent Collisions

;; Good: namespaced keywords
{:user/id 123
 :user/name "Alice"
 :user/email "[email protected]"
 :account/id 456
 :account/balance 1000.0
 :account/currency :USD}

;; Bad: unqualified keys risk collisions
{:id 123        ; Which id? User or account?
 :name "Alice"
 :balance 1000.0}

Auto-resolved keywords in the namespace:

(ns myapp.users)

;; ::name resolves to :myapp.users/name
{::id 123
 ::name "Alice"
 ::email "[email protected]"}

When to Use Records vs Maps

Maps should be 95% of your data structures. Records exist for specific cases:

Use records when:

• Java interop requires specific types
• Performance-critical code with known fields (measure first!)
• Protocol implementation needs type dispatch
• You want a named type for clarity (rare)

Use maps when:

• Exploring the domain (always start here)
• Flexibility matters more than performance
• You don't know all fields upfront
• Different consumers need different subsets
• You want loose coupling

Don't create records prematurely. Start with maps. Only extract records when you have evidence they're needed. The flexibility of maps compounds over time.

EDN: Clojure's Data Format

EDN (Extensible Data Notation): Subset of Clojure syntax for data serialization.

• Human-readable and machine-parseable
• Richer types than JSON (keywords, symbols, sets, tagged literals)
• Extensible through tagged elements

Use EDN for:

• Configuration files
• Data exchange between Clojure systems
• Persisting application state
• When consumers understand EDN

Use JSON when:

• Interfacing with non-Clojure systems
• Web APIs for JavaScript consumers
• External requirements dictate it

</data_oriented>

<spec>

Spec: Runtime Validation, Not a Type System

Critical positioning: Spec provides runtime validation with detailed error messages. It is NOT compile-time type checking. The namespace clojure.spec.alpha is production-ready despite "alpha" (indicates potential API evolution, not quality).

When Spec is Mandatory

At system boundaries:

• External API inputs (HTTP, queue messages, file uploads)
• Public function contracts at service boundaries
• Configuration validation on startup
• Data contracts between services

Where spec shines:

• Detailed error messages for debugging
• Generative testing with random data
• Development-time instrumentation
• Executable documentation of data shapes

When NOT to Use Spec

Don't over-specify:

• Internal function arguments (adds overhead, little benefit)
• Performance-critical hot paths (validation cost matters)
• During initial development exploration
• Where the cost exceeds the value

The judgment call: Spec at boundaries where bad data enters. Don't spec internal implementation details. Trust your code within the boundary.

Basic Spec Patterns

Register specs with namespaced keywords:

(require '[clojure.spec.alpha :as s])

;; Predicate-based specs
(s/def ::id pos-int?)
(s/def ::email (s/and string? #(re-matches #".+@.+\..+" %)))
(s/def ::role #{:admin :user :guest})

;; Map specs - note: maps are OPEN by default
(s/def ::user
  (s/keys :req [::id ::email]
          :opt [::role ::created-at]))

Co-locate specs with code:

(ns myapp.users
  (:require [clojure.spec.alpha :as s]))

(s/def ::id pos-int?)
(s/def ::email string?)
(s/def ::user (s/keys :req [::id ::email]))

(defn create-user
  "Creates a new user account."
  [user-data]
  (let [validated (s/conform ::user user-data)]
    (if (s/invalid? validated)
      (throw (ex-info "Invalid user data"
                      (s/explain-data ::user user-data)))
      (db/insert! :users validated))))

Function Specs

(s/fdef create-user
  :args (s/cat :user-data ::user)
  :ret ::user
  :fn (s/and #(= (-> % :args :user-data ::email)
                 (-> % :ret ::email))))

Instrument in development only:

(require '[clojure.spec.test.alpha :as stest])

;; Development/test: validates :args at call time
(stest/instrument `create-user)

;; Production: turn off (performance overhead)
(stest/unstrument `create-user)

Generative Testing

Specs automatically generate test data:

(require '[clojure.spec.gen.alpha :as gen])

(gen/sample (s/gen ::user))
;; Generates random valid users

(stest/check `create-user)
;; Property-based testing with generated inputs

Spec Guidelines from Production Use

Maps are open by default: Extra keys allowed. This is intentional—enables evolution. Use s/keys not s/strict-keys unless you have a specific reason.

The spec IS the function: It defines correctness. Design specs carefully.

Don't fight the alpha status: clojure.spec.alpha is stable and widely used. The "alpha" means "we might make a new namespace for breaking changes" not "this is experimental."

spec2/spec-alpha2: Work in progress with no timeline. Stick with spec.alpha for all production code. </spec>

<state_management>

State Management: Atoms, Refs, Agents, and Vars

Clojure provides different reference types for different coordination needs. Understanding when to use each is critical.

Decision Tree

Atoms (90% of state):

• Uncoordinated, synchronous, independent state
• Your default choice for application state
• Use for: caches, counters, configuration, UI state
• Operations: swap!, reset!, compare-and-set!

(def app-state (atom {:users {} :sessions {}}))

(swap! app-state update-in [:users user-id] assoc :last-seen (Instant/now))

Refs (coordinated transactions):

• Coordinated, synchronous, transactional state (STM)
• Multiple identities must change together atomically
• Use for: account transfers, inventory management, ACID-like guarantees
• More overhead than atoms—only use when coordination required

(def account-a (ref 1000))
(def account-b (ref 500))

(dosync
  (alter account-a - 100)
  (alter account-b + 100))

Agents (asynchronous updates):

• Uncoordinated, asynchronous, queued state changes
• Background tasks and controlled side effects
• Use send for CPU-bound, send-off for blocking I/O

(def background-processor (agent {}))

(send background-processor process-batch data)

Vars with dynamic scope:

• Thread-local bindings for configuration
• Use for: *out*, *print-length*, context propagation
• Never use vars for application state

The Atom Anti-Pattern

Don't use atoms for everything just because they're simple:

;; Anti-pattern: global mutable state everywhere
(defonce web-server (atom nil))
(defonce db-connection (atom nil))
(defonce cache (atom {}))

(defn start! []
  (reset! web-server (create-server))
  (reset! db-connection (connect-db)))

Better: Component/Mount/Integrant for lifecycle:

(defn create-system []
  {:web-server (create-server)
   :database (connect-db)
   :cache {}})

Why: Global atoms create hidden dependencies, make testing hard, and obscure system boundaries. Use lifecycle libraries for managing stateful resources. </state_management>

<common_mistakes>

Common Mistakes from Other Language Backgrounds

These patterns are retrieval triggers—seeing them should activate knowledge about the Clojure alternative.

<from_java>

From Java: Fighting Data Orientation

Overusing class hierarchies where maps suffice:

;; Java thinking: types for everything
(defrecord User [id name email])
(defrecord Admin [id name email permissions])
(defrecord Guest [id name])

;; Clojure thinking: just data
{:user/id 123 :user/name "Alice" :user/role :admin :user/permissions #{:read :write}}
{:user/id 456 :user/name "Guest" :user/role :guest}

Creating unnecessary mutable state:

;; Java thinking: everything needs state management
(defonce users (atom {}))

(defn create-user! [user-data]
  (let [id (generate-id)
        user (assoc user-data :user/id id)]
    (swap! users assoc id user)
    user))

;; Clojure thinking: pass data through
(defn create-user [db user-data]
  (let [user (assoc user-data :user/id (generate-id))]
    (db/insert! db :users user)))

The `contains?` confusion:

;; Java: Collection#contains checks for VALUE
;; Clojure: contains? checks for KEY/INDEX

(contains? {:a 1 :b 2} :a)  ; true (key exists)
(contains? {:a 1 :b 2} 1)   ; false (1 is not a key)
(contains? [0 1 2] 1)       ; true (index 1 exists)

;; For value membership, use:
(some #{1} (vals {:a 1 :b 2}))  ; 1 (truthy)

Not enabling reflection warnings:

;; Add to dev/user.clj
(set! *warn-on-reflection* true)

;; Causes compiler warnings for reflection
;; Fix with type hints in hot paths only

Making everything private:

Clojure trusts developers. Use *.impl.* namespaces for internal details rather than making everything defn-. </from_java>

<from_python>

From Python: Lazy Evaluation Surprises

Expecting eager evaluation:

;; Lazy sequences don't realize until needed
(def results (map expensive-operation data))
;; Nothing has run yet!

;; Force realization when you need it
(doall (map expensive-operation data))  ; Realizes and returns seq
(dorun (map expensive-operation data))  ; Realizes for side effects, returns nil
(into [] (map expensive-operation data)) ; Realizes into vector

Printing infinite sequences hangs:

;; Don't do this
(println (range))  ; Hangs trying to realize infinity

;; Do this
(println (take 10 (range)))  ; Finite!

Holding sequence heads causes space leaks:

;; Bad: holds entire sequence in memory
(let [data (range 1000000)]
  (println (first data))
  (println (last data)))  ; Entire sequence retained!

;; Good: don't hold the head
(println (first (range 1000000)))
(println (last (range 1000000)))  ; Separate realization

</from_python>

<from_javascript>

From JavaScript: Async and Binding Differences

Trying to use async/await directly:

;; JavaScript async/await doesn't exist in Clojure
;; Use core.async for coordination (not all async operations!)

(require '[clojure.core.async :as async])

(defn fetch-user [id]
  (async/go
    (let [response (async/<! (http/get (str "/users/" id)))]
      (:body response))))

Over-using core.async:

;; Don't over-complicate
;; Simple callbacks are fine!

;; Overkill
(async/go
  (let [result (async/<! (simple-async-op))]
    (process result)))

;; Better: just use a callback
(simple-async-op #(process %))

Expecting 'this' binding:

Clojure has no implicit this. Pass data explicitly. </from_javascript>

<from_haskell>

From Haskell: Over-Abstraction

Creating type-level abstractions with macros:

Don't recreate Haskell's type system. Embrace dynamic runtime validation with spec.

Assuming purity enforcement:

;; Clojure: pragmatic impurity
;; Just do side effects where needed
(defn get-user-name []
  (println "Name: ")
  (read-line))

;; Isolate at boundaries, but don't fight them

Avoiding necessary runtime validation:

;; Haskell thinking: types ensure correctness
;; Clojure thinking: validate at boundaries

(defn create-user [user-data]
  (let [validated (s/conform ::user user-data)]
    (when (s/invalid? validated)
      (throw (ex-info "Invalid user"
                      (s/explain-data ::user user-data))))
    (db/insert! :users validated)))

</from_haskell>

<from_imperative>

General Imperative/OO Anti-Patterns

Not using `recur` for tail recursion:

;; Stack overflow: JVM has no TCO
(defn factorial [n]
  (if (zero? n)
    1
    (* n (factorial (dec n)))))

;; Correct: use recur
(defn factorial
  ([n] (factorial n 1))
  ([n acc]
   (if (zero? n)
     acc
     (recur (dec n) (* acc n)))))

Misusing equality:

;; Use = by default for structural equality
(= 1 1.0)   ; false (different types)
(== 1 1.0)  ; true (numeric equality only)

;; = for collections
(= [1 2 3] [1 2 3])  ; true

</from_imperative> </common_mistakes>

<advanced_topics>

Advanced Topics: Judgment Frameworks

When to Use Macros

Rich Hickey: "Don't use macros unless you absolutely need to."

Use macros when you need to:

• Control evaluation order (delay/prevent evaluation)
• Generate repetitive boilerplate that can't be abstracted with HOFs
• Perform compile-time code generation
• Create domain-specific syntax (sparingly!)
• Manipulate code as data

Use functions for everything else. Functions are the default.

Anti-patterns:

• Using macros when higher-order functions suffice
• Creating unreadable DSLs
• Premature abstraction
• Making debugging harder for no benefit

;; Don't write a macro for this
(defmacro double [x]
  `(* 2 ~x))

;; Write a function
(defn double [x]
  (* 2 x))

When you do write macros: Create usage examples first. Break complex macros into helper functions. Prefer syntax-quote forms.

When to Use Transducers

Transducers provide composable, context-independent transformations.

Use transducers when:

• Avoiding intermediate collections improves performance (measure!)
• Same transformation applies across contexts (collections, channels, streams)
• Building reusable transformation pipelines
• Performance-critical data processing

Don't use when:

• Simple threading macros are clearer
• Small collections where intermediate collections don't matter
• Team unfamiliarity outweighs benefits
• You haven't measured performance

;; Without transducers
(->> data
     (map parse)
     (filter valid?)
     (map transform))  ; Three intermediate seqs

;; With transducers (single pass)
(def xf (comp (map parse)
              (filter valid?)
              (map transform)))

(into [] xf data)
(transduce xf conj [] data)

When to Use core.async

core.async serves specific coordination needs, not all async operations.

Use core.async for:

• ClojureScript: avoiding callback hell
• Producer-consumer architectures
• Coordinating multiple async operations
• Event-driven systems with complex flow
• Pipeline processing

Avoid core.async for:

• Simple callbacks (just use callbacks!)
• No coordination between operations
• Blocking I/O (use thread not go)
• Team unfamiliar with CSP concepts

Key patterns:

• go for parking (lightweight, many thousands possible)
• thread for blocking operations
• Dynamic bindings DON'T persist across go block boundaries
• Prefix channel-returning functions with <

Performance Optimization Workflow

Always measure before optimizing.

1. Profile first:

• criterium for microbenchmarks
• clj-async-profiler for flame graphs
• tufte for application metrics
• VisualVM/YourKit for comprehensive JVM profiling

1. High-level optimization (do first):

• Fix algorithmic complexity
• Choose appropriate data structures
• Use transducers for transformation pipelines

1. Type hints (only if reflection is the problem):

• (set! *warn-on-reflection* true) in development
• Add hints to hot paths only
• Trust JVM JIT for most code

1. Primitive optimization (measure first!):

• Unchecked math for hot paths
• Primitive arrays with proper type hints
• Primitive locals in tight loops

1. Verify improvements:

• Measure before and after
• Watch for regressions
• Document why optimizations exist

Anti-patterns:

• Premature optimization
• Ignoring algorithmic complexity
• Optimizing cold paths
• Not measuring improvements
• Type hinting everything

The 90/10 rule: 90% of time spent in 10% of code. Find that 10% first. </advanced_topics>

<tooling>

Mandatory Tooling Stack

clj-kondo: Mandatory Static Analysis

clj-kondo must fail builds on errors in CI. Fast, comprehensive static analyzer:

• Arity errors across namespaces
• Unused vars and bindings
• Unresolved symbols
• Type mismatches
• Deprecated var usage
• Reflection warnings
• And much more

CI configuration:

# Run first in CI (fastest feedback)
clj-kondo --lint src test --fail-level error --parallel

Local `.clj-kondo/config.edn`:

{:linters {:unresolved-symbol {:level :error}
           :unused-binding {:level :warning}
           :unused-private-var {:level :warning}
           :deprecated-var {:level :warning}}
 :lint-as {my.macro/defroute clojure.core/def}}

Integration:

• Editor integration (real-time feedback)
• CI enforcement (fails builds)
• Pre-commit hooks (optional)

Spec: Mandatory at API Boundaries

Already covered extensively above. Key: mandatory for external inputs, optional for internal code.

zprint: Opinionated Code Formatting

zprint reformats code from scratch like gofmt or Spotless. Aggressive, opinionated, maximum consistency.

Philosophy: Surrender control of formatting for consistency. Let the tool handle it.

Configuration in `deps.edn`:

:format {:deps {zprint/zprint {:mvn/version "1.2.9"}}
         :main-opts ["-m" "zprint.main"]}

CI check:

# Check formatting (don't auto-fix in CI)
clojure -M:format "{:search-config? true}" check src test

# Format locally
clojure -M:format "{:search-config? true}" -w src test

`.zprintrc` options:

{:style :community
 :width 80
 :map {:comma? false}}

Why zprint over cljfmt: Complete reformatting ensures absolute consistency. cljfmt preserves your line breaks; zprint doesn't trust you to get them right.

Optional/Recommended Tooling

Kibit: Idiomatic Code Suggestions

"There's a function for that!" Suggests more idiomatic Clojure patterns.

Uses core.logic to find code that could be more idiomatic:

;; Kibit suggests
(if (not x) y z) → (if-not x y z)
(apply concat x) → (mapcat identity x)

Use for:

• Learning Clojure idioms
• Code reviews
• Improving existing code

Don't enforce in CI (too opinionated, some suggestions debatable).

Eastwood: Deep Static Analysis

Slower but more thorough than clj-kondo. Best for CI where speed isn't critical.

Complements clj-kondo with different checks. Use both if you want comprehensive coverage.

<testing>

Testing: clojure.test + test.check

For general testing philosophy and TDD principles, see the test-driven-development skill. This section covers Clojure-specific testing practices.

Core testing principle (from test-driven-development skill): Mock at architectural boundaries (external systems, injected dependencies), not internal implementation details.

clojure.test dominates (~85% adoption):

• Built-in
• Universal tooling support
• Battle-tested

(ns myapp.users-test
  (:require [clojure.test :refer [deftest is testing]]
            [myapp.users :as users]))

(deftest create-user-test
  (testing "creates user with valid data"
    (let [user-data {:user/email "[email protected]"}
          result (users/create-user user-data)]
      (is (pos-int? (:user/id result))
          "Generated user ID should be positive")))

  (testing "throws on invalid data"
    (is (thrown? clojure.lang.ExceptionInfo
                 (users/create-user {:invalid :data})))))

Add test.check for property-based testing:

Leverage spec for generative testing via clojure.spec.test.alpha/check. </testing> </tooling>

<build_tools>

Build Tool Selection: deps.edn for New Projects

deps.edn has won the build tool debate (70%+ adoption and growing). Leiningen still fine for existing projects.

deps.edn: Recommended for New Projects

Why:

• Officially recommended by Clojure core team
• Focused philosophy: dependency resolution and classpath
• Compose tools as needed
• Git dependencies without Maven
• Growing ecosystem momentum

Basic structure:

{:deps {org.clojure/clojure {:mvn/version "1.12.3"}}

 :paths ["src" "resources"]

 :aliases
 {:test {:extra-paths ["test"]
         :extra-deps {io.github.cognitect-labs/test-runner
                      {:git/tag "v0.5.1" :git/sha "dfb30dd"}}}

  :dev {:extra-deps {org.clojure/tools.namespace {:mvn/version "1.4.4"}}}

  :lint {:deps {clj-kondo/clj-kondo {:mvn/version "2025.01.24"}}
         :main-opts ["-m" "clj-kondo.main" "--lint" "src" "test"]}

  :format {:deps {zprint/zprint {:mvn/version "1.2.9"}}
           :main-opts ["-m" "zprint.main"]}}}

Compose aliases:

clj -M:dev:test  # Development + testing
clj -M:format "{:search-config? true}" -w src test

Leiningen: Still Valid for Existing Projects

Don't migrate unless you have a reason. Leiningen is stable, batteries-included, and well-supported.

Use Leiningen when:

• Existing project already uses it
• Team expertise is there
• Plugin ecosystem provides needed functionality

</build_tools>

<project_structure>

Project Structure and Namespace Organization

Standard Layout

my-project/
├── deps.edn
├── README.md
├── .gitignore
├── .clj-kondo/config.edn
├── .zprintrc
├── src/
│   └── myapp/
│       ├── core.clj
│       ├── users.clj
│       └── db.clj
├── test/
│   └── myapp/
│       ├── core_test.clj
│       └── users_test.clj
├── resources/
│   └── config.edn
├── dev/
│   └── user.clj
└── target/  (gitignored)

Namespace Organization Principles

Large namespaces are acceptable. Clojure core has 500+ symbols in one namespace. Don't over-fragment.

Hard rule: No circular dependencies. If A requires B, B cannot require A.

Naming pattern: [organization].[project].[module]

(ns myapp.users
  "User management functionality."
  (:require [clojure.spec.alpha :as s]
            [clojure.string :as str]
            [myapp.db :as db])
  (:import [java.time Instant]
           [java.util UUID]))

Standard library aliases (use these):

• [clojure.string :as str]
• [clojure.set :as set]
• [clojure.java.io :as io]

dev/user.clj Pattern

(ns user
  "Development namespace loaded automatically."
  (:require [clojure.tools.namespace.repl :refer [refresh]]))

(defn start []
  (start-system))

(defn stop []
  (stop-system))

(defn reset []
  (stop)
  (refresh :after 'user/start))

(comment
  (start)
  (stop)
  (reset))

</project_structure>

<documentation>

Documentation Standards

Public API functions require docstrings. Production code expectations.

Docstring Format

(defn create-user
  "Creates a new user account with the provided data.

  Validates `user-data` against the ::user spec and persists
  to the database. Returns the created user with generated :user/id.

  Arguments:
  - `user-data`: Map with :user/email (required), :user/role (optional)

  Returns:
  - Created user map with :user/id, :user/email, :user/created-at

  Throws:
  - `ex-info` with spec explanation if validation fails
  - `SQLException` if database insert fails"
  [user-data]
  ...)

Rules:

• First line: complete sentence summarizing function
• Format for ~80 characters
• Use Markdown (compatible with Codox/cljdoc)
• Wrap identifiers in backticks
• Link related vars: [[related-fn]]

Metadata:

(defn ^:no-doc internal-helper ...)  ; Exclude from docs

(defn ^{:deprecated "1.2.0"} old-fn
  "Legacy. Use [[new-fn]] instead."
  ...)

</documentation>

Version Targeting and Upgrade Philosophy

Clojure 1.12.3 (September 2025) is current. Version history: https://github.com/clojure/clojure/blob/master/changes.md

Aggressive Adoption is Safe

The community upgrades rapidly thanks to exceptional backward compatibility.

Rich Hickey's "Spec-ulation" philosophy:

• Growth through accretion (adding), not breakage (removing)
• Breaking changes warrant new namespaces, not version bumps
• "Dependency hell becomes mutability hell"

Practical guidelines:

• Upgrade to stable releases within 6-12 months
• Specify exact versions in deps.edn
• Test thoroughly despite strong compatibility
• Monitor https://clojure.org/releases/devchangelog

Clojure 1.12 highlights:

• Method values (Java methods as first-class functions)
• Functional interface adaptation (IFns auto-convert)
• Array class syntax
• Virtual thread support

Compatibility: Java 8 minimum, Java 21 LTS recommended, supports through Java 25.

Respecting Third-Party Codebases

Aggressive adoption applies ONLY to codebases you own.

When contributing to open source:

• Respect existing style and tooling choices
• Follow their Clojure version targeting
• Don't force modern features on older codebases
• Propose improvements through proper channels
• "You're a guest—respect the house rules"

<related_skills>

Related Skills

• software-engineer — Core engineering philosophy, system design principles
• functional-programmer — General FP principles (this skill provides Clojure-specific guidance)
• test-driven-development — Testing philosophy and TDD principles

</related_skills>

<resources>

Resources

Official:

• https://clojure.org - Official site
• https://github.com/clojure/clojure/blob/master/changes.md - Changelog
• https://clojure.org/guides/spec - Spec guide
• https://clojure.org/reference/java_interop - Java interop

Rich Hickey's Essential Talks (transcripts—machine-readable):

• Transcripts: https://github.com/matthiasn/talk-transcripts/tree/master/Hickey_Rich
• Key talks: "Simple Made Easy", "Value of Values", "Spec-ulation" (read transcripts, not video)

Community:

• https://guide.clojure.style - Authoritative style guide
• https://clojuredocs.org - API reference with examples
• https://clojureverse.org - Discussion forum
• https://corfield.org - Sean Corfield's production experience

Tooling:

• https://github.com/clj-kondo/clj-kondo - Static analyzer
• https://github.com/kkinnear/zprint - Code formatter
• https://github.com/clj-commons/kibit - Idiomatic suggestions
• https://github.com/jonase/eastwood - Deep static analysis

Books (online):

• "Clojure for the Brave and True" - https://www.braveclojure.com

Performance:

• https://clojure-goes-fast.com/blog/performance-nemesis-reflection
• https://codescene.com/engineering-blog/performance-optimization-workflow-clojure

</resources>