Skip to content

fix: uv lock release sync and local skill install - #147

Merged
zhengchaol merged 3 commits into
mainfrom
fix/uv-lock-release-sync
Aug 14, 2026
Merged

fix: uv lock release sync and local skill install#147
zhengchaol merged 3 commits into
mainfrom
fix/uv-lock-release-sync

Conversation

@zhengchaol

@zhengchaol zhengchaol commented Aug 14, 2026

Copy link
Copy Markdown
Contributor
  1. bump uv.lock in release script
  2. skill install --project now install .claude/skills if Claude is detected. Previously this only works for the global skill install

zhengchaol and others added 3 commits August 14, 2026 09:30
The 0.8.2 bump (#146) updated pyproject.toml, __init__.py, the cloud
function requirements, and npm/package.json, but left uv.lock pinning
the editable parallel-web-tools entry at 0.8.1 — the same slip the
0.8.1 release made (fixed by hand in #145). Any uv sync regenerates the
entry, so the lock has been showing as dirty in working trees since the
release.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Every release bump has left uv.lock stale on main: release.sh rewrites
pyproject.toml but never re-locks, so the lock's own-package entry keeps
the previous version and the first uv sync in any working tree dirties
it. It happened at 0.8.1, was hand-patched in #145, and happened again
at 0.8.2.

Run uv lock as part of update_version_files and stage uv.lock in the
release commit. Add a `uv lock --check` step to the CI lint job so a
stale lock fails the release PR instead of surfacing later — `uv sync`
alone silently re-locks in the runner and can never catch it.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
`skills install --project` only wrote `<root>/.claude/skills` when
`<root>/.claude` already existed. A repo that has never stored Claude
settings has no `.claude` directory, so on exactly the machines that do
run Claude Code, project installs landed only in `.agents/skills` — a
location Claude Code never reads — and the skills were silently
invisible.

A missing `<root>/.claude` doesn't mean the user isn't running Claude
Code there; a missing machine-level configuration directory does.
Project installs now create `<root>/.claude/skills` whenever the
machine-level Claude config dir (CLAUDE_CONFIG_DIR or ~/.claude)
exists. The mirror stays project-local — the global config dir is only
consulted as the Claude-Code-is-present signal, never as a target.
Global installs are unchanged.

Also refresh the --project help strings, which still described the
pre-#145 single-directory behavior.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@zhengchaol
zhengchaol merged commit 59b0b86 into main Aug 14, 2026
7 checks passed
@zhengchaol
zhengchaol deleted the fix/uv-lock-release-sync branch August 14, 2026 17:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant