first pass of merging in warp (doesn't build)
This commit is contained in:
Ryan Ward
@@ -0,0 +1,104 @@
|
||||
# Common Skills Installation — Product Spec
|
||||
## Summary
|
||||
Warp development setup should automatically make the shared `warpdotdev/common-skills` agent skills available to local agents, without requiring developers to remember manual restore commands. `script/bootstrap` and `script/run` should install or update common skills from the repository lock, support both project-local and global installs, work whether the common-skills repo is checked out locally or not, and prevent duplicate project/global common-skill definitions.
|
||||
## Problem
|
||||
Common skills are consumed by agents across Warp development workflows. If they are missing, stale, installed in two places, or restored from an unexpected source, local agents can behave differently across developer machines and cloud-like local test scenarios.
|
||||
## Goals / Non-goals
|
||||
1. Common skills should be present and match the Warp checkout's expected versions after successful setup flows.
|
||||
2. Developers should explicitly choose project-local or global installation through a flag, environment variable, or interactive prompt.
|
||||
3. Developers should be able to test the same behavior with a local common-skills checkout, a common-skills worktree, or the remote `warpdotdev/common-skills` repo.
|
||||
4. Installing common skills must not duplicate the same common skills in both project and global locations.
|
||||
5. Normal setup should follow the Warp checkout's lock file; adopting newer upstream common skills is an explicit developer-approved update to that lock, not an unreviewed floating dependency update during every run.
|
||||
## Behavior
|
||||
1. `./script/bootstrap` includes common-skills setup as part of the normal local platform bootstrap flow. A developer who runs bootstrap without opting out should end the setup with common skills installed in exactly one supported target and matching the Warp checkout's common-skills lock.
|
||||
|
||||
2. `./script/bootstrap --skip-common-skills` skips all common-skills installation and verification behavior. Platform bootstrap behavior continues as usual, and the command does not create, remove, update, or verify common skills.
|
||||
|
||||
3. `WARP_SKIP_COMMON_SKILLS_INSTALL=1` skips common-skills installation and verification even when bootstrap or run would otherwise install common skills. This environment override is respected consistently by bootstrap and run.
|
||||
|
||||
4. `./script/run` checks common skills before launching the local Warp build. When common skills are missing or stale, the check attempts to restore them before the app launches. When common skills are already current, the check is quiet and does not distract the developer from the run flow.
|
||||
|
||||
5. `./script/run` is strict for common-skills setup when common-skills installation is enabled. If run cannot install or verify common skills, it reports the error and fails before launching Warp so the developer does not start a local build with missing, stale, duplicated, or mismatched common skills.
|
||||
|
||||
6. `./script/bootstrap` is equally strict for common-skills setup when common-skills installation is enabled. If bootstrap cannot install or verify common skills, bootstrap reports the error and fails so the developer knows setup is incomplete.
|
||||
|
||||
7. `./script/run --install-common-skills` forces a common-skills restore attempt before launching Warp, even when the current install appears up to date. This gives developers a simple recovery path when they suspect local skill contents are damaged or stale.
|
||||
|
||||
8. If a developer explicitly selects project installation with `./script/bootstrap --install-common-skills-in-repo`, `WARP_COMMON_SKILLS_INSTALL_TARGET=project`, or the installer `--project` option, common skills are installed into the Warp checkout's project-local skill directory as local developer state.
|
||||
|
||||
9. Project-local common-skill installs are ignored by Git and must not be checked into source control. The ignore behavior applies only to the locked common-skill paths installed from `warpdotdev/common-skills`; unrelated project-local skills in `.agents/skills` must remain visible in normal `git status`. A developer who installs common skills into the project directory should not see the installed common-skill directories as untracked or modified files and should not need to manually avoid committing them.
|
||||
|
||||
10. If a developer explicitly selects global installation with `./script/bootstrap --install-common-skills-globally`, `WARP_COMMON_SKILLS_INSTALL_TARGET=global`, or the installer `--global` option, common skills are installed into the user's global agent skills directory.
|
||||
|
||||
11. Common-skills installation target selection is always explicit. The installer must not infer the target from an existing project-local or global install. A target is explicit only when the developer provides a project/global flag, sets the install-target environment variable, or answers an interactive prompt for the current command.
|
||||
|
||||
12. When no project/global target is provided in an interactive command, bootstrap and run ask the developer where common skills should be installed. The prompt presents project-local and global options, recommends global for normal local development, and uses global only when the developer accepts the default for that prompt.
|
||||
|
||||
13. When no project/global target is provided and no interactive prompt is available, the installer fails with an actionable error asking the developer or automation to choose project or global explicitly. The command should not hang in CI, automation, cloud setup, or non-interactive shell contexts.
|
||||
|
||||
14. Project-local installs and global installs are mutually exclusive for common skills. If common skills are detected in both the Warp checkout and the user's global skill directory, install and verification flows fail with an actionable error telling the developer to remove one copy before continuing. The error should suggest using `remove_common_skills --repo-root <warp-checkout>` to remove the project-local copy or `remove_common_skills --repo-root <warp-checkout> --global` to remove the global copy.
|
||||
|
||||
15. Duplicate detection applies only to the locked common skills, not every skill the developer has installed. Developers may keep unrelated global skills such as personal utilities, local-only workflows, or other agent skills alongside global common skills.
|
||||
|
||||
16. Installing common skills globally must not remove or overwrite unrelated global skills. Only the common skills listed by the Warp checkout's common-skills lock are installed, updated, verified, or removed by these flows.
|
||||
|
||||
17. Installing common skills project-locally must not remove or overwrite unrelated project-local skills. Only the common skills listed by the Warp checkout's common-skills lock are installed, updated, verified, or removed by these flows.
|
||||
|
||||
18. Successful install, update, and skip paths verify that every locked common skill exists in the selected target and matches the content expected by the Warp checkout. A setup flow is not considered successful merely because an install command exited successfully; the installed skill contents must also match the lock.
|
||||
|
||||
19. Verification failures are specific and actionable. Missing skills, duplicated project/global installs, missing lock files, invalid target choices, and content mismatches each produce errors that tell the developer what is wrong and, when possible, how to recover.
|
||||
|
||||
20. `--verify-only` verifies the current common-skills state without installing, updating, creating a lock, or prompting for an install target. If the lock file is missing, it fails immediately with a missing-lock error. If the locked skills are missing, duplicated, or mismatched, it reports those verification errors without changing local skill state.
|
||||
|
||||
21. If the Warp checkout has no common-skills lock during a normal install flow, the installer creates one from `warpdotdev/common-skills` and installs the corresponding common skills into the selected target. If `WARP_COMMON_SKILLS_REF=<git-ref>` is set, the missing lock is created from that branch, tag, or commit instead. This supports first-time setup of a checkout that has not yet adopted a common-skills lock and lets developers test a common-skills branch end to end.
|
||||
|
||||
22. If the Warp checkout already has a common-skills lock, install flows treat that lock as the manifest for the selected target: the lock determines which common skills should exist and what their file contents should be. Restoring from the lock means the selected project-local target is brought back to that manifest, or the selected global target is installed or verified when it is empty or already matches the same lock. If the global target is already pinned to a different common-skills lock, the flow fails with a version-mismatch error instead of overwriting it. Normal bootstrap and run flows do not silently float to newer common-skills contents that were pushed upstream after the lock was written.
|
||||
|
||||
23. In an interactive normal install flow where the Warp checkout already has a common-skills lock, the installer checks whether `warpdotdev/common-skills` would produce a different lock before asking the developer to choose project-local vs. global installation. If `WARP_COMMON_SKILLS_REF=<git-ref>` is set, the check uses that branch, tag, or commit as the candidate source. If the candidate common-skills version differs, the installer tells the developer that common skills have been updated and asks whether to update the checkout's `skills-lock.json` and reinstall common skills from the updated lock.
|
||||
|
||||
24. If the developer accepts the interactive upstream update prompt, the installer updates the checkout's `skills-lock.json`, then continues to the explicit project/global target choice when no target was already provided. After the target is selected, it reinstalls common skills from the updated lock. The resulting lock diff is a tracked source change that the developer can review and commit intentionally.
|
||||
|
||||
25. If the developer declines the interactive upstream update prompt, the installer leaves `skills-lock.json` unchanged and continues normal setup from the existing lock. It may still prompt for the project/global target and restore missing or stale local skill contents to match the existing lock.
|
||||
|
||||
26. Explicit non-interactive flows never prompt to update `skills-lock.json` from upstream. CI, cloud setup, and direct installer invocations with `--non-interactive` use the current checkout lock as the source of truth and fail rather than hanging if required choices were not provided. Local `script/run` behaves like bootstrap: it may prompt for upstream lock updates and project/global target selection when run from an interactive terminal.
|
||||
|
||||
27. When new common-skill versions are pushed to `warpdotdev/common-skills`, a developer can also adopt them by manually updating the Warp checkout's common-skills lock. After the lock changes, the next successful `script/run`, `script/bootstrap`, or direct installer invocation updates project-local common skills or an unpinned/matching global install to match the new lock.
|
||||
|
||||
28. If the common-skills lock changes on a branch, `script/run` detects that the locally installed common skills no longer match the checkout's expected versions before launching Warp. For a project-local install, or for a global install that is not pinned to a conflicting version, run restores the selected target automatically. For a global install pinned to a different version, run fails with the same actionable version-mismatch error used by setup.
|
||||
|
||||
29. If the common-skills lock has not changed and installed common skills already match it, `script/run` and `script/bootstrap` skip reinstalling. Skipping should be fast, quiet in normal run flows, and must not modify tracked files.
|
||||
|
||||
30. The installer supports a direct remove flow for developers who intentionally want to clear common skills from one target. Removing project-local common skills removes only the locked common skills from the project target. Removing global common skills removes only the locked common skills from the global target.
|
||||
|
||||
31. `remove_common_skills --clear-lock` is destructive by design: in addition to removing locked common skills from the selected target, it removes the checkout's common-skills lock. After this, `--verify-only` should fail until the lock is restored or a normal install flow recreates it.
|
||||
|
||||
32. If common skills are removed from the selected target but the lock remains, the next normal install flow restores the missing common skills from the lock. If both skills and lock are removed, the next normal install flow treats the checkout as missing a lock and creates a new one from `warpdotdev/common-skills`.
|
||||
|
||||
33. The default script source for common-skills installation is the remote `warpdotdev/common-skills` repository. Bootstrap and run must not silently discover or execute scripts from local sibling checkouts or worktrees.
|
||||
|
||||
34. `WARP_COMMON_SKILLS_SCRIPTS_DIR` lets a developer explicitly test scripts from a local common-skills checkout or worktree. Local script execution is allowed only through this explicit override; it should never happen merely because a checkout or worktree exists nearby.
|
||||
|
||||
35. When no explicit local scripts directory is set, bootstrap and run fetch and execute the remote common-skills script. A developer on a machine that has only the Warp checkout should be able to bootstrap or run without first cloning `warpdotdev/common-skills`, and a developer who does have a local common-skills checkout should still get the remote default unless they opt into local script execution.
|
||||
|
||||
36. `WARP_COMMON_SKILLS_REF=<git-ref>` selects which remote common-skills branch, tag, or commit is used for both the remote script path and the common-skills source used by missing-lock creation and interactive upstream lock update checks. This lets developers test an unpublished or not-yet-main common-skills script and skill-content branch against a local Warp checkout without relying on a local common-skills checkout.
|
||||
|
||||
37. Local and remote script sources should produce the same install behavior for a given script version. Differences in behavior should be attributable to the selected script version, not to whether the script came from a local path or a remote URL.
|
||||
|
||||
38. If remote script fetching fails because the network is unavailable, the branch does not exist, the script is missing, or the remote host returns an error, the command reports the remote fetch failure. Bootstrap and run both treat that as common-skills setup failure when common-skills installation is enabled.
|
||||
|
||||
39. Global common-skills installs are shared per user and may be used by multiple client repositories. If multiple client repos depend on the same locked common-skills version and all select global installation, each repo's setup flow should verify the existing global install and succeed without duplicating or unnecessarily reinstalling the same skills.
|
||||
|
||||
40. If a client repo selects global installation but the existing global common skills match a different common-skills lock than that repo expects, setup should fail with an actionable version-mismatch error rather than silently replacing the global install. The error should explain that another checkout may be pinned to a different common-skills version and that the developer must explicitly reconcile, update, or remove/reinstall the global common skills. When the current interactive flow has just asked the developer to adopt an upstream common-skills update and the developer accepted, reinstalling the selected global target from the newly updated lock is an explicit reconciliation and may proceed.
|
||||
|
||||
41. User-facing output should make state transitions understandable without being noisy. Installs, updates, target prompts, duplicate errors, and verification errors should be visible. No-op checks during normal `script/run` should be quiet when everything is already correct.
|
||||
|
||||
42. Common-skills setup should be safe to rerun. Repeating bootstrap, run, forced install, verify-only, or remove commands should either converge to the requested state or report a clear error; repeated commands should not accumulate duplicate skill copies.
|
||||
|
||||
43. A developer can recover from most bad local states with a small set of understandable actions:
|
||||
- Run normal install to restore missing skills from an existing lock.
|
||||
- Force install to repair damaged skill contents.
|
||||
- Remove one target when duplicate project/global common skills are reported.
|
||||
- Reconcile, update, or remove/reinstall global common skills when multiple checkouts are pinned to different common-skills versions.
|
||||
- Restore or recreate the lock when `--clear-lock` or manual file deletion removed it.
|
||||
|
||||
44. The checked-in common-skills lock is the source of truth for code review. When common skills are intentionally updated, reviewers should be able to see the lock change in the branch rather than having local bootstrap/run flows silently adopt unreviewed upstream content.
|
||||
@@ -0,0 +1,89 @@
|
||||
# Common Skills Installation — Tech Spec
|
||||
|
||||
## Context
|
||||
This PR replaces the custom `.agents/common-skills.lock` flow with the standard project lock managed by `npx skills`. The checked-in `skills-lock.json` records each common skill from `warpdotdev/common-skills`, including its source, skill path, and content hash (`skills-lock.json:1`). Installed skill copies are local developer state: they may live in the checkout's project-local skills directory or in the user's global agent skills directory, but they are not source-controlled. For project-local installs, the installer ignores only the locked common-skill paths so unrelated project skills in `.agents/skills` remain visible to Git.
|
||||
|
||||
The main install entrypoint is `warpdotdev/common-skills/scripts/install_common_skills`. It targets a Warp checkout through `--repo-root <warp-checkout>` or `WARP_COMMON_SKILLS_TARGET_REPO_ROOT`, points at that checkout's `skills-lock.json`, and installs into an explicit target selected by `--project`, `--global`, `WARP_COMMON_SKILLS_INSTALL_TARGET`, or an interactive prompt. If the lock is missing during a normal install, the script creates it by installing the standard common skill set from `warpdotdev/common-skills` with the pinned `skills` CLI. When `WARP_COMMON_SKILLS_REF=<git-ref>` is set, missing-lock creation uses `warpdotdev/common-skills#<git-ref>`. If the lock exists during an interactive normal install, the script checks whether adding the selected common-skills source in a temporary directory would produce a different lock and, when it would, prompts the developer before changing `skills-lock.json`. If the lock is missing during `--verify-only`, the script fails immediately without prompting or creating files.
|
||||
|
||||
The script hashes `skills-lock.json` and records target-local install metadata after a successful restore. Project-local installs use checkout-local metadata under `.git` so normal restore runs do not create tracked files. Global installs use global target metadata so different client repositories can verify whether the shared global install is pinned to the same lock. If a global install already matches the requested lock, setup verifies and succeeds. If it is pinned to a different lock, setup fails with an actionable version-mismatch error instead of silently overwriting the shared global copy. Successful install and skip paths verify that exactly one target contains common skills and that installed contents match `skills-lock.json`.
|
||||
|
||||
`script/run` checks common skills before launching a local build. It enables the check by default and executes the installer through `script/resolve_common_skills`, which uses the raw script from `warpdotdev/common-skills` unless the developer explicitly sets `WARP_COMMON_SKILLS_SCRIPTS_DIR` to a local common-skills checkout or worktree. `WARP_COMMON_SKILLS_REF=<branch>` selects a non-main common-skills ref for the remote script path and is inherited by the installer as the common-skills source ref for missing-lock creation and interactive update checks. `script/run` then calls `warpdotdev/common-skills/scripts/install_common_skills --repo-root <warp-checkout> --if-needed --prompt-for-target --quiet` when no explicit target was provided, or passes `--project`/`--global` when `WARP_COMMON_SKILLS_INSTALL_TARGET` selected a target. `--install-common-skills` forces a restore using the same target-resolution behavior. `script/bootstrap` also installs common skills by default and delegates target resolution to the same installer, allowing the installer to prompt first for an upstream lock update and then for the install target when those choices are needed. `WARP.md` documents the standard update command and the files reviewers should expect to change.
|
||||
|
||||
## Diagrams
|
||||
### Local agent installation and update flow
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A["warpdotdev/warp checkout"] --> B["skills-lock.json"]
|
||||
A --> C["Selected install target"]
|
||||
C --> C1["Project-local .agents/skills/*"]
|
||||
C --> C2["Global ~/.agents/skills/*"]
|
||||
|
||||
B --> D["script/run"]
|
||||
D --> E["common-skills/scripts/install_common_skills --repo-root <warp-checkout> --if-needed --quiet"]
|
||||
E --> F["Hash skills-lock.json"]
|
||||
F --> G{"Does target metadata match?"}
|
||||
|
||||
G -->|Yes| H["Skip restore"]
|
||||
H --> I["Continue local build/run"]
|
||||
|
||||
G -->|No| J["npx --yes skills@1.5.6 experimental_install"]
|
||||
J --> K["Read skills-lock.json"]
|
||||
K --> L["Fetch locked skills from warpdotdev/common-skills"]
|
||||
L --> M["Restore selected install target"]
|
||||
M --> N["Write target-local lock metadata"]
|
||||
N --> I
|
||||
|
||||
O["Developer updates common skills"] --> P["npx --yes skills@1.5.6 update -p -y"]
|
||||
P --> Q["Update skills-lock.json hashes"]
|
||||
Q --> S["Commit lock change"]
|
||||
S --> A
|
||||
```
|
||||
|
||||
### Global target compatibility flow
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A["Client repo selects global install"] --> B["Read repo skills-lock.json"]
|
||||
B --> C{"Does global target contain common skills?"}
|
||||
C -->|No| D["Install locked common skills globally"]
|
||||
C -->|Yes| E{"Does global metadata match repo lock?"}
|
||||
E -->|Yes| F["Verify installed contents"]
|
||||
F --> G["Succeed without reinstalling"]
|
||||
E -->|No| H["Fail with version-mismatch error"]
|
||||
H --> I["Developer explicitly reconciles, updates, or removes/reinstalls global skills"]
|
||||
```
|
||||
|
||||
## Proposed changes
|
||||
The implementation should keep `skills-lock.json` as the single source of truth for common skills installed from `warpdotdev/common-skills`. The repo should not maintain a second custom lock format or a separate GitHub workflow for scheduled common-skill updates.
|
||||
|
||||
`warpdotdev/common-skills/scripts/install_common_skills` owns lock creation and restoration from the lock for a target checkout. It should remain small and deterministic: if `skills-lock.json` is missing during a normal install, create it from the pinned common-skill source; otherwise compute a hash for `skills-lock.json`, compare it with target-local metadata, run `npx --yes skills@1.5.6 experimental_install` only when needed and allowed, and update the metadata after a successful restore. Project-local metadata belongs under the target checkout's `.git` so normal restore runs do not create or modify tracked files unless the lock itself has been updated intentionally. Global metadata belongs with the global install target so multiple client repos can detect whether they are pinned to the same common-skills lock.
|
||||
|
||||
`warpdotdev/common-skills/scripts/install_common_skills` should own install target resolution, but target selection must be explicit. The installer accepts `--project`, `--global`, or `WARP_COMMON_SKILLS_INSTALL_TARGET`; if none is provided in an interactive invocation, it prompts with global as the recommended default. If none is provided in a non-interactive invocation, it fails with an actionable error. It must not infer the target from an existing project-local or global install. It should also fail when both targets contain common skills, suggesting `remove_common_skills --repo-root <warp-checkout>` for the project-local copy or `remove_common_skills --repo-root <warp-checkout> --global` for the global copy.
|
||||
|
||||
For interactive normal install flows with an existing lock, `install_common_skills` should compute a candidate updated lock in a temporary directory before resolving the install target. The candidate is generated by adding `warpdotdev/common-skills`, or `warpdotdev/common-skills#<git-ref>` when `WARP_COMMON_SKILLS_REF` is set, with the pinned `skills` CLI. If the candidate lock differs from the checkout's `skills-lock.json`, the script should print that common skills have been updated in the selected source and ask whether to update the checkout lock and reinstall. Accepting copies the candidate lock into the checkout, marks the flow as an explicit lock update, and continues to target resolution and install. Declining discards the candidate and continues from the existing lock. Non-interactive and verify-only flows skip this upstream check entirely.
|
||||
|
||||
`script/run` should call the installer before building so local developer runs validate lock changes automatically. This makes `script/run` the dependency-update check point requested during review: when a branch changes `skills-lock.json`, the next run restores the matching project-local target or compatible global target without requiring a separate workflow. If no target was provided, run should use the same interactive target prompt as bootstrap; if no prompt is available, the installer should fail with the same actionable target-selection error. If the global target is pinned to a different lock, run should fail before launching Warp. `--install-common-skills` is retained as a force-install escape hatch, subject to the same target-resolution behavior and global version-mismatch guard.
|
||||
|
||||
`script/bootstrap` should delegate to the same installer by default, while retaining `--skip-common-skills` as an opt-out. If bootstrap needs to install or update common skills and no target was explicitly provided, it should ask the user whether to install project-local or globally. This keeps platform setup and normal run setup consistent while avoiding surprising writes.
|
||||
|
||||
`script/resolve_common_skills` should default to executing the remote raw script from `warpdotdev/common-skills`. Local common-skills checkouts or worktrees are used only when `WARP_COMMON_SKILLS_SCRIPTS_DIR` is set. `WARP_COMMON_SKILLS_REF` selects the remote branch, tag, or commit to fetch and is also consumed by `install_common_skills` when selecting the common-skills source for missing-lock creation and interactive update checks. Because the remote script is executed through a pipe, installer child commands that might read stdin should redirect from `/dev/null` so they cannot consume the remaining script body before the restore and verification steps run. No separate `WARP_COMMON_SKILLS_FORCE_REMOTE` option is needed because remote execution is already the default.
|
||||
|
||||
Updates to common skills should be explicit developer actions: accept the interactive bootstrap/install prompt or run `npx --yes skills@1.5.6 update -p -y`, review the generated `skills-lock.json` changes, and commit them. This preserves dependency-review semantics without adding repository-specific scheduled automation.
|
||||
|
||||
## Testing and validation
|
||||
Validate the shell changes with `bash -n <common-skills>/scripts/install_common_skills <common-skills>/scripts/remove_common_skills script/resolve_common_skills script/run script/bootstrap`.
|
||||
|
||||
Validate the Windows bootstrap script parses with PowerShell: `pwsh -NoProfile -Command '$null = [scriptblock]::Create((Get-Content -Raw "script/windows/bootstrap.ps1"))'`.
|
||||
|
||||
Validate the missing-lock path by removing common skills and the lock, then running `<common-skills>/scripts/install_common_skills --repo-root <warp-checkout> --project --if-needed --non-interactive`. It should run the pinned `skills@1.5.6 add warpdotdev/common-skills` command, create `skills-lock.json`, restore the selected project-local target, and write project-local metadata.
|
||||
|
||||
Validate the restore path by running `<common-skills>/scripts/install_common_skills --repo-root <warp-checkout> --project --if-needed --quiet` from a checkout without matching project-local metadata but with an existing lock. It should run the pinned `skills@1.5.6` restore command, restore the selected project-local target, and write project-local metadata.
|
||||
|
||||
Validate the skip path by running `<common-skills>/scripts/install_common_skills --repo-root <warp-checkout> --project --if-needed --quiet` again. It should exit successfully without output and without changing the worktree.
|
||||
|
||||
Validate global sharing by installing common skills globally from two test checkouts with identical `skills-lock.json` contents. The second install should verify and succeed without unnecessarily reinstalling. Then change one checkout's lock and run global setup again; it should fail with the version-mismatch error rather than overwriting the shared global target.
|
||||
|
||||
Validate explicit target selection by running the installer in non-interactive mode without `--project`, `--global`, or `WARP_COMMON_SKILLS_INSTALL_TARGET`. It should fail with an actionable target-selection error and must not infer the target from existing installs.
|
||||
|
||||
Validate interactive update behavior by using a test checkout whose `skills-lock.json` differs from the current `warpdotdev/common-skills` output and running `<common-skills>/scripts/install_common_skills --repo-root <test-checkout> --if-needed --prompt-for-target`. Before the project/global prompt, the script should report that common skills have been updated and ask whether to update the lock. Accepting should change only `skills-lock.json` before target installation; declining should leave the lock unchanged and continue from the existing lock. Also validate `WARP_COMMON_SKILLS_REF=<branch>` with a branch whose skill content differs from the lock; the update prompt should compare against the branch source and the accepted lock should record that ref.
|
||||
|
||||
Validate manual update behavior by running `npx --yes skills@1.5.6 update -p -y` in a test checkout or intentional update branch. If upstream common skills changed, the diff should be limited to `skills-lock.json`.
|
||||
Reference in New Issue
Block a user