Make applied skills visible in collapsed work activity

[OrlovAlexei]

Problem

T3 collapses a turn's tool activity into one line, e.g. Ran 3 commands and used 2 tools. A skill counts as one of those tools, so its name is only visible after expanding the group. For a lot of turns, "did it actually apply the skill?" is the one thing worth confirming, and confirming it costs an expand every time.

The signal is already in the stream: Claude and OpenCode send an explicit skill tool call, Codex loads a skill by reading its SKILL.md (and its own TUI labels that read with the skill name), Antigravity flags the read. T3 flattens all of it into a generic tool count.

Proposal

Treat an applied skill as its own kind of activity, not one more tool call:
normalize each provider's signal into one field on the activity payload, give it its own row label and icon, and name applied skills in the collapsed summary outside the tool count — Ran 1 command, used 1 tool, and Skills: first-skill-name, second-skill-name.

Never inferred from the assistant's prose; per-provider decision, including "no usable signal here" where that is the honest answer.

The open question

For providers without an explicit skill tool, the only signal is the read of SKILL.md. Codex's docs call loading that file the activation echanism — but reading it to review or edit it looks identical, so counting it will sometimes report a skill that was never applied. Three options, and I'd rather have a maintainer's call than guess:

1. Count the read, matching what Codex's TUI already shows.
2. Explicit tool calls only — Codex, Cursor and Grok then show nothing.
3. Match the read against the skill catalog the adapter already discovers.

Scope

Small: one extra field on an existing payload plus the existing summary line. No new event type, settings toggle, or UI surface. Not covered: $skill-name in Codex is sent as text and expanded natively, so no activity appears to label.

Related: #6756 asks to preserve the trace's expanded state. Same pain from the other side — this is about not having to expand at all to see that a skill ran.

[MarvinFS]

Moving my duplicate discussion here, as requested. I have a working implementation of a different design for Claude, and it may help with the summary question.

What it does

Each Claude Skill call gets its own row in the timeline that is always visible, the way the Claude Code CLI shows it. Since #14980 the row already says "Skill: fleet", but it still sits inside the collapsed tool group, it's dimmed and hard to miss as you don't open manually every tool call..

The CLI shows every skill load on its own:

With my change:

• Skill(name) with its arguments, and "Successfully loaded skill" under it
• "Loading skill" with the activity shimmer while it runs, "Failed to load skill" in the error color if it fails
• Other tool calls around it keep grouping as they do now
• The row stays visible when a finished turn folds

Implementation notes

• 3 files in apps/web, +190/-1. Claude only, because it sends an explicit Skill tool call, so nothing is inferred from a SKILL.md read.
• It follows the existing context compaction row: deriveMessagesTimelineRows pulls the skill entry out into a new skill row kind, using claudeSkillInvocation from @t3tools/shared/toolActivity.
• Five new tests in MessagesTimeline.logic.test.ts pass on main (6524a8d43), and four of them fail without the change. Typecheck and format are clean.
• Not checked: dark theme, narrow windows, providers other than Claude.

How it relates to this proposal

This proposal names skills in the collapsed summary line. My version gives each skill load its own row. The two can work together: the summary line names the skills, and the rows show each load and its status. A separate row costs one line per skill load. I think that is worth it, because a skill changes the instructions the agent works from.

The code was written with Claude in T3 Code. If maintainers want this direction, I can open a PR for the Claude part.