APX Skills Are the Adoption Layer for APC
APC is the project contract. APX is the runtime layer that makes that contract usable today. The most practical bridge between both is APX skill installation.
That sounds small, but it solves a real adoption problem.
A protocol can be clean and still be ignored. If a tool does not know how to read .apc/, it will keep inventing its own local habits. One runtime may look at AGENTS.md. Another may ignore it. A third may store sessions in a vendor-specific cache and never touch the repo at all. APC only wins when the runtime learns to treat the repository contract as the source of truth.
That is where APX matters.
APX is not trying to replace APC. It is the layer that teaches compatible runtimes how to use APC correctly. The APX docs are explicit: it installs APC-aware skills into runtimes like Claude Code and Codex, so they know how to read .apc/, which agents exist, and which skills apply. In other words, APX turns a file convention into behavior.
Why skills matter
A skill is more than a prompt snippet. In this stack, it is the smallest useful unit of operational knowledge.
Without skills, a runtime has to rediscover the project on every turn. It may still work, but it will work inconsistently. With skills, the runtime gets a stable local rule set:
- read the root contract first
- respect the agent layout in
.apc/ - keep runtime state outside the repo
- treat curated memory as project knowledge, not transcript dumps
That makes APC portable in practice, not just in theory.
A good test is simple: if a new compatible tool can open the repo and immediately understand where project rules live, where durable memory lives, and where raw runtime state should stay, APC is doing its job. APX skills are what make that possible before every vendor ships native APC support.
The adoption loop
The flow is straightforward:
- The repo carries APC files such as
AGENTS.md,.apc/project.json, and curated agent memory. - APX installs skills into the local runtime.
- The runtime reads the APC contract the same way every time.
- Runtime state stays in
~/.apx/, not inside the repo. - The project stays portable across tools and machines.
That loop matters because it keeps the repo and the runtime in their proper roles.
APC says what the project is.
APX says how to work with it today.
Concrete example
Imagine a repo with one agent for reviews and one for implementation. The APC side can define the agent files and memory. The APX side can install the skills that teach a compatible runtime to:
- discover the project root
- load the correct agent context
- use local runtime storage for sessions and messages
- avoid treating transient output as committed project knowledge
The result is not just nicer ergonomics. It is less drift.
If the runtime knows the contract, the same repo behaves the same way across tools. That is a stronger guarantee than hoping every tool author independently recreates the same folder rules.
The deeper reason
APC is not a dashboard feature. It is a protocol for project meaning.
APX is not just a CLI wrapper. It is the adoption layer that makes the protocol real on day one.
That is why the two projects belong together but do not overlap:
- APC stays durable, portable, and repo-owned.
- APX stays local, operational, and runtime-owned.
- Skills are the glue that lets the runtime respect the contract.
If you want the short version: APC defines the contract, APX teaches the runtime to obey it.
That is the useful path from spec to daily use.
Top comments (0)