Daily commits ↗ / Selected work / The AI Guide / Working principles / All repositories ↗
THE SPARK · HolyC, Terry Davis, and the curiosity to build your own world.
I'm RepoEnjoyer. I build tools that make hidden behavior easier to inspect: what a package does during installation, what a repository accidentally reveals, and what a graphics layer needs to stay small and predictable.
My work spans developer tooling, privacy, native graphics, and practical AI education. I use AI throughout the build process, with a particular interest in the decisions that still need human judgment: scope, architecture, failure modes, and whether the result is useful.
I like a good abstraction. I like knowing what it hides even more.
01 / InstallGlassWhat actually happens during An instrumented Docker sandbox that observes installation behavior and produces reviewable evidence: file activity, child processes, network destinations, and native artifacts. PACKAGE BEHAVIOR · NODE.JS / DOCKER / STRACE |
02 / LeakFenceYour source code can reveal more than secrets. A local scanner for credentials, identity leaks, Git author details, and document metadata. Findings explain the problem without echoing the sensitive value. PRIVACY ENGINEERING · NODE.JS / CLI / SARIF |
03 / OverlayKitA small window into a running system. A header-only C++20 toolkit for transparent Win32 overlays and performance HUDs. DirectX 11 rendering, a renderer-neutral draw list, and explicit resource ownership. NATIVE GRAPHICS · C++20 / WIN32 / DIRECTX 11 |
04 / RepoMendThe repository is part of the product. A deterministic repository doctor for Git state, dependency health, workflow risks, privacy, and documentation. Readable findings with a useful next action. DEVELOPER EXPERIENCE · TYPESCRIPT / GIT / CI |
The Practical AI Guide is where I organize the methods behind the work: prompting, coding agents, local models, context engineering, evaluation, and the distance between a prototype and something people can use.
Start reading ↗ · Explore the labs · Use the templates
For a different kind of machine, there's HolyC Handbook: a source-first guide to programming inside TempleOS, from the language model to memory, graphics, and small runnable programs.
- Make behavior inspectable. A finding should explain what happened and where to look next.
- Design the failure path. Limits, partial results, and recovery belong in the design.
- Keep control close to the user. Prefer local processing and reversible changes when the problem allows them.
- Write down the reasoning. Good documentation preserves the decisions, not just the commands.
A few other directions worth exploring
| Project | The question behind it |
|---|---|
| FormMint | Can 3D asset inspection happen in a private browser workspace? |
| CreatorDock | Can a creative workflow stay useful without accounts or a backend? |
| DirChord | What changed between two folders, and how can we verify it? |
| VoxLocal | How much can speech tools do with voices already on the device? |
Explore a repository. Read the design decisions. Try to break an assumption.


