메뉴
Scan files for mechanism/policy separation opportunities
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
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.
SOC 직업 분류 기준
| 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.
