gh-onboard
Skill0 starsChanged 12 days agoMITView on GitHub
Guides a GitHub account from audit to fixes end to end, interactively and stage by stage, covering profile fields, profile README, repo descriptions and topics, project READMEs and release workflows, with every write confirmed. Use when the user wants to set up, clean up or strengthen their whole GitHub presence in one guided session.
In this repository8 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- gh-auditSkill
- gh-normalizeSkill
- profile-bioSkill
- profile-readmeSkill
- readme-standardSkill
- release-workflowSkill
The file
We split this skill into the rules it gives an agent
8 rules. About 0 are common, 3 are distinctive, and 5 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
5
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 14
Run only when the user explicitly asks.
- Very specific: line 23
If gh is missing, point to https://cli.github.com and stop.
- Very specific: line 28
Read the config (${GITHUB_MANAGER_HOME:-$HOME/.agents/github-manager}/config.json).
- Very specific: line 31
If the user wants changes, show the JSON and offer to save it to ~/.agents/github-manager/ (or $GITHUB_MANAGER_HOME) after an explicit yes.
- Very specific: line 37
If --scope public|private|all wasn't given, ask the user and wait for an explicit answer.
- Very specific: line 41
Follow ../gh-audit/SKILL.md with --scope <chosen scope> (account mode, even when run inside a clone).
- Distinctive: line 55
Before each stage, say what it will change and ask whether to run it, skip it, or stop.
- Distinctive: line 66
Read first, write later. No outward-facing step (API write, commit, push) without explicit approval.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
gh-onboard
Interactive orchestrator for a whole GitHub account. Runs the other skills of this plugin in a fixed order; every write stage is opt-in and confirmed.
Run only when the user explicitly asks.
0. Preflight
command -v gh >/dev/null || echo "gh CLI missing: https://cli.github.com"
gh auth status >/dev/null 2>&1 || echo "not logged in"If gh is missing, point to https://cli.github.com and stop. If not logged in, ask the user to run
gh auth login -s repo,read:org,user and wait.
1. Preferences
Read the config (${GITHUB_MANAGER_HOME:-$HOME/.agents/github-manager}/config.json). If none
exists, show the defaults from ../gh-audit/references/config.md and ask whether they fit. Typical
questions: README mirrors in another language? Description period style? Profile README sections?
If the user wants changes, show the JSON and offer to save it to ~/.agents/github-manager/ (or
$GITHUB_MANAGER_HOME) after an explicit yes. If writing there is blocked, say so and let the user
save it.
2. Scope
If --scope public|private|all wasn't given, ask the user and wait for an explicit answer.
3. Audit (read-only)
Follow ../gh-audit/SKILL.md with --scope <chosen scope> (account mode, even when run inside a
clone). Show the report and ask which stages to run. Pass the same --scope to gh-normalize.
4. Stages (each optional, in this order)
| Stage | Skill | Runs when |
| Profile fields | ../profile-bio/SKILL.md | the audit lists empty or weak fields |
| Profile README | ../profile-readme/SKILL.md | missing, weak or out of date |
| Repo metadata | ../gh-normalize/SKILL.md | description or topic findings |
| Project READMEs | ../readme-standard/SKILL.md (audit, then create or fix per repo) | README findings; needs a local clone per repo |
| Release workflows | ../release-workflow/SKILL.md | the user wants automated releases for chosen repos; needs a local clone |
| License | ../gh-audit/references/license.md | public repos without a recognised license; only report and ask |
Before each stage, say what it will change and ask whether to run it, skip it, or stop.
5. Wrap-up
List what changed, what was skipped, and the manual steps the API can't do (pronouns, PRO badge, local time, pinned repos, avatar). Remind the user that local file changes (READMEs, workflows) are not committed until they approve.
Flow rules
- Order: identity → public repo metadata → public READMEs → releases → private repos (optional).
- Read first, write later. No outward-facing step (API write, commit, push) without explicit approval.
- Works for any account: read the login from
gh api user; nothing about a specific user is hardcoded.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.