💭 Looking at the diff in ChatComposer.tsx, I want to check what item.provider actually represents—whether it's a driver kind or a provider id. The mobile version passes the driver from selectedProviderStatus, so if web's item.provider isn't a driver kind, the driver === "claudeAgent" check would never match, creating a mismatch between web and mobile behavior.

1. git_tools — item.provider

2. git_tools — formatProviderSkillInvocation|formatProviderSkillDisplayName

💭 I need to check line 2057 in ChatComposer.tsx to understand where item.provider originates from.

3. browse_code — apps/web/src/components/chat/ChatComposer.tsx

4. browse_code — apps/web/src/components/chat/ChatComposer.tsx

💭 I need to check what selectedProvider actually is - likely a provider id like "claude" or "codex" rather than the driver kind, so I should verify that.

5. git_tools — selectedProvider(\b|[^S])

6. browse_code — packages/client-runtime/src/providerSkills.ts

💭 Confirmed the type is correct for web. Now I want to check whether other components like ComposerPromptEditor or ComposerCommandMenu also insert skill invocations, so I should search for other call sites that insert the skill name syntax. Also, ComposerPromptEditor may parse $name tokens as skill chips for rendering. If skill invocations are now inserted with /name for Claude instead, that could break the chip rendering/highlighting in web that mobile plain-text doesn't have. I want to check the token parsing logic there and in SkillInlineText.tsx to see how skill segments are recognized.

7. git_tools — skill

8. browse_code — packages/shared/src/composerTrigger*

💭 I'm noticing that the web composer parses plain text into skill chip nodes when it sees $name segments, so switching to /name for Claude means that chip rendering would disappear and it'd just show as plain text. This seems like an intentional tradeoff since the docs specify both menus should insert /name for Claude, but I want to confirm it's not an unintended regression. Looking closer at how the slash trigger detection works, skill items in the slash menu seem to only appear when the cursor is at the very start of the prompt, which affects when /name gets inserted versus $name. I'm now digging into whether there's a genuine parsing bug tied to the PR title around fixing skill invocation parsing. I'm also comparing selectedProviderStatus?.driver on mobile versus selectedProvider/selectedProviderStatus on web to see if they're actually the same underlying value or if there's a subtle mismatch in how driver kind gets resolved between platforms. I'm also considering whether other web insertion paths might still reference the old skill format — like mobile-web composer, tab completion, or the command menu — so I should search for those patterns to be sure nothing else got missed.

