feat(server): show Codex display names for Claude skills

[bompus]

Problem

A skill installed for both Codex and Claude Code shows a different label in the $ picker depending on the provider. Codex reports interface.display_name from the skill's agents/openai.yaml ("HR: Handoff"). The Claude driver reports only the directory name, so the composer title-cases it ("Hr Handoff"). Claude Code itself has no display-name field and requires a lowercase name, so the skill cannot carry the label in its front matter.

Change

discoverClaudeSkills now also reads agents/openai.yaml beside each SKILL.md and reports interface.display_name as the skill's displayName. It ignores the file when it is missing, unreadable or malformed YAML, has no interface.display_name string, or when the trimmed value is empty or equals the skill name. Discovery roots, ordering, invocation and settings are unchanged. Server only; the picker already uses provider-supplied display names (the Cursor driver sets one from front matter). Per adapter: Claude changes here; Cursor scans the same .claude/skills folder but labels from the front-matter name, so it is unchanged and still shows the title-cased name; Codex already reports the label itself.

Scope and approval

I opened discussion #17482 with this proposal and have no maintainer reply, so there is no approval to link. I am submitting it anyway as a small, additive change: one optional file read per discovered skill inside the existing scan, no new setting, no change to how skills are invoked. If you judge it needs prior approval or a different direction, closing it is fine.

Related open PRs touch the same file (#15662, #17513) for other reasons; neither reads agents/openai.yaml or sets a label from it, so I expect at most a textual conflict.

Verification

• vp test run src/provider/Drivers/ClaudeSkills.test.ts in apps/server: 22 passed. The new test covers a declared name ("HR: Handoff"), a value equal to the skill name, a blank value, a non-string value, malformed YAML, a document that is a scalar, a file without interface, an openai.yaml that is a directory, and a skill with no agents/openai.yaml.
• vp fmt --check and vp lint on the two changed files: clean.
• vp run typecheck in apps/server reports one error, in src/mcp/McpHttpServer.ts (allowSessionTermination), a file this change does not touch.
• Not checked: the label in a running T3 build's picker, Windows paths, and Codex's own reader against the same fixture files.

Claude Fable 5.1, Claude Opus 5.5 and Claude Sonnet 5.5, in Claude Code.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

• Configuration used: Path: .coderabbit.config.ts
• Review profile: CHILL
• Plan: Advanced
• Run ID: c534f8ac-4d68-4a88-b58d-8fdc23bd9b2b

---

📥 Commits

Reviewing files that changed from the base of the PR and between 0e7abea and 75f8239.

---

📒 Files selected for processing (2)

• apps/server/src/provider/Drivers/ClaudeSkills.test.ts
• apps/server/src/provider/Drivers/ClaudeSkills.ts

---

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 9 remain after this review.

---

---

📝 Walkthrough

Walkthrough

Skill discovery now reads Codex agents/openai.yaml metadata and adds a valid, distinct interface.display_name to the skill record. Tests cover valid, missing, malformed, blank, non-string, and directory-name-matching values.

Changes

Codex skill display names

Layer / File(s)	Summary
Parse and expose display names apps/server/src/provider/Drivers/ClaudeSkills.ts, apps/server/src/provider/Drivers/ClaudeSkills.test.ts	Discovery reads agents/openai.yaml and parses a nonblank interface.display_name. It adds the name only when it differs from the skill name. Tests cover valid and invalid metadata.

Priority: ⬇️ Low

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Feature

Suggested reviewers: juliusmarminge

---

Merge Risk: ⚪ Minimal · up to 75f82

No merge-blocking issue was identified in the Claude skill display-name change.

Pre-merge checks | 3 | 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Description check		The description explains the problem, implementation, scope, verification results, known limitations, and agent usage. However, the required scope and approval information is not satisfied because it …	Obtain explicit maintainer approval for the proposed direction and link the approval comment, or explain why this change is an obvious focused fix that qualifies for the repository's approval exemption.

✅ Passed checks (3 passed)

Check name	Status	Explanation
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.
Title check		The title clearly and concisely describes the main change: exposing Codex display names for Claude skills.

---

Full details: Description check

Explanation

The description explains the problem, implementation, scope, verification results, known limitations, and agent usage. However, the required scope and approval information is not satisfied because it cites a discussion without maintainer approval and does not establish that this change qualifies for the approval exemption.

---

• Fix all pre-merge checks with AI

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create a new PR

---

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

---

_{Comment @coderabbitai help to get the list of available commands.}

[juliusmarminge]

Note

This comment is posted by Julius' dot

The inconsistent skill labels are a useful report, but this proposal needs prior direction approval. discoverClaudeSkills now adopts Codex's agents/openai.yaml metadata as a new display-name source for Claude, whose own format has no display-name field. That adds cross-provider metadata behavior rather than repairing a broken supported field or configuring an existing Claude display-name option. The PR explicitly says there is no maintainer approval, and #17482 currently has no replies.

Under prior approval, intentional product behavior changes outside the focused exceptions need explicit approval of direction and scope. Closing this submission on that basis. Please get that decision in #17482 and link the approval when requesting reconsideration.