The models get better every few months. What you can actually get one to do is decided somewhere else: the skills, rules, subagents and MCP servers you have written or installed. That layer has a name now, the harness, and it is starting to get standards. AGENTS.md became an open spec in August 2025 and is read by more than twenty tools; .agents/skills/ is the broadest shared path there is. Cody Lindley's compatibility matrix maps where that landed.
What it hasn't got is an interface. Mine lives across a dozen folders in my home directory, and I manage it with dev tools and a symlink. Hanger is an attempt to put a simple interface on it.
I wrote about moving my agent setup to a new Mac. Doing it by hand started this.
Open source, built with Tauri and Rust. If it doesn't read your harness yet, send me the path.
What was actually on my machine
I pointed the first version at my own machine expecting a tidy number. It found 148 assets in my home directory, 357 once it walked my repositories. I had written or installed every one of them and could not have named half.
One asset, several agents
Part of that is my own doing: one canonical folder at ~/.agents/skills, symlinked into each tool. Compatibility reading pushes the same way, with Copilot reading Claude's skill paths and OpenCode falling back to CLAUDE.md. So an asset is live in several agents at once, and nothing on disk records which.
Those are the columns Hanger adds. Reach is which engines pick an asset up and through which path; beyond the store is how many of your projects it turns up in. The consequence of not having it is quiet. Edit one skill and you have changed every agent and every project that reads it, with no diff and no review, because the half that lives in your home directory never had either.
Which is why the main view turned out to be a map rather than a list. Claude Code reaches my store through two symlinks, Codex and Gemini through one each. Five roots aren't linked to it at all, though Zed still reads it where it sits.
It keeps a second list of what looks wrong. Mine came to 92 things wanting a decision, 78 of them spanning more than one repository, and nearly all of it duplication: 86 copies with no shared source. Six don't parse at all. Copying folders between machines is how you get there.
Design ethos
What the scans turn up is scattered across every agent's own footprint, and it only gets more complicated with time.
Hanger adds a visual layer over that, built from simple interface paradigms rather than new ones. A map that draws the symlinks between agent directories. An issues view for the copies that have drifted or duplicated. Skills and MCP lists that show what context and tools each agent actually has.
The design system underneath is one set of parts reused on every screen rather than something drawn per view, so a new surface starts with most of its shape already decided. It isn't settled, though. Every function that lands puts pressure on it, and it moves.
What it changes, and what it doesn't
Nearly all of Hanger reads. The one thing it changes is the link itself: Link to… writes the symlink from an engine root into the store, which is the move that makes an asset shared instead of copied. Creating, editing, deleting and renaming assets come later, because an interface earns the right to change things by first being trustworthy about what is already there. Coverage is close but not complete either: Amp's five locations are read, Windsurf's ~/.codeium only partly.
Discovery has landed already: 34 directories where the ecosystem publishes assets, format specs at the top since everything below implements one. Hanger doesn't fetch from any of them. You open one, run its install command yourself, then rescan.
I'll keep adding functions and working out which ones earn their place. Hanger is open source, so contributions are welcome, and if the roadmap or the design is more your thing than the code, that's just as useful.