New: 97,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Verdaccio Pull Request Workflow

by verdaccio in verdaccio/verdaccio

Takes a change through a verdaccio pull request: branch, local checks, changeset, title and body, labels, CI and review rounds, and ports to other release lines.

MITAuto-check passedDevelopment

Install Verdaccio Pull Request Workflow

skills CLI
$ npx skills add verdaccio/verdaccio --skill pull-requests -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install verdaccio/verdaccio pull-requests --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/verdaccio/verdaccio.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.agents/skills/pull-requests .claude/skills/pull-requests && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
pull-requests
GitHub stars
18k
Token cost
~1.9k tokens
SKILL.md length
1,106 words
Files
1
Skills in repo
8
Repo updated
First seen
Licence
MIT

At a glance

Takes a change through a verdaccio pull request: branch, local checks, changeset, title and body, labels, CI and review rounds, and ports to other release lines.

  • Works in 5 steps: Branch from the current base: git fetch… → Run the checks that cover the change… → Add one changeset for the PR, naming… → …
  • Opening a pull request against verdaccio/verdaccio
  • SKILL.md covers Before opening, Opening, Draft or ready and After every push, plus 3 more sections
  • Calls gh, git and pnpm

What it does

The skill defines done as green checks, a review round with nothing left to act on, and every release line that needs the change having its own PR or an explicit note that the port is pending. Before opening, the agent branches from the current base (origin/master, or origin/6.x for a port), runs the checks that cover the change plus pnpm lint, pnpm format:check and a type check, adds one changeset naming each published package it touches, reviews its own diff and confirms the husky hooks are installed, never skipping them with --no-verify. CI does not run on draft PRs, so the local pass is the only gate until the PR is ready.

Commit messages and titles are lowercase Conventional Commits with no AI attribution trailers, and the PR title becomes the squash commit. Port PRs say which line they target, for example fix(6.x). The body is brief, a few sentences a reviewer needs. The PR is opened with gh pr create against verdaccio/verdaccio, as a draft if wanted, or from GitHub's compare page when gh is missing. The agent pushes only when you or the calling workflow authorized it, and the description adds the CI and review rounds that follow each push.

When your agent uses it

  • Opening a pull request against verdaccio/verdaccio
  • Responding to a failing check or review comments after a push
  • Porting a fix to another release line with its own PR
  • Deciding whether a change needs a changeset

Example prompts

  • “Open a draft PR for this fix against master, with a changeset.”
  • “CI failed on my verdaccio PR. Look at the failing check and fix it.”
  • “Port this change to the 6.x line and open the PR with the right title suffix.”

Requirements

  • Git, pnpm and the GitHub CLI (gh)
  • A checkout of verdaccio/verdaccio with the husky hooks installed

Workflow steps

