菜单
Score a community Redis client library against the docs team's quality checklist. Use when reviewing a PR or suggestion to add a client library to the redis.io clients page, or when asked to vet/evaluate a Redis client library.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/redis/docs --skill vet-redis-client命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Create or extend tabbed code examples (TCEs) — the multi-language code blocks rendered by the clients-example shortcode. Use when a docs page needs client examples added, when auditing a command page for missing client coverage, when an example set needs a new step, or when a client needs backfilling into an existing set. Covers audit, parallel generation across clients, live testing, and Codex review.
Port a Redis use-case example (cache-aside, session store, rate limiter, leaderboard, etc.) to all 9 supported client libraries in parallel, with cross-client synthesis and audit
Freeze a release-ready-pending-upstream branch as a parked PR — open (or update) the PR with a machine-diffable unpark manifest, apply the parked / do-not-merge labels, and deliberately defer /finalize so the episodic re-check notes survive. Use when docs are written against an unreleased or still-changing external source (an upstream PR, a preview feature) and must wait for it to ship before merging. Pairs with /unpark.
正在显示 SKILL.md
| name | vet-redis-client |
| description | Score a community Redis client library against the docs team's quality checklist. Use when reviewing a PR or suggestion to add a client library to the redis.io clients page, or when asked to vet/evaluate a Redis client library. |
Score a community-supported Redis client library against the docs team's 13-criterion checklist and produce an evidence-backed verdict (Recommend include / Needs discussion / Decline). Every score must cite a URL plus the specific fact observed (e.g. "last release v2.3.1, 2026-05-02"). Reviews, blog posts, project-published benchmarks, and social-media popularity are deliberately excluded as signals — only verifiable repo/registry facts count.
The input is the client's GitHub repository, given as a URL or owner/name. If you are only given a package name, look up the package on its language's registry and follow the registry page's repository/homepage link to find the GitHub repo. If you cannot locate a source repository at all, stop and report that — an unreviewable source is disqualifying on its own.
Use gh or the GitHub API when available; otherwise fetch the public HTML pages. Check all of the following before scoring:
/releases and /tags — release recency and cadence over the last 2 years./commits/<default-branch> — commit dates and distinct author names in the last 12 months (the contributors graph is JS-rendered; the commits list works)./issues?q=is%3Aissue+sort%3Aupdated-desc) and /pulls — maintainer responsiveness and triage./actions tab./security/advisories — open security advisories.A single index returning zero is not evidence of absence. Before scoring any criterion Fail on a missing-from-the-registry or missing-from-the-graph reading, confirm it against the authoritative store, or state that you could not. Three instances that have each been one step away from producing a wrong score on a real submission:
search.maven.org/solrsearch returned 0 hits for com.github.ghostdogpr:sage-core_3 while all seven published versions were sitting in the artifact store. The authoritative check is the store itself: https://repo1.maven.org/maven2/<group/path>/<artifact>/maven-metadata.xml, which lists every version and a lastUpdated stamp.build.sbt, so it reports "0 Repositories / 0 Packages" for any sbt project regardless of real usage. Treat a zero as no-signal, not as a Fail on its own, and say which instrument was blind.mvnrepository.com (which does show a "Used By" count) returns HTTP 403 to scripted requests. It is browser-only; do not cite it as a source that a re-run can reproduce.Score each criterion Pass (2) / Warn (1) / Fail (0). Every criterion's evidence must cite a URL and a concrete fact.
Each criterion's three bands must be mutually exclusive and exhaustive — numeric ones as half-open intervals, qualitative ones as cases. If a plausible project matches two bands, or none, the row is broken rather than the reviewer's judgement: fix the row. This applies to the qualitative criteria exactly as much as the numeric ones; every band gap found in this checklist so far has been in a row whose wording read perfectly well as English.
Where a band offers alternative routes ("X or Y"), every lower band must explicitly exclude those routes — otherwise the tie-break below silently kills the alternative route, and a documented path to Pass becomes unreachable whenever a lower band's condition also happens to hold.
If more than one band still applies, score the lowest one and say in the evidence cell that the row needs repair. A reviewer mid-review cannot rewrite the rubric, and two scorers resolving the same overlap by reading order is the failure this whole section exists to prevent. Prefer restructuring a row around the single axis it measures over appending another "or" clause to a band — an appended clause closes one case and opens an edge against every neighbouring band.
A Fail requires positive evidence of the deficiency, from an instrument known to work for that ecosystem. Where the figure does not exist, or the only instrument available is blind to the project's ecosystem, score Warn and name the gap — not Fail, and not Pass. This rule takes precedence over every band in the tables below: if a band's wording would produce a Fail on nothing more than a missing or unmeasurable reading, the score is Warn and the evidence cell says which instrument was blind. Absence of a claim is not evidence of absence of the thing claimed.
| # | Criterion | Pass (2) | Warn (1) | Fail (0) | Where to look |
|---|---|---|---|---|---|
| A1 | Recent commit activity | Last commit on default branch ≤ 6 months ago | > 6 and ≤ 18 months | > 18 months, or repo archived | GitHub repo front page / …/commits/<default-branch> |
| A2 | Release recency & cadence | ≥ 1 release in last 12 months and visible cadence over the last 2 years | Release in last 12 months but thin/irregular history | No release in 12 months | …/releases, …/tags, registry version list — a release counts whether it is evidenced by a git tag or by a registry publish; score only recency and cadence here, and leave missing tags to C2 |
| A3 | Bus factor | ≥ 2 distinct committers active in the last year | Exactly 1 active committer | 0 active committers in the last year | …/commits author names (contributors graph is JS-rendered; the commits list works) |
| A4 | Responsiveness | Every inbound channel is served: recent issues get maintainer replies and open PRs are triaged | Inbound is served but slowly or inconsistently, or there is too little inbound to judge (give the counts) | Any inbound channel is unserved: issues disabled, or open issues/PRs sitting untouched with no maintainer response | …/issues?q=is%3Aissue+sort%3Aupdated-desc, …/pulls |
| # | Criterion | Pass (2) | Warn (1) | Fail (0) | Where to look |
|---|---|---|---|---|---|
| B1 | Registry downloads | ≥ the ecosystem's Pass threshold, per the table below | ≥ the Fail floor and < the Pass threshold | < the Fail floor | npmjs.com / pypi.org (pepy.tech) / crates.io / pub.dev / packagist.org / nuget.org / hex.pm package page |
| B2 | Downstream usage | ≥ 100 dependents, or ≥ 1 named independent downstream user of real substance | No named user of substance and either 1–99 dependents or no dependents figure obtainable for the ecosystem (state which instrument was blind) | 0 dependents from an instrument that does work for this ecosystem, and none named | GitHub repo sidebar "Used by", …/network/dependents, registry "dependents" tab; for Go, pkg.go.dev's "Imported by" count is a working substitute |
B1 thresholds are ecosystem-relative. State the number you found and the threshold triple you applied. Monthly downloads:
| Ecosystem | Pass | Fail floor |
|---|---|---|
| npm, PyPI | ≥ 100k | < 10k |
| crates.io, packagist, nuget | ≥ 20k | < 2k |
| pub.dev, hex.pm | ≥ 5k | < 500 |
For a registry not listed, pick a triple in proportion to that ecosystem's size and state it — the Pass threshold and a Fail floor an order of magnitude below it, matching the pattern above. Naming all three bands is the requirement; the specific numbers are a starting point a reviewer may override with a stated alternative. Two registries are absent from the table because they publish no figures at all rather than because a triple is missing — do not invent one for them, see the note below.
Ecosystems that publish no download figures at all: Maven Central (JVM — Scala, Java, Kotlin) and pkg.go.dev (Go). B1 is unscoreable there, so cap it at Warn and state that the number does not exist rather than implying the project has poor uptake — the same limitation hits every client in that language. Note the asymmetry: Go loses B1 but keeps B2 via "Imported by", whereas a JVM project's dependents are only visible through named adopters (mvnrepository.com's "Used By" is browser-only, per the traps above).
| # | Criterion | Pass (2) | Warn (1) | Fail (0) | Where to look |
|---|---|---|---|---|---|
| C1 | CI + tests | A real test suite, run by CI, green on the default branch | A real test suite exists but CI does not run it green — absent, red, or lint/build only | No meaningful test suite, whatever CI does | README badges, …/actions, test/ or spec/ dirs |
| C2 | Release hygiene | On the official registry, versions ordered under a consistently applied scheme (semver, CalVer or similar), changelog/release notes maintained, and published versions traceable to a source state (git tags or equivalent) | On the registry with consistent versioning but missing either or both of the other two — no changelog, or no tags to trace versions to | Not on the official registry, or versioning inconsistent enough that release order is unclear | Registry page + changelog tab, …/tags vs registry versions (on the JVM, diff the tags against repo1.maven.org/maven2/…/maven-metadata.xml, not the search index). Publisher verification (npm provenance, PyPI trusted publishing, signed artifacts) is worth recording as a note where the registry shows it, but is not scored — most ecosystems do not expose it, so scoring it would penalise the language rather than the project |
| C3 | License & security | OSI-approved license, and the advisories endpoint answers with none open | OSI-approved license, but advisory status cannot be established (endpoint unavailable, advisories not enabled) | Non-OSI or no license, or an open unpatched advisory | Repo sidebar License, …/security/advisories |
| # | Criterion | Pass (2) | Warn (1) | Fail (0) | Where to look |
|---|---|---|---|---|---|
| D1 | Modern feature coverage (RESP3, cluster, TLS, ACL/AUTH, pub/sub, pipelining) | ≥ 4 of these 6 covered | 2–3 covered | ≤ 1 covered | README feature list, changelog, API reference (search for RESP3/cluster/TLS/subscribe/pipeline) |
| D2 | Stated Redis version compatibility | Docs explicitly state compatibility with a current major — Redis 7.x or later | Stated but only for an older range (≤ 6.x), or stated without version detail, or unstated but implied by recent feature work | No statement, and nothing implying one | README, docs site, CI matrix |
| # | Criterion | Pass (2) | Warn (1) | Fail (0) | Where to look |
|---|---|---|---|---|---|
| E1 | Quickstart | Install → connect → set/get a fresh user can follow, in the README or one hop from it | Partial (examples exist but no clean end-to-end path, or non-English gaps) | No usable quickstart anywhere | Repo README and the page it links to for getting started (a quickstart on the docs site counts; note where it lives, since a README with no inline snippet is worth saying out loud) |
| E2 | Docs beyond README | Hand-written guides or a hand-written docs site beyond the README, currently maintained | A generated API reference only, however current it is (docs.rs, dartdoc, javadoc, readthedocs autodoc), or hand-written docs that are no longer maintained (say how you can tell) | Nothing beyond README | Docs link in README/registry sidebar (readthedocs, pub.dev dartdoc, docs.rs, etc.) — the quickstart already scored in E1 does not by itself satisfy this; E2 asks what exists beyond it |
13 criteria × 2 points = 26 max.
| Total | Verdict |
|---|---|
| ≥ 21 | Recommend include |
| 14–20 | Needs discussion (list the specific Warn/Fail items to resolve) |
| < 14 | Decline (cite the failing criteria in the PR response) |
Hard stops regardless of total: archived repo, no OSI license, or open unpatched security advisory → Decline. Check these first; if one applies, still complete the scorecard for the record, but the verdict is Decline no matter the total.
Produce, in this order:
Keep observations that are not criteria out of the scorecard and out of anything published — note them separately for the reviewer. They carry no score, and in a public reply they read as a judgement on the author rather than on the library.
Do not save the scorecard as a file in this repo: readers expect a checked-in file to be current, and half of a scorecard's facts (open-issue counts, "last commit 5 days ago", the total itself) are false within months. A dated snapshot belongs somewhere that is understood to be a snapshot.
On an accept, put it in the squash commit message of the PR that adds the table row. That commit touches exactly the one line being justified, so git blame on the row leads a future reviewer straight to the evidence. Write it as a snapshot: name the review date and the version observed, keep the four-or-so non-Pass criteria in full with their evidence, and compress the passes to a single line — a Pass is cheap to re-derive, whereas why a criterion was scored down (and what instrument was blind when it was) is not.
Anchor it with trailers so the set stays enumerable across reviews (git log --grep='^Vetted:'), using the vocabulary in .claude/skills/_shared/commit-trailers.md:
Vetted: <library> <n>/26 <verdict> <YYYY-MM-DD>
Gaps: <what could not be measured, and which instrument was blind>
Recheck: <expiry condition — an age, or a signal such as the sole maintainer going quiet>
This repo squashes with squash_merge_commit_message = COMMIT_MESSAGES, so the default body is the contributor's WIP commits concatenated and the scorecard is silently discarded. Override it explicitly:
gh pr merge <n> --squash --subject "<subject>" --body-file <scorecard-file>
On a decline, the PR reply comment is the record — a closed PR is still discoverable by searching the repo URL. There is no commit to carry it, so the accept and decline paths are deliberately asymmetric; a queryable data file only earns its place if the volume of reviews ever makes that gap hurt.