Usora Turns AI Debugging Sessions Into Reusable, Versioned Skills
AI coding agents are fragmenting into separate ecosystems (Codex, Claude, Kimi, Gemini), each with its own skill silos. Usora proposes a cross-agent protocol where hard-won debugging and design methods become personal engineering assets that survive model and tooling changes.
Repeatedly re-teaching an AI agent the same debugging steps wastes the context, methods, and validation criteria already discovered. Usora introduces a Foundry pipeline that observes real development activities — fixing a memory leak, refactoring a module, designing a CI workflow — and extracts only the practices worth keeping into structured Skills. These Skills carry versions, provenance, test records, and changelogs, evolving like code rather than sitting as lost markdown in a chat history.
The system separates concerns across multiple AI agents: any agent can propose a Candidate Skill from observed practice, but a designated Maintainer (defaulting to Codex) reviews, tests, versions, and publishes. This keeps a personal Skill Hub from becoming an uncontrolled auto-generated dump while still leveraging different models for different tasks.
A planned Skill Market would let developers share battle-tested Skills — such as a Vue memory-leak analysis or a React performance audit — that have been validated across real projects. The longer vision is a Capability Network where people, agents, and Skills interconnect, with humans deciding what is worth preserving.
The core waste in AI-assisted development is not rewriting prompts but losing the accumulated context, judgment criteria, and workflow that a session already produced.
Treating a debugging method as a versioned engineering asset — with provenance, testing, and rollback — is a category shift from prompt libraries, which are usually static text.
The Candidate/Maintainer split solves a real governance problem: multi-agent collaboration without surrendering quality control to every model that touches the hub.
A cross-agent Skill protocol directly pushes back against the vendor lock-in emerging as each AI coding tool builds its own proprietary skill format and ecosystem.
The core tension is whether capturing AI debugging sessions as reusable skills pays off or just bloats context. One side argues that skill accumulation quickly becomes a disaster because every skill description consumes context, and recall accuracy rarely justifies the cost in real-world, environment-dependent problems. The counterpoint acknowledges the risk but reframes the problem as one of curation — recall, context control, and ruthless skill retirement — rather than raw accumulation. A separate concern notes that agents may soon absorb this functionality natively, making the tool redundant; the response shifts the value proposition to user-owned, cross-agent portability rather than competing with built-in features.
Consider one issue: context and recall accuracy. Most of the time it's not that people don't want to do these things, but that the cost outweighs the benefit. The majority of problems depend on the scenario and environment. And once you have too many skills, they bloat — many skill descriptions become chaotic. With dozens of skills, it turns into a disaster. Skill descriptions are injected into the context, and that comes at a cost. I had this same idea a long time ago, but later abandoned it after developing it. There's still a saying that rings true: "For an Agent, what you deliberately choose not to do is more important than what you do."
This point is definitely worth considering. I also agree that more skills is not always better. What matters more down the line may not be "how much you accumulate," but how to handle recall, context control, and skill retirement — even injecting none when they aren't needed. "For an Agent, not doing something is more important than doing something" is very insightful. Thanks for sharing.