Over the last few months, I have been working on several projects that share a common thread but have lived across different repositories and domains. Today, I am giving them a shared home: cli.dev.

The domain has a little history. cli.dev was the second-choice domain for Hydra. Facebook obtained it before it managed to obtain hydra.cc; once it did, Hydra moved and cli.dev spent the following years as a derelict redirect. I am now giving it a new role.

The cli.dev ecosystem brings together tools, products, and experiments for building, deploying, and operating software. It currently includes Hydra, OmegaConf, Arbiter, Reploy, and OmegaFlow.

In 2019, while working at Facebook, I started Hydra to make it easier to build and configure complex applications. Today, I am happy to share that Hydra has moved from Meta stewardship to an independent home under the Hydra Ecosystem GitHub organization.

After I left Facebook at the end of 2021, the team maintaining Hydra gradually dispersed and development slowed. Adoption continued, however, and people kept building remarkable things around the project.

During an earthquake, a building frame sways and its floors move relative to one another. A wall inside the frame may be intentionally detached, with enough clearance for the frame to move without pushing on it.

That separation matters even more when the wall is reinforced concrete, such as an insulated concrete form (ICF) wall, rather than a lightweight partition. If the frame closes the clearance and contacts the wall, the two begin interacting and both can be damaged.

The design challenge is to size this seismic gap and connect the wall to the columns in a way that keeps the wall stable while still allowing the frame to move independently. The wall needs support without unintentionally becoming part of the building's earthquake-resisting system.

I built this interactive visualization to make the gap-closing problem easier to see and to show how the beams and columns move relative to the detached wall.

You argue with your AI agent about what is in a file you already have open, only to realize later that you were looking at different versions. The agent was reading the file on disk; your editor was still showing an older buffer from before that disk change.

That mismatch is easy to miss. Version control, formatters, and agents can all change files outside the editor. When an editor tab keeps presenting stale text, you can ask your agent to fix something it already fixed, miss a generated change, or make a manual edit from old information.

llm-auth is a small local credential manager for LLM developer tools. It keeps API-key and subscription-OAuth credentials in a project .env file, with metadata that makes each auth surface discoverable, testable, and refreshable.

The motivating problem is simple: local scripts, benchmarks, evals, and agent runners often need access to several LLM providers, but the credentials tend to end up scattered across shell profiles, one-off env files, and provider-specific token stores.

Agent Skill Installer started as a by-product of another project I am working on. That project needed to install a skill reliably and easily, and the installer came out useful enough that I decided to make it available more generally.

Agent skills are useful when they are easy to try. The awkward part is usually not writing SKILL.md; it is getting the files into the right place, making the agent aware of them, and later remembering exactly what was installed.

Agent Skill Installer is a small Python tool for that part of the job. It installs Codex and Claude Code skills from GitHub, PyPI, a local checkout, or a local wheel file. Installation can be global for the current user or specific to a repository.

Backlog Atlas started from a maintainer problem I ran into when I recently started maintaining OmegaConf and Hydra again. Both projects are widely used, but they had been under-maintained for years. Over time, issues accumulated, pull requests piled up, and the backlog became hard to reason about.

With hundreds of issues and pull requests across both repositories, tackling the work directly felt almost impossible. Backlog Atlas came from needing a way to make that backlog visible enough to act on.

This first post is about making yadan.net into a small personal website: enough structure for projects, blog, about, and contact, without turning it into a full resume or a busy homepage.