Conversation
…action The publish path from the previous PR had no surface: nothing invoked it, so a locally authored skill still had no route to the workspace, and the CLI still did not say whether one existed. - `altimate-code skill publish <name>` resolves the skill the way `skill test` does, refuses a built-in (no directory to bundle), and prints one line on success. Every deliberate refusal — not linked, workspace-owned, binary or linked file, empty, too large, name taken elsewhere, uploaded but not attached — is printed as-is, since each already says what to do. - The Skills dialog gains "Publish to workspace" in the per-skill action picker, next to Show / Edit / Test / Remove — where a user who wonders whether publishing is possible will see it. Disabled for built-ins and for skills the workspace sent us. - `describePublish` and `explainPublishError` give both surfaces the same words, and a `skill_published` telemetry event records the outcome. Verified: 538 pass across the workspace + plugin suites and the fork guards, typecheck clean; `skill publish` smoke-run on an unlinked project and on a missing skill prints the intended line for each. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012Q51zFUmPg1WwtS5CrGJE6
There was a problem hiding this comment.
Claude Code Review
This repository is configured for manual code reviews. Comment @claude review for a one-time review, or @claude review always to subscribe this PR to a review on every future push.
Tip: disable this comment in your organization's Code Review settings.
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Advanced Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
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. Comment |
Code Review SummaryThis review did not run. Your provider API key hit its rate limit, so the Previous Review SummaryCurrent summary above is authoritative. Previous snapshots are kept for context only. Previous reviewThis review did not run. Your provider API key hit its rate limit, so the |
There was a problem hiding this comment.
All reported issues were addressed across 5 files
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
…nst the project directory, record TUI publishes - `skill publish` classifies built-ins through `skillSource`, which also knows the `~/.altimate/builtin` install; the prefix check let those through as absolute paths. - The TUI action checks the managed snapshot against, and publishes from, `api.state.path.directory` — where the binding and the snapshot live — rather than the git root, which differs in a worktree subdirectory. - A TUI publish records the same `skill_published` event as the CLI, with `source: "tui"`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012Q51zFUmPg1WwtS5CrGJE6
Issue for this PR
Part of #1271 — the surface. #1280 added the publish path; this PR is what invokes it.
Type of change
What does this PR do?
Two ways to publish a locally authored skill to the linked workspace, saying the same things.
altimate-code skill publish <name>— resolves the skill the wayskill testdoes, refuses a built-in (there is no directory to bundle; the workspace-owned snapshot is refused bypublishSkillitself), and prints one line on success. Every deliberate refusal is printed as-is, because each already says what to do next:"Publish to workspace" in the Skills dialog's per-skill action picker, next to Show / Edit / Test / Remove. This is the discoverability half: the UAT report was that a participant could not tell whether publishing from the CLI was possible at all. A row that anyone who opens a skill will see answers that; a row under
/workspacewould only be found by someone already thinking about workspaces — and the verb needs a skill name, which that menu does not have. Disabled for built-ins and for skills the workspace sent us, the same way Remove is disabled for built-ins.Deliberately not done: auto-publishing from
skill create. A freshly scaffolded skill is a stub, publish should be an explicit "this is ready for the team" act, and create works on unlinked projects where publish cannot.describePublish/explainPublishErrorinskill-publish.tsgive both surfaces one vocabulary; askill_publishedtelemetry event records the outcome alongside the existingskill_created/skill_installed/skill_removed.How did you verify your code works?
test/altimate/workspace,test/altimate/plugin, the install classifier and the fork-feature guards; typecheck clean.skill publishsmoke-run from source on an unlinked project (prints the not-linked line) and on a missing skill (prints the not-found line);skill --helplists the subcommand.Screenshots / recordings
Not a visual change beyond one new row in an existing picker.
Checklist
🤖 Generated with Claude Code
https://claude.ai/code/session_012Q51zFUmPg1WwtS5CrGJE6
Summary by cubic
Adds a
skill publish <name>CLI command and a "Publish to workspace" action in the Skills dialog's per-skill picker, so locally authored skills can be uploaded to the linked workspace. Previously the publish path existed but nothing invoked it. Built-in skills are refused in both surfaces, and the dialog also disables publishing for skills the workspace sent us. Both surfaces share one wording viadescribePublishandexplainPublishError, and askill_publishedtelemetry event records the outcome from both the CLI and the TUI.Written for commit 30ba5c3. Summary will update on new commits.