Automate the process of creating PRs to update lockfiles in other repos.

[vorporeal]

Description

Automates propagation of common-skills changes to the downstream lockfiles that engineers consume. On every push to main, the workflow regenerates the lockfiles in warpdotdev/warp and warpdotdev/warp-server, opens ready-for-review PRs, requests the originating common-skills PR author when possible, and enables squash auto-merge.

Adds a lock-only helper so CI can refresh hashes without installing skills into the target checkout. Downstream writes use the dedicated, repository-scoped common-skills-sync GitHub App; its installation and the required Actions variable and secret are configured.

Testing

• bash -n scripts/update_common_skills_lock
• shellcheck scripts/update_common_skills_lock
• actionlint .github/workflows/update-downstream-skill-locks.yml
• git diff --check
• Ran the updater twice against an isolated copy of a downstream lockfile; the first run generated all 19 current skills without Git refs, and the second run was a no-op.
• Verified source PR lookup resolves PR Add research and cross-critique skills. #28 to vorporeal.

Co-Authored-By: Oz oz-agent@warp.dev

[vorporeal]

• Automate the process of creating PRs to update lockfiles in other repos. #29 👈 (View in Graphite)
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[oz-for-oss]

@vorporeal

I'm starting a first review of this pull request.

You can view the conversation on Warp.

I completed the review and no human review was requested for this pull request.

Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).

Powered by Oz

[oz-for-oss]

Overview

This PR adds a workflow that propagates common-skills lockfile updates into downstream repositories and a helper script that regenerates an existing skills-lock.json without installing skills into the target checkout.

Concerns

• The updater resolves warpdotdev/common-skills from the default branch at execution time, but the downstream PRs are labeled with the triggering SHA/PR. Overlapping pushes can therefore generate a lockfile for a different commit than the PR claims to distribute.
• No approved or repository spec context was provided, so there was no implementation-vs-spec drift to validate.

Verdict

Found: 0 critical, 1 important, 1 suggestions

Request changes

Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).

Powered by Oz

[oz-for-oss]

⚠️ [IMPORTANT] The updater always resolves whatever is on the default branch when the job happens to run, while the downstream PR title/body point at the triggering SHA or source PR. If two main pushes overlap, an older run can generate a lockfile for a newer commit and open or auto-merge it under the wrong source label; pin the generation to the triggering ref or cancel stale runs before creating downstream PRs.

[vorporeal]

yes, the agent that implemented this brought up the same thing; we decided that the likelihood of this happening is sufficiently low that it's not worth the additional complexity needed to prevent this.

[oz-for-oss]

💡 [SUGGESTION] Invoke the helper through bash so the workflow does not depend on the new script being committed with executable mode.

Suggested change

	common-skills/scripts/update_common_skills_lock --repo-root target
	bash common-skills/scripts/update_common_skills_lock --repo-root target

[vorporeal]

why didn't the agent just check if it was executable...