re-scale
rescale
verb
- To alter the scale of a drawing or project; to change the physical proportions.
- To change the scope of a business or project to meet a change in demands.
- Establish on a new scale.
re-scale is an utility created to make it easier to port useful libraries
to Scala using Claude Code via a project-agnostic Scala Native CLI.
It gives any codebase the same disciplined developer workflow without dragging
in project-specific behavior. One installable, tested, memory-bounded
binary that learns project specifics from .rescale/*.yaml config
files instead of hard-coding them.
Where this came from
re-scale is the third iteration of the same idea: a project-local
dev CLI that wraps a fast Claude Code hook + a persistent migration
state layer, written specifically to support large AI-assisted
language-to-language porting work.
The lineage:
-
sge-dev was the original. It lived inside
SGE — the Scala Game
Engine, a cross-platform Scala Native game engine ported from
libgdx + custom native components, targeting six desktop and three
Android architectures simultaneously. sge-dev started as a handful
of helper scripts and grew organically into ~2500 LOC of
project-specific Scala.
-
ssg-dev was bootstrapped FROM sge-dev when the same author
started SSG — the
Scala Static Site Generator — porting five upstream libraries
to Scala Native cross-platform: flexmark-java (Markdown, Java),
liqp (Liquid, Java), dart-sass (SCSS, Dart), jekyll-minifier
(HTML/JS/CSS minification, Ruby), and terser (JavaScript
compiler, JS). At the time of the re-scale split, ssg carried
~944 .scala files across 5 modules and ~80 KLoC. ssg-dev started
as a copy of sge-dev with the obviously-game-engine-specific bits
replaced; from there the two forks diverged file-by-file as each
project grew its own opinions, until they were nearly-identical-
but-not-quite duplicates.
-
re-scale is the rewrite that finally factors out the
project-specific behavior into .rescale/*.yaml config files.
No more forks. The tool itself is generic; the YAML in any given
consuming repo carries the SGE-specific or SSG-specific or
$YOUR-NEXT-PROJECT-specific opinions.
All three iterations share the same operating constraint: a single
human guiding multiple Claude Code sessions through hundreds of files
of language-to-language porting work. Neither sge-dev nor ssg-dev
nor re-scale is a standard or widely-adopted approach — they were
invented to make this specific workflow tractable.
Why a custom dev CLI?
Claude Code is excellent at code transformation, but the porting
workflow exposed two recurring failure modes that off-the-shelf
tooling didn't address:
1. A fast hook layer that nudges Claude towards safer, less wasteful patterns
By default, Claude Code can shell out to anything the OS allows. In a
repo with hundreds of files and active in-flight work, that's a
liability:
rm -rf <some-path> is usually correct, but the one time it isn't,
it's catastrophic. A hard deny saves an hour of "did I just
delete my work?" panic.- Reaching for
grep / find / cat / sed works, but the dedicated
Claude Code tools (Grep, Glob, Read, Edit) are much faster for the
user (no shell startup, no terminal scrollback flooding) AND let
Claude reason about results structurally instead of reparsing
wall-of-text output. Redirecting these to the right tool with a
one-line deny reason teaches Claude to default to the better path.
sbt --client talks to a persistent sbt server that keeps the JVM
warm and avoids the multi-second startup penalty bare sbt pays
on every invocation. Forcing the client form means a 200 ms
compile instead of a 30 s one — and across a session of dozens
of build invocations that compounds into hours of dead time.
(sbt --client itself can hang if build.sbt has an error AND
reload-on-change is enabled; the rule isn't "client is always
hang-proof," it's "stop paying JVM startup over and over.")- A handful of patterns (downloading a
.jar to grep through, writing
under /etc, reaching for .env) are so universally wrong they
deserve a hard stop regardless of intent.
