fix(server): discover Claude commands and skills per workspace

[RaitP1]

What Changed

• The composer now asks the server which commands and skills exist in the workspace it is about to send a turn to, instead of reading the single global list that ships with the provider snapshot.
• The client sends ids, never a path. The server picks the directory itself: the thread's worktree when it has one, otherwise the project folder.
• For Claude, the server runs the same capability probe and skill scan in that directory and keeps the answer for five minutes per workspace. A provider with nothing project-specific to report still answers from the global snapshot, so nothing else changes.

composer (web / mobile)
└─ useProviderWorkspaceCapabilities() apps/{web,mobile}/src/state/queries.ts
└─ serverEnvironment.providerWorkspaceCapabilities packages/client-runtime/src/state/server.ts
└─ WS RPC "server.listProviderWorkspaceCapabilities" packages/contracts/src/rpc.ts
└─ scope check apps/server/src/auth/RpcAuthorization.ts
└─ handler: resolve the cwd apps/server/src/ws.ts
└─ ProviderRegistry.listWorkspaceCapabilities()
└─ instance.listWorkspaceCapabilities(cwd) (optional)
└─ ClaudeDriver: probe + skill scan

Why

Commands and skills that live inside a project never appear in the / and $ menus, and every project shows the same list. Typing the command still works, because the thread itself runs in the project folder. Only the menus are wrong.

Discovery asks the directory the server process started in, not the project the user has open. In the desktop app those are never the same. The answer is then cached per provider, with nothing that records which project it came from, so opening another project cannot refresh it.

Left out on purpose: other providers keep their current behavior, and a probe that fails drops its cached entry instead of leaving a menu empty for the next five minutes.

Related: #4658. #4546 proposes the skills half of this, for the $ picker only.

Checklist

• This PR is small and focused — one concern, the directory discovery reads
• I explained what changed and why
• I included before/after screenshots for any UI changes — no visual change; the menus look the same and list the open project's entries. I can add a matched pair.
• I included a video for animation/interaction changes — not applicable

Written by Claude Opus 5 in Claude Code, running inside T3 Code.

---

Note

Medium Risk
New read RPC and cwd resolution from projections affect composer discovery; Claude runs per-workspace probes with caching, but behavior falls back to snapshots for non-Claude providers and failed probes.

Overview
Workspace-scoped provider menus — Web and mobile composers no longer rely only on the global provider snapshot for / slash commands and $ skills. While those menus are open, they call useProviderWorkspaceCapabilities, which hits server.listProviderWorkspaceCapabilities with project/thread ids (no client paths).

Server resolution — The WS handler resolves cwd from the thread worktree when it belongs to the project, otherwise the project workspace root, then ProviderRegistry.listWorkspaceCapabilities. Drivers may implement listWorkspaceCapabilities(cwd); others keep snapshot lists.

Claude — ClaudeDriver probes capabilities and discovers skills in that cwd, caches per workspace (~5 minutes), and falls back to snapshot slash commands if the probe is empty.

Docs note that menus reflect the thread’s workspace folder.

