review-renovate
# Review Renovate GitHub Actions PRs The review-renovate skill validates Renovate bot pull requests that update GitHub Actions dependencies by verifying supply chain integrity through SHA pinning verification, detecting breaking changes in release notes, and confirming workflow compatibility. Use this skill when a Renovate PR modifies GitHub Actions versions in .github/workflows/ files to ensure CI/CD pipelines remain functional and secure after the automated dependency update.
git clone --depth 1 https://github.com/backnotprop/plannotator /tmp/review-renovate && cp -r /tmp/review-renovate/.agents/skills/review-renovate ~/.claude/skills/review-renovateSKILL.md
# Review Renovate GitHub Actions PRs
You are reviewing a Renovate bot PR that updates GitHub Actions dependencies. Your job is to verify supply chain integrity and ensure the upgrades won't break CI/CD workflows.
## Inputs
You will be given a PR number or URL. Use `gh` CLI to fetch PR details and diff.
## Steps
### 1. Fetch PR metadata and diff
```
gh pr view <PR> --json title,body,files,commits,author,headRefName
gh pr diff <PR>
```
Confirm the PR author is `app/renovate`. If not, flag this immediately — it may not be an automated dependency update.
### 2. Identify all action version changes
From the diff, extract each changed action:
- Full action name (e.g., `oven-sh/setup-bun`)
- Old version tag and pinned SHA
- New version tag and pinned SHA
- Update type (patch, minor, major)
### 3. Verify pinned SHAs against upstream tags
For every action being updated, verify **both old and new** SHAs match the claimed version tags:
```
gh api repos/{owner}/{repo}/git/ref/tags/{version} --jq '.object.sha'
```
Compare each result against the SHA in the workflow file. If any SHA does not match, **stop and report a supply chain integrity failure**. Do not approve the PR.
### 4. Review changelogs for breaking changes
From the PR body (Renovate includes release notes), check each updated action for:
- Removed inputs or outputs that the workflows currently use
- Changed default behavior for inputs the workflows rely on
- New required inputs
- Major version bumps (these almost always have breaking changes)
### 5. Check workflow compatibility
Read the affected workflow files and verify:
- No removed or renamed inputs are being used
- No changed defaults affect current behavior
- The action's runtime requirements are still met (e.g., Node.js version compatibility)
### 6. Report findings
Present a summary table:
| Action | Old | New | Type | SHA verified |
|--------|-----|-----|------|-------------|
| ... | ... | ... | patch/minor/major | yes/NO |
Then state:
- Whether all SHAs are verified
- Whether any breaking changes were found
- Whether the workflows remain compatible
- A clear **safe to merge** or **do not merge** recommendationGuard against breaking the @pierre/diffs integration in Plannotator's code review UI. Use this skill whenever modifying DiffViewer.tsx, upgrading the @pierre/diffs package, changing unsafeCSS injection, adding new props to FileDiff, or touching shadow DOM selectors or CSS variables that cross into Pierre's shadow boundary. Also trigger when someone asks "will this break the diff viewer", "is this safe to change", or when reviewing PRs that touch the review-editor package.
Prepare and execute a Plannotator release — draft release notes with full contributor credit, bump versions across all package files, build in dependency order, and kick off the tag-driven release pipeline. Use this skill whenever the user mentions preparing a release, bumping versions, writing release notes, tagging a release, or publishing. Also trigger when the user says things like "let's ship", "prep a release", "what's changed since last release", or "time to cut a new version".
Audit and update npm/Bun dependencies with supply chain integrity checks — verifies maintainers, publish age, tarball diffs, and provenance before bumping. Defers risky packages to ~/.supply-chain/notes/.
Open Plannotator's annotation UI for a markdown file, converted HTML file, URL, or folder and then respond to the returned annotations.
Open Plannotator's browser-based code review UI for the current worktree or a pull request URL, then act on the feedback that comes back.
Open Plannotator on the latest rendered assistant message and use the returned annotations to revise that message or continue.
>
Turn an idea or objective into a goal package for /goal. Interviews the user, builds a reviewed fact sheet via Plannotator, then explores the codebase to produce an execution plan.