Expanding Santi020k Theme from editor to terminal
How a VS Code palette became a generated terminal system with six application formats, three Starship styles, managed shells, validation, and Homebrew releases.
Latest
Latest post first, then browse by topic and depth.
How a VS Code palette became a generated terminal system with six application formats, three Starship styles, managed shells, validation, and Homebrew releases.
How I separated product code from distribution metadata and turned signed terminal releases into familiar Homebrew install and upgrade commands.
What separates ESLint configurations that spread across a codebase from ones that get removed after the first sprint.
In series: ESLint in Practice · Part 4
How I built 123 accessible primitives for Astro, React, and Web Components while sharing tokens and behavior without forcing one runtime model.
Why I built Dep Beacon, a VS Code extension that keeps npm update paths, pnpm catalog context, and OSV security warnings inside manifests.
Why I built Astro Doctor: a CLI, ESLint plugin, editor extension, GitHub Action, and agent skill system for catching Astro anti-patterns early.
A practical tour of the shipped @santi020k/eslint-config-basic v2.0 release: ESLint 10, one main install, lazy frameworks, lite mode, monorepos, CLI checks, and AI standards.
In series: ESLint in Practice · Part 5
DX improvements that cannot be measured rarely survive long enough to compound. Treating them like product work changes that.
In series: The santi020k way · Part 12
How a nautical personal site became a shared family platform for messages, invitations, administration, and a long-lived digital home.
Articles currently hosted on my site and cross-posted to Medium.
Topics and themes covered in my writing across various publications.
Grouped reading tracks so related posts are easier to follow in sequence.
Years of writing and sharing engineering knowledge across the web.
The santi020k way
A new blog section collecting the principles I keep returning to around ownership, code quality, feedback, responsive thinking, and calmer releases.
This series turns a private set of notes into public writing. The throughline is simple: stronger teams care about the whole system, not just the local task in front of them.
The posts cover ownership, code smells, review language, Git habits, responsive standards, team conventions, release discipline, and small readability choices that compound over time.
Focus areas
It is the right track if you want the cultural and operational rules behind how I like to build software teams, not only the framework-specific implementation details.
Series
Related posts now live in clearer tracks, so topics like Next.js delivery systems and ESLint tooling feel like connected reading instead of isolated entries.
A practical sequence for turning a fresh Next.js codebase into a product teams can lint, test, document, deploy, and secure with confidence.
A guided walkthrough from project structure to auth and delivery.
Browse seriesA focused track on config design, migrations, and the standards work that keeps code reviews sharper without slowing teams down.
Evergreen tooling notes for teams standardizing JavaScript and TypeScript work.
Browse seriesA running set of principles on ownership, review quality, code clarity, responsive thinking, and releases that do not rely on heroics.
Opinionated field notes on how strong software teams stay clear, calm, and accountable.
Browse seriesNewsletter
A low-volume email for new engineering notes, architecture writeups, and practical lessons from the work.