Open Source
Two public projects: a terminal toolkit I use every day and the pipeline that builds this site.
ZDX — Zsh Developer Experience Suite
I use ZDX to inspect and run recurring terminal tasks from one searchable
menu. Built for Zsh and Oh My Zsh, it uses fzf to find a workflow and show
its details. Changes expose their targets and ask for confirmation.
The public walkthrough follows a Git task from the menu to its plan and confirmation. Its transcript and reproduction guide explain what happens at each step.
View ZDX on GitHub See the walkthrough
Three commands to start
| Command | What it does |
|---|---|
zdx |
Browse every suite, filter and preview its commands |
dev-menu |
Open one suite directly: checks, audits, cleanups |
zdx doctor |
Report missing dependencies before you need them |
What is inside
Each suite loads only when first used. The project README documents the current catalog, platform requirements and limits.
| Area | Examples |
|---|---|
| Projects | Git repositories and identities, stashes, quality checks and security audits |
| Files and environments | Archives, reviewed file cleanup, masked environment variables, Python virtual environments with uv |
| System and network | Host diagnostics, system maintenance and WireGuard tunnels |
| Extending ZDX | zdx doctor and a plugin manager for your own menus in ~/.config/zdx |
Safe by default
- Anything that changes state lists its exact targets and offers a dry run and a confirmation first.
- The installer only links a checkout you have reviewed: it downloads nothing and leaves your shell startup file alone.
- Your own plugins are Zsh code that runs in your shell, so review them before loading them.
Quality. BATS tests; shellcheck, gitleaks, actionlint, zizmor and
zsh -n in pre-commit and CI; releases with a SHA-256 checksum and signed
build provenance; OpenSSF Best Practices Silver. It runs on Linux and WSL2,
and macOS covers the core workflows. MIT license.
This site — landerox.github.io
The repository behind this site
is public: the Markdown content, the bilingual Zensical build and the checks
every change has to pass, such as SHA-pinned Actions, CodeQL, Lighthouse CI and
browser tests.
docs/decisions.md
explains each tool choice and the alternatives it rejected.
UX/UI principles
The site is also a small case study in making technical ideas usable without asking visitors to know the vocabulary first.
- Explain progressively. Each tool opens on a worked example and keeps its formulas and limits in one disclosure.
- Show state and recovery. Failure Lab separates waiting, saved, retried and rejected work, so a stopped service is not mistaken for lost work.
- Suggest without acting. In the CLI, faint suggestions and examples fill the input; only Enter runs a command.
- Keep one visual language. Shared color tokens, quiet surfaces and restrained motion, checked for contrast, focus, zoom and narrow screens in both palettes.
- Preserve control and privacy. Tools run locally, motion can be reduced and content stays readable without JavaScript.
The format follows the content: brief, scannable table cells (USWDS tables), cards that carry an action rather than a border (USWDS cards) and disclosures only for context some visitors need (GOV.UK details). WCAG 2.2 is the accessibility reference. Automated and browser checks catch defects; they do not replace sessions with real visitors, which the Tool Usability study plans and has not run. The implementation and its constraints live in the design system.