Clojure Development

Guide Clojure and ClojureScript development using REPL-driven workflow, coding conventions, and best practices.

You say
Install this skill Read the source first Free Written by metabase · unverified publisher
Context cost
1.6k tokensestimated from the bundle, loaded when it triggers
Bundle
1 file · 6.5 kBtext throughout, nothing executable
Licence
AGPL-3.0free to use
Last change
no release on file
Servers it uses
Noneruns standalone

What it does

Guide Clojure and ClojureScript development using REPL-driven workflow, coding conventions, and best practices. Use when writing, developing, or refactoring Clojure/ClojureScript code.

Installed, it changes the agent in these ways.

What this skill changes about the agent is not written down here yet. The listing was collected from its source, and the description is in its own SKILL.md.

Guardrail

Constrains what the agent is allowed to do.

api

The skill itself

This is the whole product. A skill is instructions the model reads, so there is nothing behind the listing you cannot see first — the front matter loads with every session, and the body below it loads when the skill triggers.

SKILL.md6.5 kB · 128 lines
--- name: clojure-write description: Guide Clojure and ClojureScript development using REPL-driven workflow, coding conventions, and best practices. Use when writing, developing, or refactoring Clojure/ClojureScript code. ---
6# Clojure Development Skill
7
8## Tool Preference
9
10When clojure-mcp tools are available (e.g., clojure_eval, clojure_edit), **always use them**
11instead of shell commands like ./bin/mage -repl. The MCP tools provide:
12- Direct REPL integration without shell escaping issues
13- Better error messages and feedback
14- Structural Clojure editing that prevents syntax errors
15
16Only fall back to ./bin/mage commands when clojure-mcp is not available.
17
18@./../_shared/development-workflow.md
19@./../_shared/clojure-style-guide.md
20@./../_shared/clojure-commands.md
21
22## REPL-Driven Development Workflow
23
24- Start with small, fundamental functions:
25- Identify the core features or functionalities required for your task.
26- Break each feature down into the smallest, most basic functions that can be developed and tested independently.
27- Write and test in the REPL:
28 - Write the code for each small function directly in the REPL (Read-Eval-Print Loop).
29 - Test it thoroughly with a variety of inputs, including typical use cases and relevant edge cases, to ensure it
30 behaves as expected.
31- Integrate into source code:
32 - Once a function works correctly in the REPL, move it from the REPL environment into your source code files (e.g.,
33 within appropriate namespaces).
34- Gradually increase complexity:
35 - Build upon tested, basic functions to create more complex functions or components.
36 - Compose smaller functions together, testing each new composition in the REPL to verify correctness step by step.
37- Ensure dependency testing:
38 - Make sure every function is fully tested in the REPL before it is depended upon by other functions.
39 - This ensures that each layer of your application is reliable before you build on it.
40- Use the REPL fully:
41 - Use the REPL as your primary tool to experiment with different approaches, iterate quickly, and get immediate
42 feedback on your code.
43- Follow functional programming principles:
44 - Keep functions small, focused, and composable.
45 - Use Clojure's functional programming features—like immutability, higher-order functions, and the standard
46 library—to write concise, effective code.
47
48## How to Evaluate Code
49
50### Bottom-up Dev Loop
51
521. Write code into a file.
532. Evaluate the file's namespace and make sure it loads correctly with:
54
55```
56./bin/mage -repl --namespace metabase.app-db.connection
57```
58
593. Call functions in the namespace with test inputs, and observe that the outputs are correct
60 Feel free to copy these REPL session trials into actual test cases using deftest and is.
614. Once you know these functions are good, return to 1, and compose them into the task that you need to build.
62
63## Writing Docstrings
64
65A docstring is a contract for the *caller*, not a diary for the
66implementer. It states what the function does, what it takes, returns,
67throws, and the preconditions/invariants the caller must respect. Those
68guarantees and requirements *belong* there — they are exactly what the
69caller needs surfaced in the IDE.
70
71When you find implementation context in a docstring, the default is to
72**relocate it, not delete it** — move it to an inline comment at the
73point in the body where it is actually relevant. That context is often
74genuinely valuable; it is just in the wrong place (the caller should not
75have to read it; the implementer standing at that line should). Delete
76outright only when it is blather: self-congratulation, restating the
77obvious, or documenting a property that is the expected default.
78
79On that last case — narrating properties like "portable across all
80supported appdbs" earns no sentence. If it were not portable, that is
81either a bug, or it means callers must handle each case themselves — and
82in *that* case it is the *absence* of the property that must be
83documented. Document deviations from expectation, not conformance to it.
84
85Heuristic — a sentence earns its place in the docstring only if it
86passes both tests:
87
881. Rewrite test (necessary, not sufficient): if rewriting the body to a
89 different implementation with an identical contract could make the
90 sentence false, it describes the implementation, not the contract.
91 Relocate it to an inline comment at the point in the body where it
92 applies.
93
942. Ownership test: if the sentence states a fact about code this
95 function does not own — a callee's behavior, a library's guarantee —
96 it survives any rewrite trivially, which is exactly why the rewrite
97 test alone is not enough. If this body *relies* on that fact, it is
98 implementation context: relocate it to the call site. If nothing here
99 relies on it, it is blather about someone else's code: delete it, and
100 let the callee's own docstring answer for it.
101
102Say each fact once. Duplicated prose is a stale comment in advance: when
103the fact changes, one copy gets updated and the rest quietly rot. This
104holds even within code you own — a namespace docstring that
105re-summarizes its own multimethods, three sibling functions carrying the
106same paragraph about retry behavior. Give the fact one home, and have
107the other places name it rather than restate it.
108
109Multi-line docstrings are not banned — a genuinely non-obvious constraint
110the code had to deal with can be worth explaining. But be prudent; the
111failure mode is far too much detail. When tempted to write a
112multi-paragraph explanatory docstring, check with the user first. And
113prefer a *test* to prose: if a future reader thinks "that's a silly way
114to do it" and changes it, a test should fail and tell them why. If that
115breakage keeps happening, *that* is the signal a comment was warranted.
116
117## Critical Rules for Editing
118
119- Be careful with parentheses counts when editing Clojure code
120- After EVERY change to Clojure code, verify readability with -check-readable
121- End all files with a newline
122- When editing tabular code, where the columns line up, try to keep them aligned
123- Spaces on a line with nothing after it is not allowed
124- After changing module boundaries (adding/removing/renaming a src namespace, a cross-module require
125 or :model/X reference, or a new module), run ./bin/mage fix-modules-config to regenerate
126 .clj-kondo/config/modules/config.edn and keep metabase.core.modules-test green. No-op when nothing
127 drifted; see "Module Boundaries" in the project CLAUDE.md.
128
In the file
SKILL.md1,010 words
Files1
LicenceAGPL-3.0
Why you can read it

