What's the expected review cadence for community skill submissions?

[idoco2003]

Hi maintainers 👋

We recently submitted PR #1073
(four Haruspex stock-analysis skills) And we're trying to plan our roadmap
around it.
We're mid-scaling on our side, onboarding users, and iterating on
the skill bundles, and deciding how much to invest in keeping the upstream
copies in sync vs. directing people to our canonical repo + npm-published
MCP server.

Is there a rough expected turnaround for community PRs that add new skill
bundles? Even a wide range (days vs. weeks vs. "we batch these quarterly")
would help us plan whether to keep upstreaming routine updates or only
submit at major releases.

Totally understand the queue is large and the team is small, happy to wait, just want to set expectations on our side.
Thanks for the work on this repo and the skills standard.

— Ido (Haruspex)

[UMER-Devtechs]

Hey Ido, this is a really thoughtful and respectful way to ask about PR timelines — more maintainers wish users would communicate like this. Realistically, for community PRs that add new skill bundles, most repos fall into one of three buckets: "days" if they have active maintainers and an automated review pipeline, "weeks" if it's a small team reviewing in batches, or "quarterly" if they only bundle changes around major releases. Looking at the activity on this repo, I'd guess you're looking at somewhere between 2-6 weeks unless you get lucky with timing. My advice? Don't wait around for upstream to merge before moving forward — publish your canonical repo and npm MCP server now, keep building your users, and treat upstream syncs as a "nice to have" rather than a blocker. If the maintainers are responsive, great, you can keep things in sync. If not, your users will just go to your repo directly anyway since that's where the active development is happening. Either way, you're not stuck waiting. Good luck with the scaling!

[idoco2003]

Thanks for your detailed answer, Umer. I really appreciate it.
We do keep going, and waiting for @Anthropic to move it forward.
Have a great week ahead.

[idoco2003]

Thanks for putting this together, Dustin — the data is more damning than I expected when I opened the thread.

Echoing the ask: even a one-line statement of scope would help. Specifically:

1. Are external code PRs to first-party skills (e.g. skill-creator) in scope for review/merge, or is the expectation that contributors fork and patch locally?
2. If they are in scope, is there a rough SLA or a triage label we should watch for?
3. A CONTRIBUTING.md (even a stub) and an issue/PR template would let contributors self-select before investing in a fix.

The duplicated-Windows-fix example is exactly the kind of waste a one-paragraph policy note would prevent. Happy to help draft a CONTRIBUTING.md PR if a maintainer signals it would be reviewed.

[dmwyatt]

Sorry, @idoco2003 I pulled a bad move on you. I made a comment on this thread and then decided to move it to a top level thread over here.

[idoco2003]

Confirming Dustin's analysis matches what we've seen. We'll leave
#1073 open as a record but stop investing in chasing review.
Pivoting to canonical install via our own repo + npm package +
community registries (mcp.so, awesome-mcp-servers, smithery).

Would still welcome any guidance from Anthropic on the in-product
Claude.ai skill directory submission path, different from this
repo, no public process documented.