Request: an official statement on whether external code PRs to first-party skills are reviewed/accepted

[dmwyatt]

The ask: could a maintainer post an official statement, somewhere discoverable (a CONTRIBUTING.md, a note in the README, or a pinned issue/discussion), on whether external code PRs to the first-party skills are reviewed and accepted? There is currently no stated policy, and the observable track record (below) suggests they are not, so people keep spending real effort on fixes that may never be looked at. Even a one-line "we do not take outside code PRs to these skills" would let contributors redirect their effort instead of guessing. If outside code contributions are welcome, a note on where or how to get them triaged would do the same.

I am asking because I measured how the repo has actually responded to community contributions, and the pattern is consistent enough that the absence of a stated policy is itself costing people work. All counts are as of 2026-05-24 and are reproducible from the GitHub search/REST API.

Maintainer engagement (a comment or review from an account with MEMBER/OWNER/COLLABORATOR rights):

• Issues: 0 of the 40 most recently opened issues have a maintainer comment.
• Open PRs, newest: 0 of the 50 most recently opened PRs have a maintainer comment or review.
• Open PRs, oldest: 0 of the 30 oldest still-open PRs (the oldest opened 2025-10-16) have a maintainer comment or review. Age does not change the outcome, so this is not a slow queue.
• Closed PRs: 0 of the 40 most recently closed-unmerged PRs were closed with any maintainer comment or review.
• Discussions: 0 of the 30 most recently active discussions (of 47 total) have a maintainer reply. What's the expected review cadence for community skill submissions? #1089 ("expected review cadence for community skill submissions?") is representative: open since May 4, its only reply is from another external user.

Merges:

• Across all PRs: 35 merged vs 630 open and 185 closed-unmerged (about a 4% merge rate).
• Every merged PR that changed Python code was authored by an Anthropic-affiliated account: klazuka (the repo owner), zack-anthropic, and kencheeto (profile lists @anthropics). The external contributors whose PRs did merge landed only docs/metadata, no code (e.g. quuu and allenzhou101, both @vercel; one was a one-line frontmatter fix).

Affiliation is inferred from public profile and role, not from anything definitive, but it is consistent across every code merge I checked. To be clear, this is not "the repo is dead": Anthropic collaborators merge first-party updates (e.g. the claude-api skill) regularly. The gap is specifically engagement with externally filed code contributions and questions.

Until there is a statement either way, the practical note for contributors: I found no evidence that an externally filed PR here gets reviewed at all, regardless of its age, quality, or outcome. The realistic value of contributing is the public record and helping other users who hit the same bug (you can apply the fix to your own install in the meantime), not a review or a merge.

[hiiqbiz-wq]

Second affected-user voice on this.

I hit a Windows compatibility bug in skill-creator today (issue #1061, fix PRs #1099 and #1050) and walked the trail: original report filed 2026-04-28, fix PRs opened 2026-04-27 and 2026-05-07, multiple independent Windows-user reproductions in each thread, zero maintainer engagement across any of them.

Not isolated to skill-creator either. I have a separate workflow that hits Unicode crashes in generate_review.py repeatedly, with the same silent-no-response pattern.

For context on impact: Claude Code on Windows is my daily-driver development environment. skill-creator is the canonical surface for building and optimizing Claude Code skills. The combination means a meaningful fraction of your power-users are running into ship-blocking bugs in your own tooling, against your own platform, with no signal that submitted fix-PRs will ever be reviewed. The silent-failure pattern in run_eval.py is particularly bad because the broken code succeeds loudly — reports clean exit, fake 0% trigger rate, fake "iterations complete" — meaning users on Windows can run the optimizer for 30 minutes against noise without realizing it's broken.

An official statement helps in either direction:

• "We do review and accept community PRs, here's the backlog and cadence" — sets expectations, lets contributors decide whether the investment is worth it.
• "First-party skills are Anthropic-maintained only; please file issues but don't submit fix PRs" — also fine, just lets contributors stop putting effort into a queue that won't move.

The silence is the worst of both — affected users keep filing well-scoped PRs hoping they'll be reviewed, while the affected codebase keeps shipping broken-on-Windows. The signal-to-noise on these threads is high (real reproductions, byte-identical SHAs, working fixes); the engagement-to-signal is zero.

Andre Valentine
HIIQ Business Solutions
Pacific rig: Win11 Pro 26200 / Python 3.13.13 / uv / claude-code 2.1.145