Publish repo
Skill Paldom/skillskit/skills/create-skill-repo/assets/template/.claude/skills/publish-repo
From context to installable agent skills - research packs in, validated skills.sh-ready skills out. Scaffolding, eval-first authoring, validation, and deployment included.
npx -y skills add Paldom/skillskit --skill publish-repoAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Publishes this Agent Skills repository to skills.sh - pre-flight checks, public visibility flip, protections (PVR, ruleset), consumer-style install verification, telemetry seeding, and repo-page groupings. Use when the user asks to publish, deploy, release, go public, or get listed on skills.sh. Not for authoring skills or editing scaffold infrastructure.
SKILL.md
7.6 KB, as published. Nobody here has run it
publish-repo
Deploys this repository to the skills.sh ecosystem. There is no publish API — deployment = a public, installable repo plus a first install that seeds the catalogue telemetry. This skill makes that sequence deliberate instead of ad hoc. Slash-invoked only: it flips repository visibility, which is hard to undo socially (anything ever pushed becomes visible).
When NOT to use
- Writing or fixing a skill →
add-skill. - The repo has zero skills under
skills/→ build first; never publish an empty catalogue. - Routine pushes to an already-public repo → plain git.
Workflow
- Pre-flight (hard gates — stop on any failure): the working tree must be
clean and pushed by the owner — this skill never runs
git commitorgit push; if there are uncommitted changes, stop and hand the list to the owner instead.
Triage everygit status --porcelain # must be empty make check # must end: 0 error(s) — includes skills.sh.json schema shape npx skills@latest add . --list # every skill under skills/ discovered (@latest: a stale npx cache lies) gh skill publish --dry-run # spec validation (needs gh >= 2.90; older gh: skip, use the step-6 fallback) env | grep -E 'DISABLE_TELEMETRY|DO_NOT_TRACK|^CI=' || true # any hit -> the step-7 seed MUST use env -ugh skillwarning: add missinglicense: MITfrontmatter; the.claude/skills/warning is expected here (bundled first-party dev skills, committed by design — not third-party content). Those dev skills carrymetadata.internal: true, so consumer installs skip them — they must NOT appear inadd . --list; maintainers opt back in withINSTALL_INTERNAL_SKILLS=1or--include-internal. Also verify: README catalogue- CHANGELOG current; every skill description is benefit-led (it is the listing copy); CI green on the latest commit.
- Manual blockers — require explicit user confirmation, never assume:
- full-history secret scan (gitleaks/trufflehog) done;
- personal/private-file review done (everything ever committed goes public).
With
--dry-runin$ARGUMENTS, stop here and report readiness instead.
- Groupings: ensure
skills.sh.jsonlists every skill in exactly one group with an engaging one-sentence description per group (see docs/deploying.md). - Flip visibility (confirm with the user immediately before):
gh repo edit <owner>/<repo> --visibility public --accept-visibility-change-consequences - Protections (public repo unlocks them):
Add a default-branch ruleset. Solo-maintainer default: block force pushes and deletions only (a require-PR rule would block the owner's direct-push workflow); when outside contributors arrive, upgrade to require-PR + code-owner review + thegh api repos/<owner>/<repo>/private-vulnerability-reporting --method PUTvalidatecheck. Also add a tag ruleset onv*(block update + deletion) so published releases are immutable. - Release — cut a versioned GitHub release matching
.claude-plugin/plugin.json:
It re-validates, adds thegh skill publish --tag v<version>agent-skillstopic if missing, and creates the release with auto-generated notes. Add theskills-shtopic too:gh repo edit <owner>/<repo> --add-topic skills-sh.gh< 2.90 has nogh skill— equivalent fallback:gh release create v<version> --generate-notes gh repo edit <owner>/<repo> --add-topic agent-skills --add-topic skills-sh - Verify like a consumer, and seed the catalogue. The first real install is
what lists the repo — and the CLI reports it ONLY when
DISABLE_TELEMETRY,DO_NOT_TRACK, and CI variables are all fully unset (any value disables, even0orfalse— env strings are truthy). Run locally, never in CI, with the opt-outs explicitly unset for these commands only:
Then confirm the listing:npx skills@latest add <owner>/<repo> --list mkdir -p /tmp/skills-verify && cd /tmp/skills-verify env -u DISABLE_TELEMETRY -u DO_NOT_TRACK npx skills@latest add <owner>/<repo> -a claude-code -y # NO --skill '*': the wildcard opts into internal dev skills npx skills list -a claude-codecurl -sIL https://skills.sh/<owner>/<repo>turns 200 within minutes of a valid seed (canonical URL is lowercase on www.skills.sh; the search API lags the page). Still 404 after ~15 minutes means the telemetry never fired — re-check the env, don't wait on "cache". Publishing SEVERAL repos? Seed them ONE at a time, ~5 minutes apart, and confirm each page before the next: burst install events for multiple unlisted repos from one machine are throttled server-side — the security audit still runs but the listings never materialize, and re-seeding inside the burst does nothing. A single spaced event lists within ~5 minutes. - Polish: the README carries the skills.sh badge
(
[](https://skills.sh/<owner>/<repo>)— scaffolded by default); set the homepage (gh repo edit --homepage, e.g. tohttps://skills.sh/<owner>/<repo>); remind about the social preview image (manual UI step). - Report: repo URL, skills.sh page URL, install command, release tag, protections applied, what was skipped (with unlock conditions), and the note that the skills.sh page appears after telemetry processes the seed install (pages are cached).
Output spec
Public repo installable via npx skills add <owner>/<repo> (verified by an
actual install), PVR enabled, ruleset active, skills.sh.json valid with every
skill grouped, seed install performed, user told exactly what to expect next.
Gotchas
- Visibility flip is the point of no return for history — that is why step 2 demands explicit confirmation and never self-certifies.
npx skills add . --listfailing with "No skills found" means frontmatter or layout problems — fix viamake checkoutput, never by restructuring blindly.- Telemetry opt-outs silently kill the listing:
DISABLE_TELEMETRYorDO_NOT_TRACKset to ANY value (even0/false) stops the install report — the page then 404s forever while every install "succeeds". Always seed viaenv -u DISABLE_TELEMETRY -u DO_NOT_TRACK. - Pin
npx skills@latest— npx happily reuses a stale cached CLI version. - The badge endpoint (
skills.sh/b/...) returns 200 even for unlisted repos — it proves nothing; only the repo page URL does. - The page appears within minutes of a valid seed install; the search API and leaderboard lag longer. A 404 beyond ~15 minutes = suppressed telemetry — or a burst: seeding several unlisted repos back-to-back from one machine gets throttled; space seeds ~5 minutes apart, one repo at a time.
- Agent harnesses may permission-block the visibility flip and release commands (public-surface actions): hand the exact command to the owner to run themselves instead of retrying.
- Do not enable a require-PR ruleset on a solo repo whose workflow pushes to main directly — it will block the owner; use the staged default in step 5.