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.
インストール方法を見るインストールする前に、エージェントに与えられる指示の中身を確認できます。
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.
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
Implement a verdaccio bug fix, feature, or refactor — establish the affected release lines, check whether existing configuration, package-access rules, plugins, or uplink options already solve it, put the change in the layer that owns it, reuse existing helpers, add tests and a changeset, and validate. Use when asked to implement a change in this repository.
日本語の概要は準備中です。原文の説明を表示しています。
Maintain the plugins bundled in this repository (htpasswd, local-storage, auth-memory, memory, audit, package-filter, ui-theme) and the plugin contracts in @verdaccio/core — fix a bundled plugin, change a pluginUtils interface safely, diagnose why a plugin does not load, or verify a plugin with @verdaccio/plugin-verifier. Use when a task touches packages/plugins, packages/loaders, pluginUtils, or a plugin loading problem. Requests to add a new bundled plugin are gated on an accepted discussion thread; this skill says how to handle them.
日本語の概要は準備中です。原文の説明を表示しています。
Choose and apply the labels for a verdaccio/verdaccio pull request — exactly one release-line label plus content labels from the repository's existing taxonomy (typically one to three, more for a genuinely large multi-topic PR), never security, and AI assisted only on the author's own PR. Use right after gh pr create, when editing a PR, when reviewing a PR whose labels are missing or wrong, or when asked which labels a change should carry.
日本語の概要は準備中です。原文の説明を表示しています。
Review a verdaccio diff, branch, or pull request against the repository review guide (security first, then npm-client compatibility, performance, product fit, maintainability), verify each finding against the code, and report actionable issues. Use for code reviews and for reviewing your own changes before or during a PR workflow.
日本語の概要は準備中です。原文の説明を表示しています。
Review an existing verdaccio/verdaccio pull request end to end — description, diff, review threads, CI, labels, changeset, release-line coverage — verify the findings, and report them; optionally fix them on the PR branch when asked. Use when given a PR number or URL to review, re-review, or "review and fix".
日本語の概要は準備中です。原文の説明を表示しています。
Select and run the checks that actually cover a change in the verdaccio monorepo — rebuild the touched packages, run their tests and their dependents' tests, the api integration suite, the e2e CLI battery or the Cypress UI suite when the change is client- or UI-visible — and recognise the cases where a scoped run passes without testing anything. Use whenever verifying a change before committing or pushing, or when deciding what to run after an edit.
日本語の概要は準備中です。原文の説明を表示しています。