Over the last several months I’ve been building a few open-source tools around coding agents. They started separately.
One solved the problem of repository instructions. Another dealt with reusable agent skills. Then orchestration became annoying. And eventually I wanted the context about me to stop living separately inside every AI product I use.
This week I updated all four projects and, looking at them together, realized that they now form something reasonably coherent. Not another agent framework. More like a small operating layer around the agents you already use.
The stack is:
AGENTS.md Generator → ABVX Agent Skills → SET → ID
Four projects. Four different jobs. And importantly, you don’t have to use all four.
1. AGENTS.md Generator: Teach the Agent the Repository
The first problem is basic. Every coding agent arrives at your repository slightly stupid. It doesn’t know how you build the project. Which commands are real.
How tests run. What architectural constraints matter. Which files shouldn’t be touched. And we repeatedly waste tokens explaining the same things.
agentsgen turns repository knowledge into a maintained contract for coding agents. It generates AGENTS.md, RUNBOOK.md and machine-readable context, preserves handwritten instructions, detects stale command references and can guard the contract in CI.
If somebody removes npm test from package.json while AGENTS.md still tells the agent to run it, the check fails.
Simple idea. Surprisingly useful.
2. ABVX Agent Skills: Teach the Agent How to Work
Repository context answers: Where am I and what are the rules here?
Skills answer: How should I perform this kind of work?
The project is a collection of small, inspectable skills for Codex, Claude Code, Cursor and other coding agents. There are workflows for minimal diffs, evidence-driven debugging, token-efficient execution, context degradation, architecture review, release verification, reversible tasks, handoffs and other things I repeatedly want agents to do in a predictable way.
I deliberately don’t want this to become another dump of giant prompts.
A useful skill should change behavior, have a narrow trigger and include some way to verify whether the job was actually done.
The latest release also adds measured demos. Not “our prompt improves productivity by 847%”, but small reproducible comparisons where there is actual evidence to inspect.
You can install the package or individual skills:
pip install abvx-agent-skills
abvx-skills installor:
gh skill install markoblogo/abvx-agent-skills minimal-diff-builder --agent codex --scope user3. SET: Orchestrate the Workflow
Once agents have repo context and reusable skills, another problem appears: when should all of this run?
SET is the thin orchestration layer. It can run agentsgen through GitHub Actions, compose workflow presets and export plans for review before anything is applied.
That last part matters to me. I don’t particularly want another autonomous system silently rewriting repositories because somebody wrote “AI-native” on a slide.
SET is deliberately review-first. It generates proposals and artifacts. You inspect them. Then you decide what becomes real. And for the basic repo-doc workflow, it doesn’t need an AI runtime or API key at all.
4. ID: Teach the Agent Who It Works For
The repository has context. The workflow has rules. The agent has skills. But there is another context we keep rebuilding: the human.
How detailed should answers be? What trade-offs do I usually prefer? What does a good result mean to me? Which information can be shared? Which should remain local?
ID stores that as owner-controlled, reviewable files instead of leaving it trapped inside one vendor’s memory system. It produces portable context exports with explicit privacy policies and semantic diffs, so you can see what changed before handing context to another tool.
This is particularly important to me because I use several different agents.
I don’t want my working preferences to belong to any of them.
Why Four Projects?
I could obviously put everything into one giant repository. Then we’d have an Agent Platform™. There would probably be a dashboard. Eventually Kubernetes. I’d rather not. The boundaries are useful.
agentsgen owns repository truth.
Agent Skills owns reusable behavior.
SET owns orchestration.
ID owns human context.
Use one. Use two. Use all four. Replace any layer with something better. That’s the point.
The agents themselves are getting better very quickly. I don’t think the interesting problem is building another wrapper around Claude or Codex.
The interesting problem is building the infrastructure that survives when the underlying model changes. Context. Procedures. Permissions. Verification. Memory. Workflow. Those are much less model-specific.
What the Whole Stack Gives You
Put everything together and a coding agent can enter a repository knowing: what the project is, how to build and test it, how you expect particular kinds of work to be performed, which workflow is currently allowed, what evidence is required before claiming completion, and what the human owner actually prefers.
Without putting all of that into one 40,000-token system prompt.
That’s increasingly how I think agent infrastructure should work: small permanent context, more context loaded on demand, reusable procedural skills, deterministic tooling underneath, and explicit verification before “done.”
Nothing particularly magical. Mostly plumbing. Good plumbing is underrated.
Everything Is Open Source
All four projects are public and actively maintained:
You can use them independently, steal the ideas, open issues, break things, send PRs, or just inspect how I’ve approached the problem.
And yes, if something is useful, a GitHub star remains an extremely efficient form of developer emotional support.
Practical follow-up: my AGENTS.md Generator worked example demonstrates stale-command checks and safe updates; the workflow and orchestration guide explains how I separate repository context, reusable skills and review.