9. git_tools — $${

10. browse_code — packages/shared/src/composerTrigger.ts

💭 I'm noting that the web ChatComposer's skill chip replacement inserts "/plugin:clarify " even mid-sentence, like "Please $clar" becoming "Please /plugin:clarify " — which seems odd since slash commands normally need to be at the start of a line in Claude Code, but the diff's test explicitly asserts this behavior as intended. Beyond the slash-command positioning concern, I'm also considering the Lexical editor's chip rendering: since $name parses into a skill chip node but /name doesn't get parsed the same way, this could cause the skill chip to no longer render visually for Claude-inserted text, creating an inconsistency with how the menu displays and decorates skill references. I'm also checking whether item.provider is set consistently across the different insertion branches (slash-trigger vs skill-trigger) and confirming this matches the shared type definition, plus tracing whether other insertion paths like keyboard-driven autocomplete or the command menu's onSelect handler funnel through the same logic. Docs say both menus insert /name for Claude, and I'm verifying that's true across web's provider-slash path and the skill-trigger path, while noting the display-side SkillInlineText component (unchanged) renders things differently as $name. I'm also checking if submit-time logic treats leading-slash messages specially, since parseStandaloneComposerSlashCommand only handles /plan and /default — which suggests the actual bug might be that the web composer's inserted /name text from a skill chip isn't recognized by anything downstream, breaking the chip/parsing behavior. Now I need to trace how the composer's value string gets parsed back into segments to confirm skill segments should come from $ rather than /, so I'm locating the parse function used by the composer prompt setter.

11. browse_code — apps/web/src/components/ComposerPromptEditor.tsx

12. git_tools — type ComposerCommandItem

💭 I'm checking whether the types line up, and now I'm digging into a real potential issue with the web composer's skill chip rendering in the Lexical editor, tracing how the chip node's text content and the prompt application logic might diverge from the mobile path.

13. git_tools — "skill"

💭 I notice web has its own duplicate composer-logic module with its own trigger detection, while the new test uses the shared version instead. I'm also noting that the web composer filters skill items to only show at prompt start for slash triggers, but allows $ skill triggers anywhere, and that typing $name renders as a skill chip component. After this change, selecting a skill from the $ menu now inserts /name instead, which won't render as a chip — just plain text. That's a real regression since Claude only executes slash commands at message start, so a mid-sentence $clar selection now produces inert plain text with no chip and no invocation, which the test itself seems to confirm. I want to check whether this counts as an in-scope UI consistency issue tied to the specific changed line, and I should verify by reading through composer-editor-mentions.ts to see how skill token matching actually works around whitespace and position requirements.

14. browse_code — apps/web/src/composer-editor-mentions.ts

💭 Confirmed the skill chips only render from $-prefixed tokens, so inserting /name for Claude loses the chip — likely an intentional side effect of the PR's design rather than a bug. I want to check whether there's a subtler issue in the web app's applyPromptReplacement function instead. I'm now checking whether the collapsed-text length assumptions hold for /name insertion versus $name chips, and whether the slash trigger detection differs between the shared composerTrigger module and web's own detectComposerTrigger in composer-logic.ts — since the new test imports from the shared version, a divergence there could be the real bug. I'm also weighing the mobile branch's use of selectedProviderStatus?.driver — if that's actually an instance id rather than the provider driver kind, it would silently fail to produce the expected "/" prefix, though that's outside the scope of this review. Then I want to double-check whether the web code's provider comparison against "claudeAgent" could be affected by type widening if ProviderDriverKind is a branded type, so I'm going to look at how it's defined in contracts.

15. git_tools — ProviderDriverKind =

💭 Comparing the branded ProviderDriverKind against the "claudeAgent" literal should work fine at runtime and typecheck fine too, since the literal is assignable to the underlying string type. Now I need to figure out which finding actually applies here. Tracing through the skill trigger detection logic, slash commands only fire at the start of a line, so inserting one mid-message won't re-trigger anything—that path seems safe. I'm starting to suspect the planted issue might live outside the web app's scope, or perhaps there genuinely isn't anything actionable within these bounds, but I want to check one more angle in the composer code before concluding that. Actually, the changed line means Claude skill insertions render as plain text rather than the skill chip other providers get, even though the menu still labels it /skill:Name—that's a real visual inconsistency for what's likely the biggest provider's users, since the chip normally carries the display name, tooltip, and atomic deletion behavior. This looks like a genuine, user-visible regression worth flagging rather than a false positive, since the docs update only mentions the insertion text change but not the loss of chip rendering.

16. browse_code — apps/web/src/components/chat/SkillInlineText.tsx

💭 This confirms it: both the composer chip and transcript skill chip only recognize $name, so for Claude specifically, switching to /name would silently break the chip presentation in both composer and transcript, falling back to plain text like /plugin:clarify. The smallest fix would be teaching the web chip tokenizer/renderer to also accept the provider's slash-invocation form, or otherwise preserving the chip for Claude specifically. This does look like a legitimate regression tied directly to the changed line at ChatComposer.tsx:2057, and it's web-specific since mobile just uses plain text anyway — that likely explains why the include patterns only target web files. I want to double-check the composer's inline token collector to be sure there's no existing slash-handling I'm missing.

17. browse_code — apps/web/src/composer-editor-mentions.ts

18. git_tools — collectComposerInlineTokens

19. browse_code — packages/shared/src/composerInlineTokens.ts

💭 I've confirmed skill chips use dollar-sign-only tokens with a shared tokenizer. I'm now checking whether inserting plain text for a skill reference would interact with the composer's atomic chip behavior, but this doesn't seem relevant to the issue at hand. I'll flag this as an inline comment on the web composer file describing the chip regression, noting mobile is unaffected. The smallest fix options are either extending the token regex to recognize slash-based skill invocations (risky, would chip other slash commands too) or matching against known skill names in the metadata map so only actual skills get chipped, which seems like the more targeted approach.

20. git_tools — renderSkillInlineMarkdownChildren|SkillInlineText

💭 This does look like an intended consequence of the change rather than a bug, so I'll report it as a single finding pointing to ChatComposer.tsx line 2057, where the diff shows the chip insertion behavior on the right side. I'm also noting that the Lexical chip renders as an atomic collapsed unit, which could introduce another web-specific quirk worth checking. Now I'm drafting the actual comment: for claudeAgent, the insertion produces /name, but the web composer's chip pipeline only recognizes $name tokens through collectComposerInlineTokens, splitPromptIntoComposerSegments, and ComposerSkillNode, and the transcript's SkillInlineText uses the same $ regex. Since Claude is the default provider for most users, selecting a skill from either menu fails to produce a chip in the composer — losing the display name, tooltip, and atomic delete/cursor behavior — and the sent message renders as plain text instead of a chip, even though the same flow still works correctly on Codex and Cursor, while mobile is unaffected since it's plain text anyway. I'm now formulating the smallest possible fix, which would involve extending the web skill token recognizers to also accept the other token format. I want to make sure I'm being precise here — I should double check whether extending the recognizer risks accidentally chipping every slash command rather than just skills, so I should gate it specifically to known skill names. I also want to confirm my claim that the $ trigger previously produced a chip on Claude when followed by a space, which it does. With that confirmed, I'm marking this check as a failure since a finding was identified, and I'm ready to post the review with this inline comment.

21. modify_pr — Submitted review with 1 inline comment