Feature Request: Add showSkills / showMcp display elements

[ancespio]

Summary

Add skills and mcp as displayable HUD elements (alongside existing tools, agents, todos), so users can see at a glance which Skills and MCP servers are active in the current session.

Motivation

Claude Code now supports both Skills (installable via npx skills add, including 19+ from Feishu CLI) and MCP servers. Currently there is no visual indicator in the HUD when these are in use — the only notification is a <system-reminder> block that appears inline in the conversation, which is easily missed during long sessions.

The HudElement type already supports 9 elements (project, context, usage, promptCache, memory, environment, tools, agents, todos). Extending this to include skills and mcp would give users better situational awareness.

Proposed Design

Two new elements in HudElement:

| 'skills' | 'mcp'

Corresponding display toggles:

"display": {
  "showSkills": false,   // default off, consistent with other activity toggles
  "showMcp": false       // default off
}

Example rendering (Expanded layout):

[Opus | Pro] │ my-project git:(main*)
Context ████░░░░░ 45% │ Usage ██░░░░░░░░ 25%
◐ skill: feishu-docs | ◐ skill: code-review
◐ mcp: linear (3 tools) | ◐ mcp: slack

Example rendering (Compact layout):

[Opus | Pro] ████░░░░░ 45% | my-project | ◐ skill: feishu-docs | ◐ mcp: linear

Related

Issue #516 discusses simplifying MCP call counts — this is complementary. That issue is about how to count MCP interactions; this one is about surfacing skill/MCP presence in the status line at all.

Alternatives Considered

• Relying on existing showTools to reflect MCP tool count (works but doesn't distinguish native vs MCP tools vs skills)
• /skills command for manual inspection (requires user to proactively check)

[jarrodwatts]

Thanks, this is a useful backlog item. I labelled it as an enhancement.

The main design point is the data source. MCP server counts already come from config, while active skill detection needs a reliable source that does not depend on brittle parsing of inline reminders. A good PR should keep both displays default-off, avoid duplicating the existing tools/environment lines, and include transcript/config fixtures showing how skills and MCPs are detected.