Guide a Verdaccio change through a pull request, from branch preparation and checks to changelog entries, labels, CI results, and review responses. Track separate pull requests when the fix also belongs on other release lines.
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.
Review the instructions the agent will receive before you install.
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.
git fetch origin master then
git switch -c <type>/<short-name> origin/master (for a port, from origin/6.x).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.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.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.
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:
<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):
gh pr edit <n> --repo verdaccio/verdaccio --add-label "<release line>" --add-label "<content>"
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.
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.gh pr edit --title/--body); the title is what merges.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.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.
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.
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.
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.
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Implement Verdaccio fixes, features, or refactoring after checking whether existing settings or plugins already solve the problem. Place changes in the responsible component, reuse helpers, add tests and release notes, and validate affected packages.
Maintain Verdaccio’s bundled plugins and investigate loading failures using checks that identify resolution, export, construction, or interface problems. Review shared plugin interfaces for compatibility, update affected plugins, and validate fixes with plugin and integration tests.
Select existing labels for Verdaccio pull requests based on the target release line and the substance of the change. Apply them when authorized, or report exact recommendations when reviewing someone else's PR or lacking permission.
Review Verdaccio code changes for security, package manager compatibility, performance, and maintainability. Verify concerns against surrounding code and relevant tests, then report actionable issues with their location, trigger, impact, and supporting evidence.
Assess an existing Verdaccio pull request by checking code changes, automated checks, review feedback, release notes, and supported release branches. Receive a verified report explaining whether it is ready to merge and what needs attention.
Choose and run checks that cover a Verdaccio change, including affected packages, dependent packages, API tests, and relevant client or UI flows. Rebuild first and report coverage limits so passing results reflect the edited code.