I use a bunch of different harnesses depending on model need, usage limits, harness-specific capabilities, and other factors. I often switch between ClaudeCode for heavy coding, hit the 5hr limit, switch to Codex to finish it up. If I'm at limits for all, I'll go to OpenCode(DeepSeek) and finish up there.
This is a great problem to have, coding has never been easier. But, it also introduces a problem that I've had issues with for a while. The whole ecosystem is fragmented.
And this is just picking on a few of the popular harnesses. Bring in Antigravity, Roo, Cline, Zed, Gemini, Pi, Amp, you name it, and it just gets even more fragmented. Now, we're maintaining 20+ files just to make a project portable for other developers using their preferred harness.
We're doing better at converging onto standards (e.g. SKILSL.md, Agent Plugin Spec, MCP spec, AGENTS.md) but there's still overall fragmentation in where these files exist, what clients support the standard, what interfaces the standards support (e.g. Agent Plugin Spec only supports skills/MCP, not hooks or agents). Overall, it's messy.
So, I built Etymon. It's goal is very simple. Convert via `etymon convert` all your existing harness-specific files into a single, understandable unit (`etymon.toml`). Then, anyone can sync it to their harness via `etymon sync --harness codex`, for example. No need to track all these different files, just track `etymon.toml` and `etymon.lock` and profit.
And the goal here is not a new standardization. Etymon uses existing standards where possible (like SKILLS.md and MCP registry), so it's simply a wrapper around these standards. As new standards become the norm (such as Agent Plugin Spec), Etymon will adopt those. The eventual goal is Etymon won't be needed anymore: all interfaces (Skills, Agents, MCP, Hooks, Plugins) have standard specs at standard locations, and all major clients have adopted the standards. Until then, Etymon serves as a bridge for that gap.
Looking for some validation with Etymom though. Surely it isn't just a problem I face, so hoping to get it in front of others and test it in the real world. Any feedback (even if it's "This sucks!!!!"), comments, questions, or whatever is greatly appreciated!
varman11•35m ago
This is definitely a real problem lol. I dont use much coding agents my self but sometimes when im in the middle of a session and when the rate limit hits it gets annoying so yea I see why people need this.
landoncrabtree2•58m ago
This is a great problem to have, coding has never been easier. But, it also introduces a problem that I've had issues with for a while. The whole ecosystem is fragmented.
- CLAUDE.md - .github/copilot-instructions.md - AGENTS.md - .opencode/opencode.json - .mcp.json - .codex/config.toml - .github/mcp-config.json - .cursor/rules/ - .claude/rules/ - .agents/skills/ - .github/skills/
And this is just picking on a few of the popular harnesses. Bring in Antigravity, Roo, Cline, Zed, Gemini, Pi, Amp, you name it, and it just gets even more fragmented. Now, we're maintaining 20+ files just to make a project portable for other developers using their preferred harness.
We're doing better at converging onto standards (e.g. SKILSL.md, Agent Plugin Spec, MCP spec, AGENTS.md) but there's still overall fragmentation in where these files exist, what clients support the standard, what interfaces the standards support (e.g. Agent Plugin Spec only supports skills/MCP, not hooks or agents). Overall, it's messy.
So, I built Etymon. It's goal is very simple. Convert via `etymon convert` all your existing harness-specific files into a single, understandable unit (`etymon.toml`). Then, anyone can sync it to their harness via `etymon sync --harness codex`, for example. No need to track all these different files, just track `etymon.toml` and `etymon.lock` and profit.
And the goal here is not a new standardization. Etymon uses existing standards where possible (like SKILLS.md and MCP registry), so it's simply a wrapper around these standards. As new standards become the norm (such as Agent Plugin Spec), Etymon will adopt those. The eventual goal is Etymon won't be needed anymore: all interfaces (Skills, Agents, MCP, Hooks, Plugins) have standard specs at standard locations, and all major clients have adopted the standards. Until then, Etymon serves as a bridge for that gap.
Looking for some validation with Etymom though. Surely it isn't just a problem I face, so hoping to get it in front of others and test it in the real world. Any feedback (even if it's "This sucks!!!!"), comments, questions, or whatever is greatly appreciated!
varman11•35m ago