Description
When a project is linked to a workspace, the skills uploaded to that workspace
should be available to the agent in that project. Today they are not: skills
have to exist on the machine already, so anything authored in the workspace is
invisible to the CLI.
Use Case
A team keeps its shared conventions as skills on a workspace — how their dbt
project is laid out, which warehouse patterns are house style, the runbook for a
recurring migration. Someone uploads a skill; everyone whose project is linked
to that workspace should get it.
Concretely:
- A new joiner clones a linked repo and gets the team's skills without being
told they exist or copying files by hand.
- Someone fixes a skill in the workspace and the correction reaches teammates,
rather than each person carrying a private copy that drifts.
- A skill can ship supporting files — reference notes, examples — not just a
single markdown file, since that is how non-trivial skills are actually
written.
The gap is most obvious with worktrees and second clones: the same repo, the
same user, the same linked workspace, but nothing arrives.
Proposed Solution
Sync a linked workspace's skill bundles onto disk in the project, where the
existing skill discovery already looks. Whole bundle, so bundled reference files
come with it.
Behaviour that matters:
- Refresh when a skill is added or changed in the workspace, without needing a
restart.
- Never confuse a failed fetch with an empty workspace — a network failure must
leave whatever is already on disk alone, because "empty" is the answer that
deletes it.
- Never replace or delete a directory the client did not create.
- Stop serving a workspace's skills when the account is disconnected or the
feature is turned off.
- Keep the synced tree out of the user's version control.
Alternatives Considered
- Copy skills by hand. What happens today. Drifts immediately and does not
survive a new clone.
- Fetch on demand when the model asks for a skill. Puts a network round-trip
in the middle of a turn, and gives no way to list what is available up front.
- A separate CLI command to pull skills. Workable, but it is another thing to
remember, and the common failure is not knowing the skills exist at all.
Pre-submission Checklist
Description
When a project is linked to a workspace, the skills uploaded to that workspace
should be available to the agent in that project. Today they are not: skills
have to exist on the machine already, so anything authored in the workspace is
invisible to the CLI.
Use Case
A team keeps its shared conventions as skills on a workspace — how their dbt
project is laid out, which warehouse patterns are house style, the runbook for a
recurring migration. Someone uploads a skill; everyone whose project is linked
to that workspace should get it.
Concretely:
told they exist or copying files by hand.
rather than each person carrying a private copy that drifts.
single markdown file, since that is how non-trivial skills are actually
written.
The gap is most obvious with worktrees and second clones: the same repo, the
same user, the same linked workspace, but nothing arrives.
Proposed Solution
Sync a linked workspace's skill bundles onto disk in the project, where the
existing skill discovery already looks. Whole bundle, so bundled reference files
come with it.
Behaviour that matters:
restart.
leave whatever is already on disk alone, because "empty" is the answer that
deletes it.
feature is turned off.
Alternatives Considered
survive a new clone.
in the middle of a turn, and gives no way to list what is available up front.
remember, and the common failure is not knowing the skills exist at all.
Pre-submission Checklist