^{Reviewed by Cursor Bugbot for commit 7c05f4e. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Discover Claude slash commands and skills per workspace in chat composers

• Adds a new server.listProviderWorkspaceCapabilities RPC that resolves the workspace directory from the active thread's worktree path or project root, then queries the Claude provider for workspace-scoped slash commands and skills.
• ClaudeDriver gains a listWorkspaceCapabilities(cwd) method backed by a capacity-8 cache, concurrently probing Claude capabilities and discovering skills, with fallback to the cached snapshot.
• Web (ChatComposer) and mobile (ThreadComposer) composers call the new useProviderWorkspaceCapabilities hook when a slash-command or skill trigger is active, falling back to provider snapshot data if the query is unavailable.
• Contract schemas, RPC group, client-runtime atoms, and RPC authorization scope are all updated to support the new endpoint.

^{Macroscope summarized 7c05f4e.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: b61acdbc-c0c9-4903-abb6-aa24cefd58b1

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[macroscopeapp]

Approvability

Verdict: Needs human review

This PR introduces new per-workspace discovery of Claude commands and skills, including a new RPC endpoint, client hooks, and caching logic. As a new feature that changes user-facing behavior (which commands/skills appear based on workspace), it warrants human review.

^{You can customize Macroscope's approvability policy. Learn more.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 990e75a. Configure here.}

[RaitP1]

What Changed

• The composer now asks the server which commands and skills exist in the workspace it is about to send a turn to, instead of reading the single global list that ships with the provider snapshot.
• The client sends ids, never a path. The server picks the directory itself: the thread's worktree when it has one, otherwise the project folder.
• For Claude, the server runs the same capability probe and skill scan in that directory and keeps the answer for five minutes per workspace. A provider with nothing project-specific to report still answers from the global snapshot, so nothing else changes.

composer (web / mobile)
└─ useProviderWorkspaceCapabilities() apps/{web,mobile}/src/state/queries.ts
└─ serverEnvironment.providerWorkspaceCapabilities packages/client-runtime/src/state/server.ts
└─ WS RPC "server.listProviderWorkspaceCapabilities" packages/contracts/src/rpc.ts
└─ scope check apps/server/src/auth/RpcAuthorization.ts
└─ handler: resolve the cwd apps/server/src/ws.ts
└─ ProviderRegistry.listWorkspaceCapabilities()
└─ instance.listWorkspaceCapabilities(cwd) (optional)
└─ ClaudeDriver: probe + skill scan

Why

Commands and skills that live inside a project never appear in the / and $ menus, and every project shows the same list. Typing the command still works, because the thread itself runs in the project folder. Only the menus are wrong.

Discovery asks the directory the server process started in, not the project the user has open. In the desktop app those are never the same. The answer is then cached per provider, with nothing that records which project it came from, so opening another project cannot refresh it.

Left out on purpose: other providers keep their current behavior, and a probe that fails drops its cached entry instead of leaving a menu empty for the next five minutes.

Related: #4658. #4546 proposes the skills half of this, for the $ picker only.

Checklist

• This PR is small and focused — one concern, the directory discovery reads
• I explained what changed and why
• I included before/after screenshots for any UI changes — no visual change; the menus look the same and list the open project's entries. I can add a matched pair.
• I included a video for animation/interaction changes — not applicable

Written by Claude Opus 5 in Claude Code, running inside T3 Code.

---

Note

Medium Risk
New read RPC and cwd resolution from projections affect composer discovery; Claude runs per-workspace probes with caching, but behavior falls back to snapshots for non-Claude providers and failed probes.

Overview
Workspace-scoped provider menus — Web and mobile composers no longer rely only on the global provider snapshot for / slash commands and $ skills. While those menus are open, they call useProviderWorkspaceCapabilities, which hits server.listProviderWorkspaceCapabilities with project/thread ids (no client paths).

Server resolution — The WS handler resolves cwd from the thread worktree when it belongs to the project, otherwise the project workspace root, then ProviderRegistry.listWorkspaceCapabilities. Drivers may implement listWorkspaceCapabilities(cwd); others keep snapshot lists.

Claude — ClaudeDriver probes capabilities and discovers skills in that cwd, caches per workspace (~5 minutes), and falls back to snapshot slash commands if the probe is empty.

Docs note that menus reflect the thread’s workspace folder.

^{Reviewed by Cursor Bugbot for commit 7c05f4e. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Discover Claude slash commands and skills per workspace in chat composers

• Adds a new server.listProviderWorkspaceCapabilities RPC that resolves the workspace directory from the active thread's worktree path or project root, then queries the Claude provider for workspace-scoped slash commands and skills.
• ClaudeDriver gains a listWorkspaceCapabilities(cwd) method backed by a capacity-8 cache, concurrently probing Claude capabilities and discovering skills, with fallback to the cached snapshot.
• Web (ChatComposer) and mobile (ThreadComposer) composers call the new useProviderWorkspaceCapabilities hook when a slash-command or skill trigger is active, falling back to provider snapshot data if the query is unavailable.
• Contract schemas, RPC group, client-runtime atoms, and RPC authorization scope are all updated to support the new endpoint.

^{Macroscope summarized 7c05f4e.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: b61acdbc-c0c9-4903-abb6-aa24cefd58b1

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[macroscopeapp]

Approvability

Verdict: Needs human review

This PR introduces new per-workspace discovery of Claude commands and skills, including a new RPC endpoint, client hooks, and caching logic. As a new feature that changes user-facing behavior (which commands/skills appear based on workspace), it warrants human review.

^{You can customize Macroscope's approvability policy. Learn more.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 990e75a. Configure here.}

[RaitP1]

What Changed

• The composer now asks the server which commands and skills exist in the workspace it is about to send a turn to, instead of reading the single global list that ships with the provider snapshot.
• The client sends ids, never a path. The server picks the directory itself: the thread's worktree when it has one, otherwise the project folder.
• For Claude, the server runs the same capability probe and skill scan in that directory and keeps the answer for five minutes per workspace. A provider with nothing project-specific to report still answers from the global snapshot, so nothing else changes.

composer (web / mobile)
└─ useProviderWorkspaceCapabilities() apps/{web,mobile}/src/state/queries.ts
└─ serverEnvironment.providerWorkspaceCapabilities packages/client-runtime/src/state/server.ts
└─ WS RPC "server.listProviderWorkspaceCapabilities" packages/contracts/src/rpc.ts
└─ scope check apps/server/src/auth/RpcAuthorization.ts
└─ handler: resolve the cwd apps/server/src/ws.ts
└─ ProviderRegistry.listWorkspaceCapabilities()
└─ instance.listWorkspaceCapabilities(cwd) (optional)
└─ ClaudeDriver: probe + skill scan

Why

Commands and skills that live inside a project never appear in the / and $ menus, and every project shows the same list. Typing the command still works, because the thread itself runs in the project folder. Only the menus are wrong.

Discovery asks the directory the server process started in, not the project the user has open. In the desktop app those are never the same. The answer is then cached per provider, with nothing that records which project it came from, so opening another project cannot refresh it.

Left out on purpose: other providers keep their current behavior, and a probe that fails drops its cached entry instead of leaving a menu empty for the next five minutes.

Related: #4658. #4546 proposes the skills half of this, for the $ picker only.

Checklist

• This PR is small and focused — one concern, the directory discovery reads
• I explained what changed and why
• I included before/after screenshots for any UI changes — no visual change; the menus look the same and list the open project's entries. I can add a matched pair.
• I included a video for animation/interaction changes — not applicable

Written by Claude Opus 5 in Claude Code, running inside T3 Code.

---

Note

Medium Risk
New read RPC and cwd resolution from projections affect composer discovery; Claude runs per-workspace probes with caching, but behavior falls back to snapshots for non-Claude providers and failed probes.

Overview
Workspace-scoped provider menus — Web and mobile composers no longer rely only on the global provider snapshot for / slash commands and $ skills. While those menus are open, they call useProviderWorkspaceCapabilities, which hits server.listProviderWorkspaceCapabilities with project/thread ids (no client paths).

Server resolution — The WS handler resolves cwd from the thread worktree when it belongs to the project, otherwise the project workspace root, then ProviderRegistry.listWorkspaceCapabilities. Drivers may implement listWorkspaceCapabilities(cwd); others keep snapshot lists.

Claude — ClaudeDriver probes capabilities and discovers skills in that cwd, caches per workspace (~5 minutes), and falls back to snapshot slash commands if the probe is empty.

Docs note that menus reflect the thread’s workspace folder.

^{Reviewed by Cursor Bugbot for commit 7c05f4e. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Discover Claude slash commands and skills per workspace in chat composers

• Adds a new server.listProviderWorkspaceCapabilities RPC that resolves the workspace directory from the active thread's worktree path or project root, then queries the Claude provider for workspace-scoped slash commands and skills.
• ClaudeDriver gains a listWorkspaceCapabilities(cwd) method backed by a capacity-8 cache, concurrently probing Claude capabilities and discovering skills, with fallback to the cached snapshot.
• Web (ChatComposer) and mobile (ThreadComposer) composers call the new useProviderWorkspaceCapabilities hook when a slash-command or skill trigger is active, falling back to provider snapshot data if the query is unavailable.
• Contract schemas, RPC group, client-runtime atoms, and RPC authorization scope are all updated to support the new endpoint.

^{Macroscope summarized 7c05f4e.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: b61acdbc-c0c9-4903-abb6-aa24cefd58b1

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[macroscopeapp]

Approvability

Verdict: Needs human review

This PR introduces new per-workspace discovery of Claude commands and skills, including a new RPC endpoint, client hooks, and caching logic. As a new feature that changes user-facing behavior (which commands/skills appear based on workspace), it warrants human review.

^{You can customize Macroscope's approvability policy. Learn more.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 990e75a. Configure here.}

[RaitP1]

What Changed

• The composer now asks the server which commands and skills exist in the workspace it is about to send a turn to, instead of reading the single global list that ships with the provider snapshot.
• The client sends ids, never a path. The server picks the directory itself: the thread's worktree when it has one, otherwise the project folder.
• For Claude, the server runs the same capability probe and skill scan in that directory and keeps the answer for five minutes per workspace. A provider with nothing project-specific to report still answers from the global snapshot, so nothing else changes.

composer (web / mobile)
└─ useProviderWorkspaceCapabilities() apps/{web,mobile}/src/state/queries.ts
└─ serverEnvironment.providerWorkspaceCapabilities packages/client-runtime/src/state/server.ts
└─ WS RPC "server.listProviderWorkspaceCapabilities" packages/contracts/src/rpc.ts
└─ scope check apps/server/src/auth/RpcAuthorization.ts
└─ handler: resolve the cwd apps/server/src/ws.ts
└─ ProviderRegistry.listWorkspaceCapabilities()
└─ instance.listWorkspaceCapabilities(cwd) (optional)
└─ ClaudeDriver: probe + skill scan

Why

Commands and skills that live inside a project never appear in the / and $ menus, and every project shows the same list. Typing the command still works, because the thread itself runs in the project folder. Only the menus are wrong.

Discovery asks the directory the server process started in, not the project the user has open. In the desktop app those are never the same. The answer is then cached per provider, with nothing that records which project it came from, so opening another project cannot refresh it.

Left out on purpose: other providers keep their current behavior, and a probe that fails drops its cached entry instead of leaving a menu empty for the next five minutes.

Related: #4658. #4546 proposes the skills half of this, for the $ picker only.

Checklist

• This PR is small and focused — one concern, the directory discovery reads
• I explained what changed and why
• I included before/after screenshots for any UI changes — no visual change; the menus look the same and list the open project's entries. I can add a matched pair.
• I included a video for animation/interaction changes — not applicable

Written by Claude Opus 5 in Claude Code, running inside T3 Code.

---

Note

Medium Risk
New read RPC and cwd resolution from projections affect composer discovery; Claude runs per-workspace probes with caching, but behavior falls back to snapshots for non-Claude providers and failed probes.

Overview
Workspace-scoped provider menus — Web and mobile composers no longer rely only on the global provider snapshot for / slash commands and $ skills. While those menus are open, they call useProviderWorkspaceCapabilities, which hits server.listProviderWorkspaceCapabilities with project/thread ids (no client paths).

Server resolution — The WS handler resolves cwd from the thread worktree when it belongs to the project, otherwise the project workspace root, then ProviderRegistry.listWorkspaceCapabilities. Drivers may implement listWorkspaceCapabilities(cwd); others keep snapshot lists.

Claude — ClaudeDriver probes capabilities and discovers skills in that cwd, caches per workspace (~5 minutes), and falls back to snapshot slash commands if the probe is empty.

Docs note that menus reflect the thread’s workspace folder.

^{Reviewed by Cursor Bugbot for commit 7c05f4e. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Discover Claude slash commands and skills per workspace in chat composers

• Adds a new server.listProviderWorkspaceCapabilities RPC that resolves the workspace directory from the active thread's worktree path or project root, then queries the Claude provider for workspace-scoped slash commands and skills.
• ClaudeDriver gains a listWorkspaceCapabilities(cwd) method backed by a capacity-8 cache, concurrently probing Claude capabilities and discovering skills, with fallback to the cached snapshot.
• Web (ChatComposer) and mobile (ThreadComposer) composers call the new useProviderWorkspaceCapabilities hook when a slash-command or skill trigger is active, falling back to provider snapshot data if the query is unavailable.
• Contract schemas, RPC group, client-runtime atoms, and RPC authorization scope are all updated to support the new endpoint.

^{Macroscope summarized 7c05f4e.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: b61acdbc-c0c9-4903-abb6-aa24cefd58b1

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[macroscopeapp]

Approvability

Verdict: Needs human review

This PR introduces new per-workspace discovery of Claude commands and skills, including a new RPC endpoint, client hooks, and caching logic. As a new feature that changes user-facing behavior (which commands/skills appear based on workspace), it warrants human review.

^{You can customize Macroscope's approvability policy. Learn more.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 990e75a. Configure here.}

[RaitP1]

What Changed

• The composer now asks the server which commands and skills exist in the workspace it is about to send a turn to, instead of reading the single global list that ships with the provider snapshot.
• The client sends ids, never a path. The server picks the directory itself: the thread's worktree when it has one, otherwise the project folder.
• For Claude, the server runs the same capability probe and skill scan in that directory and keeps the answer for five minutes per workspace. A provider with nothing project-specific to report still answers from the global snapshot, so nothing else changes.

composer (web / mobile)
└─ useProviderWorkspaceCapabilities() apps/{web,mobile}/src/state/queries.ts
└─ serverEnvironment.providerWorkspaceCapabilities packages/client-runtime/src/state/server.ts
└─ WS RPC "server.listProviderWorkspaceCapabilities" packages/contracts/src/rpc.ts
└─ scope check apps/server/src/auth/RpcAuthorization.ts
└─ handler: resolve the cwd apps/server/src/ws.ts
└─ ProviderRegistry.listWorkspaceCapabilities()
└─ instance.listWorkspaceCapabilities(cwd) (optional)
└─ ClaudeDriver: probe + skill scan

Why

Commands and skills that live inside a project never appear in the / and $ menus, and every project shows the same list. Typing the command still works, because the thread itself runs in the project folder. Only the menus are wrong.

Discovery asks the directory the server process started in, not the project the user has open. In the desktop app those are never the same. The answer is then cached per provider, with nothing that records which project it came from, so opening another project cannot refresh it.

Left out on purpose: other providers keep their current behavior, and a probe that fails drops its cached entry instead of leaving a menu empty for the next five minutes.

Related: #4658. #4546 proposes the skills half of this, for the $ picker only.

Checklist

• This PR is small and focused — one concern, the directory discovery reads
• I explained what changed and why
• I included before/after screenshots for any UI changes — no visual change; the menus look the same and list the open project's entries. I can add a matched pair.
• I included a video for animation/interaction changes — not applicable

Written by Claude Opus 5 in Claude Code, running inside T3 Code.

---

Note

Medium Risk
New read RPC and cwd resolution from projections affect composer discovery; Claude runs per-workspace probes with caching, but behavior falls back to snapshots for non-Claude providers and failed probes.

Overview
Workspace-scoped provider menus — Web and mobile composers no longer rely only on the global provider snapshot for / slash commands and $ skills. While those menus are open, they call useProviderWorkspaceCapabilities, which hits server.listProviderWorkspaceCapabilities with project/thread ids (no client paths).

Server resolution — The WS handler resolves cwd from the thread worktree when it belongs to the project, otherwise the project workspace root, then ProviderRegistry.listWorkspaceCapabilities. Drivers may implement listWorkspaceCapabilities(cwd); others keep snapshot lists.

Claude — ClaudeDriver probes capabilities and discovers skills in that cwd, caches per workspace (~5 minutes), and falls back to snapshot slash commands if the probe is empty.

Docs note that menus reflect the thread’s workspace folder.

^{Reviewed by Cursor Bugbot for commit 7c05f4e. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Discover Claude slash commands and skills per workspace in chat composers

• Adds a new server.listProviderWorkspaceCapabilities RPC that resolves the workspace directory from the active thread's worktree path or project root, then queries the Claude provider for workspace-scoped slash commands and skills.
• ClaudeDriver gains a listWorkspaceCapabilities(cwd) method backed by a capacity-8 cache, concurrently probing Claude capabilities and discovering skills, with fallback to the cached snapshot.
• Web (ChatComposer) and mobile (ThreadComposer) composers call the new useProviderWorkspaceCapabilities hook when a slash-command or skill trigger is active, falling back to provider snapshot data if the query is unavailable.
• Contract schemas, RPC group, client-runtime atoms, and RPC authorization scope are all updated to support the new endpoint.

^{Macroscope summarized 7c05f4e.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: b61acdbc-c0c9-4903-abb6-aa24cefd58b1

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[macroscopeapp]

Approvability

Verdict: Needs human review

This PR introduces new per-workspace discovery of Claude commands and skills, including a new RPC endpoint, client hooks, and caching logic. As a new feature that changes user-facing behavior (which commands/skills appear based on workspace), it warrants human review.

^{You can customize Macroscope's approvability policy. Learn more.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 990e75a. Configure here.}

[RaitP1]

What Changed

• The composer now asks the server which commands and skills exist in the workspace it is about to send a turn to, instead of reading the single global list that ships with the provider snapshot.
• The client sends ids, never a path. The server picks the directory itself: the thread's worktree when it has one, otherwise the project folder.
• For Claude, the server runs the same capability probe and skill scan in that directory and keeps the answer for five minutes per workspace. A provider with nothing project-specific to report still answers from the global snapshot, so nothing else changes.

composer (web / mobile)
└─ useProviderWorkspaceCapabilities() apps/{web,mobile}/src/state/queries.ts
└─ serverEnvironment.providerWorkspaceCapabilities packages/client-runtime/src/state/server.ts
└─ WS RPC "server.listProviderWorkspaceCapabilities" packages/contracts/src/rpc.ts
└─ scope check apps/server/src/auth/RpcAuthorization.ts
└─ handler: resolve the cwd apps/server/src/ws.ts
└─ ProviderRegistry.listWorkspaceCapabilities()
└─ instance.listWorkspaceCapabilities(cwd) (optional)
└─ ClaudeDriver: probe + skill scan

Why

Commands and skills that live inside a project never appear in the / and $ menus, and every project shows the same list. Typing the command still works, because the thread itself runs in the project folder. Only the menus are wrong.

Discovery asks the directory the server process started in, not the project the user has open. In the desktop app those are never the same. The answer is then cached per provider, with nothing that records which project it came from, so opening another project cannot refresh it.

Left out on purpose: other providers keep their current behavior, and a probe that fails drops its cached entry instead of leaving a menu empty for the next five minutes.

Related: #4658. #4546 proposes the skills half of this, for the $ picker only.

Checklist

• This PR is small and focused — one concern, the directory discovery reads
• I explained what changed and why
• I included before/after screenshots for any UI changes — no visual change; the menus look the same and list the open project's entries. I can add a matched pair.
• I included a video for animation/interaction changes — not applicable

Written by Claude Opus 5 in Claude Code, running inside T3 Code.

---

Note

Medium Risk
New read RPC and cwd resolution from projections affect composer discovery; Claude runs per-workspace probes with caching, but behavior falls back to snapshots for non-Claude providers and failed probes.

Overview
Workspace-scoped provider menus — Web and mobile composers no longer rely only on the global provider snapshot for / slash commands and $ skills. While those menus are open, they call useProviderWorkspaceCapabilities, which hits server.listProviderWorkspaceCapabilities with project/thread ids (no client paths).

Server resolution — The WS handler resolves cwd from the thread worktree when it belongs to the project, otherwise the project workspace root, then ProviderRegistry.listWorkspaceCapabilities. Drivers may implement listWorkspaceCapabilities(cwd); others keep snapshot lists.

Claude — ClaudeDriver probes capabilities and discovers skills in that cwd, caches per workspace (~5 minutes), and falls back to snapshot slash commands if the probe is empty.

Docs note that menus reflect the thread’s workspace folder.

^{Reviewed by Cursor Bugbot for commit 7c05f4e. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Discover Claude slash commands and skills per workspace in chat composers

• Adds a new server.listProviderWorkspaceCapabilities RPC that resolves the workspace directory from the active thread's worktree path or project root, then queries the Claude provider for workspace-scoped slash commands and skills.
• ClaudeDriver gains a listWorkspaceCapabilities(cwd) method backed by a capacity-8 cache, concurrently probing Claude capabilities and discovering skills, with fallback to the cached snapshot.
• Web (ChatComposer) and mobile (ThreadComposer) composers call the new useProviderWorkspaceCapabilities hook when a slash-command or skill trigger is active, falling back to provider snapshot data if the query is unavailable.
• Contract schemas, RPC group, client-runtime atoms, and RPC authorization scope are all updated to support the new endpoint.

^{Macroscope summarized 7c05f4e.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: b61acdbc-c0c9-4903-abb6-aa24cefd58b1

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[macroscopeapp]

Approvability

Verdict: Needs human review

This PR introduces new per-workspace discovery of Claude commands and skills, including a new RPC endpoint, client hooks, and caching logic. As a new feature that changes user-facing behavior (which commands/skills appear based on workspace), it warrants human review.

^{You can customize Macroscope's approvability policy. Learn more.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 990e75a. Configure here.}

[RaitP1]

What Changed

• The composer now asks the server which commands and skills exist in the workspace it is about to send a turn to, instead of reading the single global list that ships with the provider snapshot.
• The client sends ids, never a path. The server picks the directory itself: the thread's worktree when it has one, otherwise the project folder.
• For Claude, the server runs the same capability probe and skill scan in that directory and keeps the answer for five minutes per workspace. A provider with nothing project-specific to report still answers from the global snapshot, so nothing else changes.

composer (web / mobile)
└─ useProviderWorkspaceCapabilities() apps/{web,mobile}/src/state/queries.ts
└─ serverEnvironment.providerWorkspaceCapabilities packages/client-runtime/src/state/server.ts
└─ WS RPC "server.listProviderWorkspaceCapabilities" packages/contracts/src/rpc.ts
└─ scope check apps/server/src/auth/RpcAuthorization.ts
└─ handler: resolve the cwd apps/server/src/ws.ts
└─ ProviderRegistry.listWorkspaceCapabilities()
└─ instance.listWorkspaceCapabilities(cwd) (optional)
└─ ClaudeDriver: probe + skill scan

Why

Commands and skills that live inside a project never appear in the / and $ menus, and every project shows the same list. Typing the command still works, because the thread itself runs in the project folder. Only the menus are wrong.

Discovery asks the directory the server process started in, not the project the user has open. In the desktop app those are never the same. The answer is then cached per provider, with nothing that records which project it came from, so opening another project cannot refresh it.

Left out on purpose: other providers keep their current behavior, and a probe that fails drops its cached entry instead of leaving a menu empty for the next five minutes.

Related: #4658. #4546 proposes the skills half of this, for the $ picker only.

Checklist

• This PR is small and focused — one concern, the directory discovery reads
• I explained what changed and why
• I included before/after screenshots for any UI changes — no visual change; the menus look the same and list the open project's entries. I can add a matched pair.
• I included a video for animation/interaction changes — not applicable

Written by Claude Opus 5 in Claude Code, running inside T3 Code.

---

Note

Medium Risk
New read RPC and cwd resolution from projections affect composer discovery; Claude runs per-workspace probes with caching, but behavior falls back to snapshots for non-Claude providers and failed probes.

Overview
Workspace-scoped provider menus — Web and mobile composers no longer rely only on the global provider snapshot for / slash commands and $ skills. While those menus are open, they call useProviderWorkspaceCapabilities, which hits server.listProviderWorkspaceCapabilities with project/thread ids (no client paths).

Server resolution — The WS handler resolves cwd from the thread worktree when it belongs to the project, otherwise the project workspace root, then ProviderRegistry.listWorkspaceCapabilities. Drivers may implement listWorkspaceCapabilities(cwd); others keep snapshot lists.

Claude — ClaudeDriver probes capabilities and discovers skills in that cwd, caches per workspace (~5 minutes), and falls back to snapshot slash commands if the probe is empty.

Docs note that menus reflect the thread’s workspace folder.

^{Reviewed by Cursor Bugbot for commit 7c05f4e. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Discover Claude slash commands and skills per workspace in chat composers

• Adds a new server.listProviderWorkspaceCapabilities RPC that resolves the workspace directory from the active thread's worktree path or project root, then queries the Claude provider for workspace-scoped slash commands and skills.
• ClaudeDriver gains a listWorkspaceCapabilities(cwd) method backed by a capacity-8 cache, concurrently probing Claude capabilities and discovering skills, with fallback to the cached snapshot.
• Web (ChatComposer) and mobile (ThreadComposer) composers call the new useProviderWorkspaceCapabilities hook when a slash-command or skill trigger is active, falling back to provider snapshot data if the query is unavailable.
• Contract schemas, RPC group, client-runtime atoms, and RPC authorization scope are all updated to support the new endpoint.

^{Macroscope summarized 7c05f4e.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: b61acdbc-c0c9-4903-abb6-aa24cefd58b1

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[macroscopeapp]

Approvability

Verdict: Needs human review

This PR introduces new per-workspace discovery of Claude commands and skills, including a new RPC endpoint, client hooks, and caching logic. As a new feature that changes user-facing behavior (which commands/skills appear based on workspace), it warrants human review.

^{You can customize Macroscope's approvability policy. Learn more.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 990e75a. Configure here.}

[RaitP1]

What Changed

• The composer now asks the server which commands and skills exist in the workspace it is about to send a turn to, instead of reading the single global list that ships with the provider snapshot.
• The client sends ids, never a path. The server picks the directory itself: the thread's worktree when it has one, otherwise the project folder.
• For Claude, the server runs the same capability probe and skill scan in that directory and keeps the answer for five minutes per workspace. A provider with nothing project-specific to report still answers from the global snapshot, so nothing else changes.

composer (web / mobile)
└─ useProviderWorkspaceCapabilities() apps/{web,mobile}/src/state/queries.ts
└─ serverEnvironment.providerWorkspaceCapabilities packages/client-runtime/src/state/server.ts
└─ WS RPC "server.listProviderWorkspaceCapabilities" packages/contracts/src/rpc.ts
└─ scope check apps/server/src/auth/RpcAuthorization.ts
└─ handler: resolve the cwd apps/server/src/ws.ts
└─ ProviderRegistry.listWorkspaceCapabilities()
└─ instance.listWorkspaceCapabilities(cwd) (optional)
└─ ClaudeDriver: probe + skill scan

Why

Commands and skills that live inside a project never appear in the / and $ menus, and every project shows the same list. Typing the command still works, because the thread itself runs in the project folder. Only the menus are wrong.

Discovery asks the directory the server process started in, not the project the user has open. In the desktop app those are never the same. The answer is then cached per provider, with nothing that records which project it came from, so opening another project cannot refresh it.

Left out on purpose: other providers keep their current behavior, and a probe that fails drops its cached entry instead of leaving a menu empty for the next five minutes.

Related: #4658. #4546 proposes the skills half of this, for the $ picker only.

Checklist

• This PR is small and focused — one concern, the directory discovery reads
• I explained what changed and why
• I included before/after screenshots for any UI changes — no visual change; the menus look the same and list the open project's entries. I can add a matched pair.
• I included a video for animation/interaction changes — not applicable

Written by Claude Opus 5 in Claude Code, running inside T3 Code.

---

Note

Medium Risk
New read RPC and cwd resolution from projections affect composer discovery; Claude runs per-workspace probes with caching, but behavior falls back to snapshots for non-Claude providers and failed probes.

Overview
Workspace-scoped provider menus — Web and mobile composers no longer rely only on the global provider snapshot for / slash commands and $ skills. While those menus are open, they call useProviderWorkspaceCapabilities, which hits server.listProviderWorkspaceCapabilities with project/thread ids (no client paths).

Server resolution — The WS handler resolves cwd from the thread worktree when it belongs to the project, otherwise the project workspace root, then ProviderRegistry.listWorkspaceCapabilities. Drivers may implement listWorkspaceCapabilities(cwd); others keep snapshot lists.

Claude — ClaudeDriver probes capabilities and discovers skills in that cwd, caches per workspace (~5 minutes), and falls back to snapshot slash commands if the probe is empty.

Docs note that menus reflect the thread’s workspace folder.

^{Reviewed by Cursor Bugbot for commit 7c05f4e. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Discover Claude slash commands and skills per workspace in chat composers

• Adds a new server.listProviderWorkspaceCapabilities RPC that resolves the workspace directory from the active thread's worktree path or project root, then queries the Claude provider for workspace-scoped slash commands and skills.
• ClaudeDriver gains a listWorkspaceCapabilities(cwd) method backed by a capacity-8 cache, concurrently probing Claude capabilities and discovering skills, with fallback to the cached snapshot.
• Web (ChatComposer) and mobile (ThreadComposer) composers call the new useProviderWorkspaceCapabilities hook when a slash-command or skill trigger is active, falling back to provider snapshot data if the query is unavailable.
• Contract schemas, RPC group, client-runtime atoms, and RPC authorization scope are all updated to support the new endpoint.

^{Macroscope summarized 7c05f4e.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: b61acdbc-c0c9-4903-abb6-aa24cefd58b1

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[macroscopeapp]

Approvability

Verdict: Needs human review

This PR introduces new per-workspace discovery of Claude commands and skills, including a new RPC endpoint, client hooks, and caching logic. As a new feature that changes user-facing behavior (which commands/skills appear based on workspace), it warrants human review.

^{You can customize Macroscope's approvability policy. Learn more.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 990e75a. Configure here.}