{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreifui67g7a7htvzcrg3cvct3k5gso7oqvesr54ystc7463vmhbhiwu",
    "uri": "at://did:plc:lk3jfj3zq4k4wxnk474axylu/app.bsky.feed.post/3mo7miszbl6x2"
  },
  "path": "/t/how-do-you-handle-overlapping-codex-skills-in-larger-skill-catalogs/1383626#post_9",
  "publishedAt": "2026-06-14T00:27:30.000Z",
  "site": "https://community.openai.com",
  "textContent": "Yes, that is a really good formulation. I think the routing trace part is especially important, because it turns the router from a black box into something inspectable.\n\nIf the system can say “I selected this skill because it owns the task, rejected this broader skill because a narrower one fully covers it, and added this support skill only for verification,” then debugging bad routing decisions becomes much easier. Without that trace, it is very hard to know whether the router made a good decision or just guessed based on similar wording.\n\nThe incomplete-manifest case is probably the hardest part, as you said. I would rather have the router be conservative there: if no skill clearly owns the task, either use no skill, ask for clarification, or fall back to a very small general workflow instead of pulling in everything that sounds related.\n\nThat is also why I think the dynamic catalog point matters so much. The router should not assume a fixed skill universe. It should be able to inspect what exists right now, reason over lightweight metadata, and then apply project-level overrides when needed.\n\nMy current “Skill Orchestrator” experiment is basically a rough userland prototype of this idea without native manifests. It tries to infer ownership from descriptions, naming, and known overlap patterns, but I agree that the cleaner long-term model would be explicit metadata like `owns`, `does_not_own`, `hands_off_to`, `supports`, and `conflicts_with`.\n\nSo maybe the useful prototype path is:\n\nFirst, use an instruction-only router to test whether task-time selection actually improves larger skill catalogs.\n\nThen, if the pattern proves useful, move the fragile prose-based parts into explicit skill manifests and routing traces.\n\nThat feels much more maintainable than one giant merged instruction document, while still avoiding the “load every plausible skill” problem",
  "title": "How do you handle overlapping Codex skills in larger skill catalogs?"
}