Menu
Scan files for mechanism/policy separation opportunities
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use when debugging Clojure or Babashka code, especially before adding log statements or println - redirects to REPL-based inline inspection instead
When writing Clojure code with unfamiliar Java interop or macros, use this skill to explore and gather context. For Java interop, search for Clojure wrapper libraries first (via WebSearch), then explore Java classes if needed. For macros, expand them to understand what code they generate. This prevents bugs from incorrect API usage. Use this skill when encountering Java classes or unclear macros.
Use when replacing Clojure or Babashka code but str_replace fails due to formatting differences - compares S-expression structure instead
Evaluate Clojure skills through rigorous real-project testing with and without skills enabled. Use this skill whenever you need to assess whether a Clojure skill (like clj-discover, clj-debug, clj-replace) actually improves development outcomes. Compare behavior differences via context-logs, code quality, documentation depth, and test comprehensiveness. This prevents vague or hypothetical evaluation and forces concrete real-world testing.
| name | clj-refactor |
| version | 1.0.0 |
| description | Scan files for mechanism/policy separation opportunities |
Scan the specified files or directory for opportunities to improve mechanism/policy separation, following the principles below.
Using Arne Brasseur's definitions:
Mechanism is code that is:
Policy is code that is:
The distinction is not in what the code does, but in how it is written. The goal is to push code toward the edges of this spectrum.
When assessing where code sits on the spectrum, ask:
Does this code accept all its dependencies as explicit parameters, or does it rely on defaults, globals, or implicit context? (More explicit → more mechanism)
If you needed to reuse this logic elsewhere, would you call it with different parameters, or copy-paste and modify it? (Parametric reuse → mechanism; copy-paste reuse → policy)
Is this code expressing a stable technical fact, or a current business decision? Business decisions belong in policy.
How hard-coded are the values? Hard-coded constants are a sign that policy has leaked into mechanism.
Does this code prioritize convenience (easy) over explicitness (simple)? Convenience-oriented defaults are often policy leaking into mechanism.
For each file or module examined, report:
Mixed code — functions or modules where mechanism and policy are tangled together. Describe what is mixed and where the boundary should be drawn.
Extraction candidates — pieces of mechanism that are currently embedded in policy code and could be extracted into a separate module or library. For each candidate, explain why it qualifies as mechanism (context-free, stable, reusable).
Misplaced policy — business logic that has drifted into what should be low-level mechanism. Describe what assumption is hidden and where it belongs.
Proposed refactoring — for each finding, suggest a concrete refactoring. Show the before/after structure, not just the principle.