5 steps, taken from the first numbered list in SKILL.md.

  1. Branch from the current base: git fetch origin master then
  2. Run the checks that cover the change with the
  3. Add one changeset for the PR, naming every published package it touches
  4. Review your own diff with the review-code skill. A
  5. Confirm the husky hooks are installed (git config core.hooksPath points at

What it can do on your machine

Read from SKILL.md and the folder at commit 2d3bcca. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • gh
    • git
    • pnpm

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use gh, git and pnpm, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Verdaccio Pull Request Workflow loads about 1.9k tokens when it runs. Until then it costs about 81 tokens; SKILL.md has 1,106 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~81
When it runs · the whole SKILL.md, loaded when a task matches
~1.9k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from verdaccio/verdaccio at commit 2d3bcca, republished under its MIT licence (© verdaccio). 1,106 words, ~1,869 tokens.

Download SKILL.mdSave it as .claude/skills/pull-requests/SKILL.md (or your agent's skills folder).
name
pull-requests
description
Take a change through a verdaccio/verdaccio pull request — branch, checks, changeset, title, body, labels, draft-to-ready, then the CI and review rounds after every push, plus the port PRs to other release lines. Use when opening a PR, after pushing to one, when a check fails, or when review comments arrive.

Pull requests

Opening the PR is the middle of the task. It is done when the checks are green, the review round has nothing left to act on, and every release line that needs the change has its own PR or an explicit note that the port is pending.

Read the commit and label rules in AGENTS.md first; this skill is the workflow around them.

Before opening

  1. Branch from the current base: git fetch origin master then git switch -c <type>/<short-name> origin/master (for a port, from origin/6.x).
  2. Run the checks that cover the change with the testing-changes skill, then pnpm lint, pnpm format:check, and the type check for touched packages. CI does not run on draft PRs, so this local pass is the only gate until the PR is marked ready.
  3. Add one changeset for the PR, naming every published package it touches (pnpm changeset or a hand-written .changeset/<slug>.md), when a published package changed. Otherwise say in the PR body why none is needed; the skip changeset label is applied by a maintainer, never by an external author.
  4. Review your own diff with the review-code skill. A finding caught here costs one commit; the same finding caught by a reviewer costs a round.
  5. Confirm the husky hooks are installed (git config core.hooksPath points at .husky/_); commit normally so the pre-commit format, lint, and lockfile checks run. Never --no-verify.

Commit messages are lowercase Conventional Commits, no AI attribution trailers. Push only when the user or calling workflow authorised it.

Opening

bash
gh pr create --repo verdaccio/verdaccio --base master --title "fix(store): <what changed>" --body-file <body.md> [--draft]

Without gh, push the branch and open the PR from the compare page GitHub prints in the push output (or https://github.com/verdaccio/verdaccio/compare); the title, body, labels, and draft checkbox are all on that form. Checks, review threads, and mergeability are on the PR page; labels are in its sidebar (see pr-labels for the API form).

Title: lowercase, Conventional Commits, scope optional. It becomes the squash commit, so write the history entry you want. Port PRs say which line they target: fix(6.x): ... or the same title suffixed (6.x).

Body: brief. A few sentences a reviewer needs to understand the diff and nothing else:

markdown
<problem in one or two sentences, with the issue link when there is one: Closes verdaccio/verdaccio#NNNN>

<the approach in a sentence or two, and any decision a reviewer might question>

No test plan, no validation log, no file-by-file walkthrough, no "not included" section; a pending port or follow-up is one sentence. No attribution footer. The changeset is where the change is explained in full for users (it is the changelog entry), so put the effort there and do not repeat it in the body. What you ran goes in your report to the person who asked, not in the PR.

Labels, immediately after creation (a PR without labels is not finished): exactly one release-line label (7.x branch (next) for master, 6.x branch (latest) for 6.x) plus content labels (typically one to three). The pr-labels skill has the taxonomy, the worked examples, the label you never apply (security) and the one you apply only to your own PR when the author says so (AI assisted):

bash
gh pr edit <n> --repo verdaccio/verdaccio --add-label "<release line>" --add-label "<content>"

Draft or ready

CI runs only on ready PRs, and an automated reviewer, when one is enabled on the repository, re-reviews on every push to one. Open as a draft while the change is still moving and the local checks are your only gate; mark it ready (gh pr ready <n>) as soon as the diff is what you want reviewed. Do not leave a draft behind silently: either mark it ready or say in the body what is left.

Show full SKILL.md (537 more words)Show less

After every push

  1. Wait for the checks. gh pr checks <n> --watch in the background, or poll. Watch to the end: the next push cancels the in-progress run, so a second failure you never saw costs another cycle.
  2. Read the whole round. Inline threads, review bodies, and any summary comment from an automated reviewer if one ran. A bot is not guaranteed on this repository; a round with no bot comment is not a failure, and a human review is what merges the PR.
  3. Verify every finding before acting; bots and humans alike are sometimes wrong, and a fix applied to a wrong finding is a new bug with a reviewer's blessing. Reply on each thread with the commit that fixed it (after it is on the remote) or the reason you are not acting, then resolve the thread. Replying and resolving are part of driving your own PR; posting anything else needs an explicit ask.
  4. Keep the title and body true. Re-read them after any push that changes what the PR does and edit them (gh pr edit --title/--body); the title is what merges.
  5. Check mergeability (gh pr view <n> --json mergeable,mergeStateStatus). CONFLICTING means rebase (git rebase origin/<base>; a lockfile conflict is resolved by pnpm install), then force-push with lease. Re-read the diff after a rebase. Do not merge the base into the branch.
  6. Go back to 1 after the push that carries the fixes. Send fixes in one push; every push restarts any automated review that is running.

A round is finished when the checks are green, every reviewer who took part has reported on the head commit, and none of it needs action. A quiet round is the stop signal, not a round count; if nobody has reviewed yet, the PR is simply waiting for a maintainer, and that wait is not yours to fill with pushes.

Failing checks

Never write a failure off as pre-existing, flaky, or unrelated without evidence. gh run view <run-id> --log-failed, reproduce it locally with the testing-changes selection, fix the cause. The e2e CLI matrix fails per client; a failure in one client is a compatibility finding, not noise. The changeset-check job fails on a PR without a changeset unless a maintainer has labelled it skip changeset.

Ports to other release lines

A bug fix on master that also exists on 6.x (binary) or 8.x (internal modules 6.x consumes) is not finished until each affected line has its own PR. Cherry-pick onto a branch from that line, adapt (6.x uses yarn and an older toolchain; code may have diverged), run that line's tests there, open the PR against that branch with the matching release-line label, and link the original PR in the body. If the port is deferred, say so in one sentence in the original PR body.

Finishing

Report which findings were real, which were not, what was declined and why, the CI state, and which ports exist or are pending. Do not add AI attribution anywhere on the PR; the AI assisted label is how AI involvement is disclosed. The author adds it to their own PR (apply it when the author tells you to), and maintainers may add it too.

© verdaccio, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .agents/skills/pull-requests of verdaccio/verdaccio.

Open the folder on GitHubat commit 2d3bcca

Compare with similar skills

Verdaccio Pull Request Workflow next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Verdaccio Pull Request Workflow compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Verdaccio Pull Request Workflow this skillverdaccio/verdaccio18k—~1.9kAutomated safety check: PassMIT
ZCF Release AutomationUfoMiao/zcf6.1k—~3.4kAutomated safety check: PassMIT
Release Clawpatchopenclaw/clawpatch813—~1.1kAutomated safety check: PassMIT
Prisma Release PRprisma/orm48k—~4kAutomated safety check: PassApache-2.0
Releasecyanfish-x/tellux207—~1.3kAutomated safety check: PassMIT
Nylas Nodejs Releasenylas/nylas-nodejs181—~1.6kAutomated safety check: WarnMIT

Similar skills

  • ZCF Release Automation

    UfoMiao/zcf

    Automates a version release with changesets: analyzes code changes, writes a bilingual CHANGELOG, bumps the version and commits through a release branch and pull request.

    6.1k GitHub stars~3.4k tokensUpdated 1 mo ago
    DevelopmentAuto-check passed

  • Release Clawpatch

    openclaw/clawpatch

    clawpatch release: version/changelog, CI, npm publish, GitHub release, verify.

    813 GitHub stars~1.1k tokensUpdated 2 days ago
    DevelopmentAuto-check passed

  • Prisma Release PR

    prisma/orm

    Official

    Helps a Prisma 8 maintainer cut the next release by bumping the version across every workspace package, opening the release PR and preparing the docs PR.

    48k GitHub stars~4k tokensUpdated today
    DevelopmentAuto-check passed

  • Release

    cyanfish-x/tellux

    Cut and publish a new tellux release — bump version, curate a changelog summary from recent commits, pause for the user to manually pnpm publish (browser 2FA), then push the tag and create the…

    207 GitHub stars~1.3k tokensUpdated 16 days ago
    DevelopmentAuto-check passed

  • Nylas Nodejs Release

    nylas/nylas-nodejs

    Prepares nylas-nodejs SDK releases on a versioned release branch with CHANGELOG updates, version bump, git tag, and PR body.

    181 GitHub stars~1.6k tokensUpdated 4 days ago
    DevelopmentAuto-check: warnings

  • Release

    emanuelcasco/pi-mono-extensions

    Release a new version of pi-extensions: bump individual package versions (independent mode), update CHANGELOGs and READMEs, create per-package git tags, publish a GitHub release, and publish…

    106 GitHub stars~2.3k tokensUpdated 1 mo ago
    DevelopmentAuto-check passed

More from verdaccio/verdaccio

All 8 skills in this repo

  • Verdaccio PR Review

    verdaccio/verdaccio

    Reviews an existing verdaccio/verdaccio pull request end to end, verifies each finding and reports whether it is mergeable, optionally fixing it on the PR branch.

    18k GitHub stars~1.7k tokensUpdated today
    Auto-check passed

  • Verdaccio Issue Triage

    verdaccio/verdaccio

    Triages an incoming verdaccio/verdaccio issue against the code, the affected release line and related issues, and picks labels from the repository's existing taxonomy.

    18k GitHub stars~2.4k tokensUpdated today
    Auto-check passed

  • Verdaccio Code Review

    verdaccio/verdaccio

    Reviews a verdaccio diff, branch or PR against the repository's review guide, verifies each finding in the code and reports only actionable issues.

    18k GitHub stars~853 tokensUpdated today
    Auto-check passed

  • Verdaccio Change Testing Selector

    verdaccio/verdaccio

    Figures out which rebuild and test suites actually cover a change in the verdaccio monorepo, instead of a scoped run that passes untested.

    18k GitHub stars~1.6k tokensUpdated today
    Auto-check: warnings

  • Verdaccio Change Implementation

    verdaccio/verdaccio

    A workflow for implementing a Verdaccio bug fix, feature or refactor: pick the release lines, check existing options, edit the owning layer, test and add a changeset.

    18k GitHub stars~1.3k tokensUpdated today
    Auto-check passed

  • Verdaccio Plugin Maintenance

    verdaccio/verdaccio

    Maintains Verdaccio's bundled plugins and the plugin contracts in @verdaccio/core, and diagnoses plugin loading problems.

    18k GitHub stars~3k tokensUpdated today
    Auto-check passed

Works with

Categories

Questions about Verdaccio Pull Request Workflow

What does Verdaccio Pull Request Workflow do?

Takes a change through a verdaccio pull request: branch, local checks, changeset, title and body, labels, CI and review rounds, and ports to other release lines. The skill defines done as green checks, a review round with nothing left to act on, and every release line that needs the change having its own PR or an explicit note that the port is pending.x for a port), runs the checks that cover the change plus pnpm lint, pnpm format:check and a type check, adds one changeset naming each published package it touches, reviews its own diff and confirms the husky hooks are installed, never skipping them with --no-verify.

When should I use Verdaccio Pull Request Workflow?

Verdaccio Pull Request Workflow fits situations like: opening a pull request against verdaccio/verdaccio; responding to a failing check or review comments after a push; porting a fix to another release line with its own PR; deciding whether a change needs a changeset.

How do I install Verdaccio Pull Request Workflow in Claude Code?

Run `npx skills add verdaccio/verdaccio --skill pull-requests -a claude-code`. Or copy the skill folder (.agents/skills/pull-requests in verdaccio/verdaccio) into .claude/skills/pull-requests in your project. Claude Code loads it when a task matches its description.

How do I install Verdaccio Pull Request Workflow in Codex?

Run `npx skills add verdaccio/verdaccio --skill pull-requests -a codex`. Or copy the skill folder (.agents/skills/pull-requests in verdaccio/verdaccio) into .agents/skills/pull-requests in your project. Codex loads it when a task matches its description.

Can I use Verdaccio Pull Request Workflow in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add verdaccio/verdaccio --skill pull-requests -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/pull-requests, .gemini/skills/pull-requests, .github/skills/pull-requests and .opencode/skills/pull-requests in your project.

What does Verdaccio Pull Request Workflow need to run?

Going by SKILL.md and its folder, Verdaccio Pull Request Workflow needs the command-line tools its instructions call (gh, git and pnpm). Our summary lists: Git, pnpm and the GitHub CLI (gh); A checkout of verdaccio/verdaccio with the husky hooks installed.

Does Verdaccio Pull Request Workflow access the network?

SKILL.md contains no URLs. Its commands use gh and git, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Verdaccio Pull Request Workflow safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Verdaccio Pull Request Workflow use?

Verdaccio Pull Request Workflow is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Verdaccio Pull Request Workflow use?

About 1.9k tokens (SKILL.md is roughly 7.5k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Verdaccio Pull Request Workflow?

Skills that share tags, products or a category with Verdaccio Pull Request Workflow: ZCF Release Automation (UfoMiao/zcf, 6.1k stars), Release Clawpatch (openclaw/clawpatch, 813 stars), Prisma Release PR (prisma/orm, 48k stars) and Release (cyanfish-x/tellux, 207 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Verdaccio Pull Request Workflow?

verdaccio (a GitHub organization) maintains it in verdaccio/verdaccio, which has 17,913 GitHub stars. The repository holds 8 skills in this directory. The repository was last updated on October 6, 2026.

Source: verdaccio/verdaccio on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.