octrow/octrow-skills

repo-publish is a skill for Claude Code and Claude Tag that takes a working project to a public GitHub repo a
stranger can find, trust and install. It reads the repo and its history before anything goes public, then does the
publishing work in a safe order and hands parts to other skills when they're installed.
Install
Claude Code:
Other agents (Codex, Cursor, Gemini CLI and more) via skills:
From a local clone: claude plugin marketplace add ./octrow-skills.
The same marketplace has repo-scout, a skill that finds GitHub repos to
build on before you write your own: claude plugin install repo-scout@octrow-skills. It drives the repo-scout CLI,
so install that first (one command, see its README).
Claude Tag: an admin registers this repository under Organization settings → Plugins & skills → Sync from GitHub,
then adds the plugin to a bundle.
Then ask in a project: "prepare this repo for publishing", "what's missing before I open-source this?", or just one
part: "add a Russian README", "refresh the screenshots".
What the preflight finds
The first step changes nothing: it reads the repo, its history and its GitHub settings. An excerpt from a run on a
test repo:
It also checks secrets in the whole history (gitleaks), private paths, employer names and author emails, code
provenance, whether the package name is free on PyPI/npm, broken README links, SKILL.md frontmatter that agents
can't load, failing Dependabot PRs, and the repo's description, topics, social preview, branch protection, secret
scanning and private vulnerability reporting.
How it works
After the preflight and a few questions (audience, right to publish, visibility, languages), the skill works
through the phases you pick, in this order:
1. Security and history: secrets in history get rotated first, private material gets a fresh-history export,
and the repo gets pre-commit and CI scanning so it stays clean.
2. Install: one command to install and one to run, with the installers tested in CI on Linux, macOS and Windows,
and releases built for all three (wheel, optional standalone binaries). The package name is checked before the README tells anyone to pipx install it.
3. README and docs: structure via github-repo, visuals via beautify-github-readme, plain language via
humanizer, EN/RU mirrors kept in sync.
4. GUI, if there is one: before/after screenshots, then refreshed README shots.
5. Community files and CI: SECURITY, CONTRIBUTING, issue forms and the workflow templates below.
6. Discoverability: description, topics, social preview, the README's first 200 words.
7. Release: version, changelog, tag, and trusted publishing to PyPI.
8. Launch, only on request: a readiness check and drafts per channel; you post them.
Anything other people can see (push, tag, release, visibility, GitHub settings, posts) waits for your yes.
A private or local-only repo gets the same run: everything that lives in files is done now, and the settings that
only work once public (Scorecard, social preview, private vulnerability reporting, push protection) end up in a