Nothing in a skill executes. The client loads the text and the model follows it, so a skill can be audited the way a runbook is — by reading it.

What it costs in context

Skills are not billed by the call. They are paid for in context: every token the instructions occupy is a token your code, your diff and your conversation cannot use. Here is what this one takes and when it takes it.

≈60
always loaded
The name and description, so the model knows the skill exists and when to reach for it.
1,565
on trigger
The instruction body, read only when the skill fires.
0.81%
of a 200k window
Ten skills this size would take about 8% of the window before you open a file.
050k100k150k200k context window

1.6k tokens, estimated from the bundle at four bytes to the token, held for the rest of the session once it triggers. Middling. Fine to keep on in a project where you use it weekly, worth unloading in one where you never do.

Servers bill, skills cost

A server charges by the month. A skill charges once per session, in context, and then keeps charging it for as long as the session lives.

Before and after

The same question, put to the same model twice: once as it comes, and once with these instructions loaded.

No worked example has been published for this skill yet.

Adoption
Installsnone yet
Ratingno reviews yet

The procedure it runs

The procedure has not been published here. It is in the skill’s own SKILL.md, which its author has not sent to the marketplace yet.

Prose, not code

These steps are written for a model to follow, not executed by a runtime. It can still be told to skip one, and it will say so when it does.

Servers it uses

None. This skill calls no MCP servers at all.

Everything it needs is in the instructions, so it works in a project with nothing connected — the model reads the file and changes how it works with what it can already reach.

It writes no files and reaches no network. All it changes is how the model reasons and writes.

What it asks for
Writes filesno
Network accessno

Read from the allowed-tools line of this skill’s own SKILL.md. A skill grants no permissions of its own — it can only ask for tools your client already has.

What it will not do

Every skill is narrow, and the useful ones say where they stop. These are the jobs this one is the wrong tool for.

What this skill is not for has not been published here. Nothing is implied by that: it is a section the author has not filled in.

What is in the bundle

1 file, 6.5 kB on disk. A bundle is text throughout: the instructions the model reads, plus the templates it fills in.

  • SKILL.md6.5 kB
What is not in it

No dependencies and nothing executable: a skill is text the agent reads, so the bundle is 1 file you can review in full before installing. The AGPL-3.0 licence covers the templates and examples as well as the instructions.

Install

Installing copies the bundle into your project. Nothing runs at install time — the files sit on disk until the model reads them.

# Clojure Development · 1.6k tokens when loaded npx mcprush@latest skill add metabase/clojure-development

Writes to .claude/skills/clojure-development/ in the current project. Add --global to put it in your home directory instead, for every project.

Which clients pick it up on their own

A skill is a folder of text. A client with a skills folder reads it without being told; everywhere else the same text works, it is just handed to the model rather than found.

Claude Code.claude/skills/
Claude Desktop
ChatGPT
Cursor.cursor/skills/
VS Code.github/skills/
Codex CLI.agents/skills/
Gemini CLI.gemini/skills/
Grok.grok/skills/
Zed.agents/skills/
Windsurf.windsurf/skills/
Agent SDK.claude/skills/
HTTP / API
This release
Versionnot versioned
Publishedno release date on file
PriceFree
Referencemetabase/clojure-development

Versions

Its author publishes no version number, so there is nothing here to pin to: what you install is the folder as it stands today. Instructions change more often than APIs do — a skill can be rewritten entirely without anything it depends on moving.

v
  • No earlier releases have been published to the marketplace.
Pinning

Nothing to pin to: this skill carries no version number of its own. What you install is what the folder holds on the day you install it.

Reviews

no reviews yet · no installs yet

Nobody has reviewed this skill yet. The rating is the mean of the reviews written here, so there is none until somebody writes the first.

Who can post

Only accounts that have had the skill installed for fourteen days, so a review is written after living with it rather than after reading it. Publishers may reply once.

Publisher
Servers0
Claim this skill