[Feature]: Discover repo-local .agents/skills (Agent Skills standard) provider-agnostically, not per provider

[RoshanMhatre]

Before submitting

• I searched existing issues and did not find a duplicate.
• I am describing a concrete problem or use case, not just a vague idea.

Area

apps/server

Problem or use case

.agents/skills is the cross-tool Agent Skills standard directory — the same repo-local skill works in Claude Code, Codex, and other harnesses. But in T3 Code, whether a repo-local skill shows up in the composer picker depends entirely on per-provider plumbing, and today every path is broken or missing in a different way:

• Claude: T3's own scanner misses the .agents/skills root entirely ([Bug]: Skill discovery never scans repo-local .agents/skills (Agent Skills standard dir) #5487, fix in fix(claude): discover repo-local .agents/skills in skill discovery #5488), and the probe cwd is wrong in packaged builds ([Bug]: Claude project-level skills absent from $ picker in packaged desktop builds #4544/fix: discover project-level Claude skills for the picker in the desktop app #4546).
• Codex: discovery is delegated to codex app-server, which does scan .agents/skills, but T3 asks with the server-process cwd ([Bug]: Repo-local Codex skills do not appear in T3 Code $ skill picker #3040, fix in fix(codex): discover project skills from workspace #5335).
• Grok / OpenCode: no skills plumbing at all — pickers are empty ([Bug]: Grok provider: skills/slash commands empty; ACP crash on skills-reload (BigInt RequestId) #4109, fix in fix(providers): show Grok and OpenCode skills/slash commands in the picker #5131).
• Any future provider: repeats this from scratch.

The result: the one skills directory designed to be harness-portable is the one users cannot rely on in T3 Code, and each provider needs (and has needed) its own bug-and-fix cycle for the same user-visible behavior.

Proposed solution

Discover workspace .agents/skills once, provider-agnostically, in T3-owned code, and merge it into every provider's picker inventory:

• One scanner (the existing discoverClaudeSkills shape in apps/server/src/provider/Drivers/ClaudeSkills.ts generalizes: */SKILL.md, YAML frontmatter name/description, best-effort skips) run against the active project cwd.
• Merge results into each provider snapshot's skills with provider-reported entries winning dedup by name — so when a runtime (like Codex app-server) already reports a .agents skill with richer metadata, nothing double-lists, and the generic entry is only a fallback.
• Provider-specific roots stay provider-owned (.claude/skills, provider config dirs, ACP/SDK catalogs); only the shared standard directory is lifted to the shared layer.

This composes with (not replaces) the project-cwd work in #3040/#5335/#4546 — the generic scan needs the project cwd at the same seam those PRs fix.

Why this matters

Repo-local skills are how teams ship shared workflows with their codebase, and .agents/skills is the location the ecosystem standardized precisely so it would work in every harness. Fixing it once in T3-owned code means every current provider behaves consistently and every future provider gets it for free, instead of five drivers each re-growing the same bug.

Smallest useful scope

Scan <project cwd>/.agents/skills in one shared helper and append the results (deduped by name, provider entries win) to skills in the provider snapshot for all providers. No settings UI, no user-level generic roots, no skill management — just the picker showing what's on disk.

Alternatives considered

• Per-provider fixes only (status quo): fix(claude): discover repo-local .agents/skills in skill discovery #5488 + fix(codex): discover project skills from workspace #5335 + fix: discover project-level Claude skills for the picker in the desktop app #4546 + fix(providers): show Grok and OpenCode skills/slash commands in the picker #5131 together cover today's four providers, but each future provider re-implements discovery, and providers whose runtime doesn't report repo skills stay dark.
• Relying on each provider runtime to report .agents/skills: works where runtimes cooperate (Codex), impossible where the runtime reports nothing (current Grok/ACP path), and leaves T3's picker at the mercy of each CLI's discovery quirks.

Happy to PR this if the direction sounds right — I have a working branch. Related: my #5487/#5488 for the Claude-specific root.

[bobleer]

One edge case I'd pin down before merging the inventories: “provider-reported wins by name” can accidentally make a user-level skill beat the repo skill. A provider result for ~/.agents/skills/deploy and T3's scan of <repo>/.agents/skills/deploy aren't two descriptions of the same item just because the frontmatter names match.

In BitFun we keep each discovery result as a candidate with a stable (scope, source slot, directory) key, then resolve precedence separately; the provider/source label is metadata, not precedence (the candidate/resolution split is here). The minimal T3 version could merge metadata only when canonical paths match, then use project-over-user for actual name collisions. That keeps the shared scan provider-agnostic without letting whichever provider reported first silently choose the winner.

[Hahaknight]

Data point from the skills-pack author side (we ship a 15-skill pack that installs across Claude Code / Codex / Gemini CLI / Goose / Crush / Qwen Code / OpenCode — verified installs on each):

Where installs actually land today (observed, not documented anywhere consistently):

• npx skills add owner/repo (default) → user level, e.g. ~/.claude/skills/
• npx skills add owner/repo --agent opencode → repo-local <cwd>/.agents/skills/ — even from a user's home dir, which surprises people

So the user-level vs repo-local split @bobleer is worried about isn't hypothetical — the dominant installer already produces both locations, and users genuinely can't tell where a skill went. When a skill doesn't show up in the composer, the two failure modes users report to us are (1) it installed repo-local but the tool only surfaces user-level, (2) name collision resolved differently per provider.

Concrete suggestion for this proposal: when surfacing the inventory, annotate origin (repo-local / user-level / provider-native) rather than merging silently — that single bit would have solved essentially every "where did my skill go" report we've gotten. Repo-local winning over user-level on name collision is the least-surprise ordering from where we sit.

(Context: our pack is Hahaknight/claude-skills-pro, MIT free tier — mention only as the source of the install observations above.)