How do you handle overlapping Codex skills in larger skill catalogs?

Yes, I think we have reached the same model now.

The dynamic-catalog point is especially important. A router should not assume that the skill environment is stable. It should inventory what actually exists at task time, reason over lightweight manifests, and treat project rules as overrides rather than hard-coding one permanent hierarchy.

A minimal manifest might only need:

• owns

• does_not_own

• hands_off_to

• supports

• conflicts_with

• activation_conditions

• context_cost

Then the router could follow a few strict rules:

1. Select one primary owner whenever possible.

2. Add another skill only when it contributes a separate capability.

3. Prefer explicit ownership and handoff declarations over semantic similarity.

4. Exclude broad skills when a narrower skill fully owns the task.

5. Record why each skill was selected or rejected.

That last part may matter more than it initially appears. A small routing trace would make failures diagnosable: “CI skill selected because the task concerns a failing Actions check; broad GitHub skill rejected because repository administration was not required.”

The difficult remaining case is probably incomplete or inaccurate manifests. The router still needs a conservative fallback when no skill clearly claims ownership, or when two skills claim it equally. But even then, it would be resolving a small metadata conflict rather than interpreting several large instruction documents.

That seems substantially more maintainable than either merging everything or relying on a static priority list.

It sounds like you’re going to have to do a lot of decision-making, but that’s why I suggest using ChatGPT in the loop. It’s way better at marking what decisions need to be met still.