docs: correct the README claims that drifted away from the live watch - #119
Merged
Conversation
…links The 2026-07-25 watch reported linkSkips: 8 — the first run where that number was visible at all. All eight are redis-development, and they are not an attack: plugins/redis-development/skills/redis-core -> ../../../skills/redis-core Redis keeps its canonical skills at the top of redis/agent-skills and each plugin symlinks the ones it ships. That is an ordinary monorepo layout. The catalog fetches that plugin as a git-subdir source, so the corpus row points at plugins/redis-development while marketplace-fetch clones the WHOLE repo. The escaping-link rule confined discovery to the row directory, so links reaching one level up resolved "outside" and were refused — even though the targets were sitting in the corpus the whole time. So eight real skills in the official directory have never been scanned. Before the link work they were skipped in silence (lstat isDirectory() is false for a symlink); since then they were at least counted. Now they are scanned. discoverMarketplaceSkills takes `confine`, a boundary that may be an ANCESTOR of the scanned root, and the watch passes the fetched repo (new `repoDir` on each corpus row). Deliberately one-directional: a confine that is not an ancestor is ignored, so a bad value can only narrow the boundary back to the scanned directory, never redirect discovery somewhere unrelated. A link that leaves the repo is still refused and still reported. Verified end-to-end against the real vendor tree at the catalog-pinned sha (3d6f255), staged the way the corpus stages it: before (no repoDir): skills 0, linkSkips 8 after (repoDir) : skills 8, linkSkips 0, poisoned 0, advisories 3 All eight scan clean; the three advisories are capability mentions (a secret env var read, an exfiltration-intent mention in redis-security), none blocking. So this adds coverage without moving the badge. Note on the first attempt: my staging harness set repoDir to the plugin dir itself, the widening correctly did nothing, and the run looked identical. The harness was wrong, not the code — worth stating because "no change" was the right output for the input it was given.
…scan-intra-repo-skill-links
Four factual claims no longer matched reality. Two predate this week.
1. "re-audits all 255 official plugins every Monday" — the cron has been daily
('17 6 * * *') since the 07-20 flip; the README was never updated. Today the
directory is 273 plugins, not 255.
2. "re-scans the full official plugin directory every week" — the same error, a
second time, further down.
3. The pinned-install example still said 0.8.0; npm latest and package.json are
both 0.10.0.
4. The hook install snippet pinned #v0.8.0. `hook install` now derives the tag
from the running build, so the example was showing an older pin than the tool
would actually write.
The plugin COUNT is removed rather than corrected. Any hardcoded number goes
stale the next time the catalog grows — 255 to 258 to 273 in three weeks — and
the badge directly above that sentence already carries the live figure. Prose
naming a number the badge contradicts is worse than prose naming none.
The historical study figures are deliberately untouched: 2,019 skills, 255
catalog plugins and 177 vendor repos, 66,541 on ClawHub, 68,560 total. Those
describe published audits at a point in time and are cited from the blog posts.
Updating them to today would misstate what was actually measured.
Docs only. Nothing about the gate behaviour changed — the two behavioural README
edits from this week (the hook decision-table row for a check that could not
complete, and matching a signer on the whole public key) already shipped with
their own PRs.
sprayberry-reviewer
approved these changes
Jul 25, 2026
sprayberry-reviewer
left a comment
sprayberry-reviewer
left a comment
Collaborator
There was a problem hiding this comment.
Automated review from the Sprayberry Labs fleet code reviewer.
Verdict: Clean docs-only fix — no blocking issues, approving.
What I checked
gh pr diff— the full unified diff (README.md only, 4 lines changed / 4 lines removed, single file).- CI check-rollup (
gh pr checks): CodeQL, analyze, test × 6 platforms/node-versions, and "verify pinned skills" all pass. - Each of the four factual corrections against the PR description's claim table:
README.md:**every Monday**→**every day**(watch cadence hunk 1) — matches the stated cron flip to17 6 * * *(daily).README.md:re-audits all 255 official plugins→re-audits the full official plugin directory— the hardcoded catalog count is removed rather than bumped to today's 273, consistent with the PR's stated rationale (a live badge already carries the real number; a stale hardcoded figure would drift again).README.md:@askalf/truecopy@0.8.0→@askalf/truecopy@0.10.0(pinned-release install line).README.md: hook snippet tag#v0.8.0→#v0.10.0.README.md: the secondevery week→every dayoccurrence further down (hunk 4), the "same error, a second time" the PR body mentions.
- The historical study figures (2,019 skills / 255 catalog plugins / 177 vendor repos / 66,541 / 68,560) are correctly left untouched in the diff — they're cited as point-in-time audit results from the linked blog posts, not live claims, so leaving them alone is the right call.
No logic, no code paths, no test surface changed — this is a pure prose/version-string correction to README.md, and every substitution in the diff traces cleanly to a claim in the PR's before/after table. All CI checks are green.
What's good
Clear before/after table in the PR description made verifying each substitution fast and unambiguous; the choice to remove rather than "fix" the hardcoded plugin count is the more maintainable call given the live badge sitting right above it.
No blocking findings.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Four factual claims no longer matched reality. Two of them predate this week.
17 6 * * *— daily since the 07-20 flip@askalf/truecopy@0.8.0, hook#v0.8.0package.jsonare both 0.10.0The
hook installone mattered a little more than the others: the command now derives its tag from the running build, so the snippet was advertising an older pin than the tool would actually write.Two deliberate choices
The plugin count is removed, not corrected. Any hardcoded number goes stale the next time the catalog grows — 255 → 258 → 273 in three weeks — and the live badge sits directly above that sentence already carrying the real figure. Prose naming a number the badge contradicts is worse than prose naming none.
The historical study figures are untouched — 2,019 skills, "255 catalog plugins, 177 vendor repos", 66,541 on ClawHub, 68,560 total. Those describe published audits at a point in time and are cited from the blog posts. Updating them to today would misstate what was actually measured.
Docs only; no behaviour changed. The two behavioural README edits from this week — the hook decision-table row for a check that could not complete, and matching a signer on the whole public key — already shipped in #111 and #112.