Repository navigation
fix: uloop skills install without a target flag now refreshes existing skill installs instead of doing nothing - #3189
Conversation
The help text promises that targets already holding uloop skills are refreshed even when their flag is omitted, but install without any target flag prints the target guidance and exits before detection runs. The first test pins the promised refresh and fails today; the second pins that guidance is still printed when no target holds a uloop skill.
…flag Install without any target flag now runs the same installed-target detection that a flagged install uses for auto-refresh: when a target already holds a uloop skill it is refreshed, and the target guidance is printed only when no target holds one. This makes the command do what its help text already promises. A detection error is reported with code 1 in the same form as the flagged install, and a test pins it.
|
Warning Review limit reachedYou've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Next included review available in 15 minutes. View limit detailsLimit details: You’ve used all 4 included reviews currently available. Review configuration: ⚙️ Run configuration
📒 Files selected for processing (1)
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configuration
📒 Files selected for processing (2)
Included review availability: This review used your included allowance. Your plan provides up to 4 included reviews per hour; 2 remain after this review. 📝 WalkthroughWalkthroughWhen ChangesSkill Install
Priority: ⬇️ Low Estimated code review effort: 2 (Simple) | ~10 minutes Change: Bug fix Merge Risk: ⚪ Minimal · up to Running Security Architecture ReviewSecurity architecture risk: 🔵 Low · up to The command reuses the existing installer and preserves explicit global and custom-directory options. However, automatic refresh now reaches filesystem writes without target flags, and linked target directories can redirect those writes beyond the selected project. Exposure requires running the install command and remains limited by the caller's filesystem permissions. Retained concerns
Security review detailsSecurity Blast Radius
Security Findings and Attack Paths
Trust Boundaries and Controls
Resilience and Maintainability Implications
Hardening Proposals
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches 💡 1📝 Generate docstrings 💡
🧪 Generate unit tests (beta)
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 |
Install without a target flag now refreshes targets that already hold uloop skills, so printing only guidance holds just when none does.
e084a23
into
feature/hot-reload-large-project-feedback
Summary
uloop skills installwith no target flag now refreshes every target that already holds uloop skills, as its help text already promised. When no target holds them yet, it still prints the target guidance and exits 0.User Impact
uloop skills installwith no target flag printed "Please specify at least one target for 'install':" and exited 0 without touching anything, even though the project's.claude/skillsalready held uloop skills. The help text says "Targets that already contain uloop skills are refreshed automatically, even when their flag is omitted", so the installed copies stayed stale while the command looked successful. Passing any target flag (for example--claude) refreshed every installed target, including the others.Auto-refreshing <target>: an existing uloop skill install was detected there.for each target that holds uloop skills and refreshes them, the same way a flagged install already refreshes the targets it was not asked for.Cause
Install without any target flag printed the guidance and returned before reaching
runSkillsInstall, which is where the detection of already-installed targets runs.Changes
runSkillsInstallWithGuidance: with no target flag, run the existingdetectInstalledSkillTargetsfirst. If it finds any target, continue intorunSkillsInstall, which detects them again (a few stats) and refreshes them. If it finds none, print the guidance and return 0 as before. A detection error is reported in the same form as inrunSkillsInstalland returns 1.What did not change:
uloop skills uninstallstill requires a target flag. Uninstall removes files, so it still asks for an explicit target.--output-dir, and the v3-migration subcommands are unchanged. The help text is unchanged; the command now does what it says.--globalwith no resolvable home directory, or a target directory that cannot be read), install without a flag now reports that error with exit 1 instead of printing the guidance. A flagged install already failed the same way.Tests
New tests in
skills_dispatch_test.go:TestRunSkillsSubcommandInstallWithoutTargetRefreshesDetectedInstall: install with--claude, overwrite the installedSKILL.mdwith stale content, then install with no target. Expects exit 0,Auto-refreshingin the output, no guidance, and the source content restored. It failed before the fix: the guidance was printed and the file stayed stale. That failing state is the first commit.TestRunSkillsSubcommandInstallWithoutTargetAndNoInstallPrintsGuidance: with nothing installed, install with no target. Expects exit 0, the guidance, noAuto-refreshing, and noSKILL.mdanywhere outside the skill source.TestRunSkillsSubcommandInstallWithoutTargetReportsDetectionErrors: with--globaland a failing home lookup, install with no target. Expects exit 1, the error on stderr, and no guidance. This case does not touch the file system, so it also runs on Windows.Mutations, each applied to the fix and then reverted:
TestTryHandleSkillsRequestPrintsTargetGuidanceWithoutTargets.Verification
This PR targets the integration branch, so the Go CI (
build-cli) does not run on it. It will run when the integration branch goes tomain. Local results on macOS:cd cli/dispatcher && go test ./... -count=1: all packages pass.scripts/check-go-cli.shstopped incli/common.ipcendpoint'sTestOSUnixMetadataReaderReportsRealOwnerAndModecould not create its directory under the system temp directory because the local sandbox denies it (operation not permitted). This PR does not touchcli/common. Before that point,cli/commonpassed format, vet, and lint (0 issues), and every othercli/commontest package passed.golangci-lint fmt --diff,go vet ./...,golangci-lint run ./...,go test ./...):cli/dispatcher: format, vet, lint (0 issues), and tests all pass.cli/release-automation: format, vet, lint (0 issues), and tests all pass.cli/project-runner: format, vet, and lint (0 issues) pass. One test,TestSendWithTransientConnectionRetryAbortsOnRefusedConnect, cannot bind its Unix socket because the local sandbox denies it (bind: operation not permitted). This PR does not touchcli/project-runner.go buildflags asscripts/build-go-cli.sh. From the root of a Unity project whose.claude/skillsand.agents/skillsalready hold the generated copies, I ranuloop skills installwith no target flag. It exited 0, printedAuto-refreshing Claude CodeandAuto-refreshing Common, and reportedSkipped: 22for each target (the copies were already current).git status --porcelainstayed empty.Release
This is a dispatcher change, so users get it with the next dispatcher release.