Support project-level skills discovery from repository workspace

Open 💬 2 comments Opened May 9, 2026 by urolzeen
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What variant of Codex are you using?

App, IDE Extension, CLI

What feature would you like to see?

Codex currently discovers skills mainly from user-level ~/.codex/skills, but project-specific skills are not automatically loaded from the repository workspace.

This makes team workflows fragile:

  • Skills are easy to miss after reinstalling the OS or switching machines.
  • Project-specific AI workflows cannot travel with the repo.
  • Different developers may have different local skills installed.
  • AGENTS.md and project rules are workspace-aware, but skills are not, which feels inconsistent.

Expected behavior:

  • Codex should automatically discover workspace-level skills from a conventional repo path such as:
  • <repo>/.codex/skills/<skill-name>/SKILL.md
  • or <repo>/.agent/skills/<skill-name>/SKILL.md
  • The available skills list should show where each skill comes from:
  • system
  • user
  • workspace/project
  • plugin

Security:

  • Since project-level skills come from the repository, Codex could require a one-time workspace trust confirmation before loading them, similar to VS Code Workspace Trust.
  • If two skills have the same name, Codex should define a clear precedence rule or report the conflict explicitly.

Why this matters:
This would make Codex much easier to use in team repositories and portable development environments. Project-specific AI workflows could be versioned together with the codebase instead of requiring every developer to manually copy skills into ~/.codex/skills.

Additional information

_No response_

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 3 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #21524

Powered by Codex Action

Tomchen070814 · 1 month ago

Hi @urolzeen — your points about project portability, inconsistent local Skill installations, source visibility, and duplicate conflicts are exactly the problems I’m researching.

I’m building Bitcase, a free public Alpha that collects external Skills, records their sources, checks SKILL.md files, detects duplicate content, and assembles a project-specific Skill Stack that can be copied into Codex.

Bitcase does not yet write Skills into a repository-level .codex/skills directory or implement workspace trust. One question I’m trying to answer is whether a project-specific Stack and source manifest are useful first steps, or whether repository-level installation must exist before the product creates real value.

Would you be willing to test it with one real project and tell me where that model fails?

https://bitcase-skill-library.tomcjq070814.chatgpt.site/?utm_source=github&utm_campaign=alpha_research&utm_content=urolzeen_21907

No account or private repository is required.