gh-repo-create
Skill3 starsChanged 7 months agoMITView on GitHub
Create and initialize a new GitHub repository with sensible defaults using the gh CLI. Defaults to private. Sets up README, .gitignore, license, and .claude directory structure. Chains naturally into architect-plan-for-dispatch and any code-writing skill that needs a repo to target. Activates when the user says "create a repo", "new repo", "set up a GitHub repo", "gh-repo-create", or when another skill needs a fresh repository to write code into.
- Reads credentials
- Commits and pushes
We split this skill into the rules it gives an agent
8 rules. About 0 are common, 5 are distinctive, and 3 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈5
Distinctive · estimate
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- could be automatic: a setting could enforce it
- Distinctive: line 69
If the repo already exists, inform the user and stop.
- Very specific: line 82
Visibility rule: Default to --private. Only use --public if the user explicitly states the repo should be public.
- Distinctive: line 89
After cloning, set up the standard Summit directory scaffold:
- Very specific: line 181
Never overwrite an existing repo: Always check gh repo view first.
- Very specific: line 193
Never commit secrets: If the project needs environment variables, create a .env.example with placeholder keys, never a .env with real …
- Distinctive: line 195
Confirm public visibility before creating: If the user says "public", ask once to confirm.
- Distinctive: line 230
Not checking if the repo already exists first
- Distinctive: line 238
Commit and push the scaffold automatically
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 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-repo-create
Establish a new GitHub repository under the ryankolean org with production-ready
defaults so that downstream skills (architect-plan-for-dispatch, Dispatch workers,
Claude Code sessions) have a clean, consistent target to write into. Private by
default because Summit and client work should never be accidentally public.
When to Activate
Manual triggers:
- "Create a repo"
- "New repo"
- "Set up a GitHub repo"
- "gh-repo-create"
- "Spin up a repo for this"
- "I need a new repo"
Auto-detect triggers:
architect-plan-for-dispatchis about to run and no repo exists yet for the project- A design document or project scope references a repo that doesn't exist
- User describes a greenfield project and there's no target repo mentioned
- Any skill in the pipeline needs to write code but has no repo to push to
Do NOT activate when:
- The target repo already exists (check with
gh repo viewfirst) - The user is working within an existing repo
- The user says "I'll create the repo myself"
Input
The skill needs the following. If not provided, ask one question at a time to fill gaps.
| Parameter | Required | Default | Description |
repo_name | Yes | — | kebab-case repository name (e.g., carrot-hire, dtst) |
visibility | No | private | private or public |
description | No | — | One-line repo description for GitHub |
license | No | MIT | SPDX license identifier. Use MIT for open-source, NONE for client/proprietary work |
gitignore_template | No | Node | GitHub .gitignore template name (e.g., Node, Go, Python, Rust) |
clone_locally | No | true | Whether to clone the repo after creation |
init_branch | No | main | Default branch name |
Process
Step 1: Validate Prerequisites
# Confirm gh is authenticated
gh auth status
# Confirm the repo doesn't already exist
gh repo view ryankolean/<repo_name> 2>/dev/null && echo "REPO EXISTS — aborting" && exit 1If the repo already exists, inform the user and stop. Do not overwrite or re-create.
Step 2: Create the Repository
gh repo create ryankolean/<repo_name> \
--private \ # or --public if visibility=public
--description "<description>" \
--license <license> \
--gitignore <gitignore_template> \
--cloneVisibility rule: Default to --private. Only use --public if the user
explicitly states the repo should be public. When creating a public repo, confirm
with the user before proceeding: "This will be a public repository visible to
everyone. Confirm?"
Step 3: Initialize Project Structure
After cloning, set up the standard Summit directory scaffold:
cd <repo_name>
# Create .claude directory for Dispatch plans and code reports
mkdir -p .claude/dispatch/plans
mkdir -p .claude/dispatch/reports
# Create a minimal README if gh didn't generate one
if [ ! -f README.md ]; then
cat > README.md << 'EOF'
# <Repo Name>
<description>
## Getting Started
TODO
## License
<license>
EOF
fi
# Create CLAUDE.md project instructions file
cat > CLAUDE.md << 'EOF'
# Project Instructions
## Overview
<description>
## Conventions
- Follow existing code patterns and naming conventions
- All environment variables go in .env (never committed)
- Tests live alongside source files or in a dedicated __tests__ / tests directory
## Structure
.claude/
dispatch/
plans/ # Dispatch execution plans
reports/ # Code reports from architect-plan-for-dispatch
EOF
# Commit the scaffold
git add -A
git commit -m "chore: initialize project scaffold"
git push origin mainStep 4: Verify and Report
# Confirm the repo is live
gh repo view ryankolean/<repo_name> --json name,visibility,url,descriptionReport back to the user with:
- Repository URL:
https://github.com/ryankolean/<repo_name> - Visibility:
private/public - Default branch:
main - Scaffold contents: what was created
- Next step suggestion: "Ready for architect-plan-for-dispatch" or "Ready for code"
Output
A fully initialized GitHub repository with:
<repo_name>/
├── .claude/
│ └── dispatch/
│ ├── plans/ # Empty, ready for Dispatch plans
│ └── reports/ # Empty, ready for code reports
├── .gitignore # From GitHub template
├── CLAUDE.md # Project instructions for Claude Code / Dispatch
├── LICENSE # From selected license
└── README.md # Minimal project READMEPlus a confirmation message with the repo URL and suggested next action.
Rules
- Always default to private. Summit client work, internal tools, and anything without an explicit "make it public" directive must be private. Public repos require explicit user confirmation.
- Never overwrite an existing repo. Always check
gh repo viewfirst. If the repo exists, report it and ask the user what they want to do. - Always create the
.claude/dispatchstructure. This is the standard scaffold thatarchitect-plan-for-dispatchexpects. Omitting it forces a later task to create it, wasting tokens. - Always create
CLAUDE.md. Dispatch workers and Claude Code sessions read this file for project context. A missingCLAUDE.mdmeans every worker starts blind. - Use
ryankoleanas the default org/owner. Unless the user specifies a different GitHub org or personal account, all repos go underryankolean. - kebab-case repo names only. Reject names with spaces, underscores, or camelCase. Suggest a kebab-case alternative if needed.
- Never commit secrets. If the project needs environment variables, create a
.env.examplewith placeholder keys, never a.envwith real values. - Confirm public visibility before creating. If the user says "public", ask once to confirm. This prevents accidental exposure of client work.
Examples
Good example:
User: "I need a new repo for the Carrot Hire project"
gh repo view ryankolean/carrot-hire 2>/dev/null # Check — doesn't exist
gh repo create ryankolean/carrot-hire \
--private \
--description "Job coordination app for Carrot Fertility" \
--license MIT \
--gitignore Node \
--clone
cd carrot-hire
mkdir -p .claude/dispatch/plans .claude/dispatch/reports
# ... create README.md, CLAUDE.md ...
git add -A && git commit -m "chore: initialize project scaffold" && git push origin mainResponse: "Done —
ryankolean/carrot-hireis live and private at https://github.com/ryankolean/carrot-hire. The.claude/dispatchscaffold is in place. Ready forarchitect-plan-for-dispatchwhenever you are."
Bad example (what to avoid):
- Creating a public repo without confirming with the user
- Skipping the
.claude/dispatchdirectory scaffold - Using
gh repo create carrot-hirewithout theryankolean/prefix (creates under the wrong account) - Not checking if the repo already exists first
Cross-Surface Behavior
In Claude Code (has git + gh access):
- Execute all commands directly
- Clone the repo into the current working directory or a specified path
- Commit and push the scaffold automatically
In Claude.ai (no git access):
- Output the full sequence of commands for the user to run
- Provide the commands as a copyable code block
- Remind the user to run
gh auth statusfirst if they haven't recently
Chaining
interrogate→gh-repo-create: After scoping a greenfield project, create the repo before planninggh-repo-create→architect-plan-for-dispatch: Repo is created, now analyze it and build the execution plangh-repo-create→ [any code-writing skill]: Any skill that produces code can target the new repodesign-doc-review→gh-repo-create→architect-plan-for-dispatch: Full pipeline from design doc to repo to dispatch plan
In this repository98 other files it gives its agents.
- AGENTS.mdAGENTS.md
- agent-architectSkill
- architect-plan-for-dispatchSkill
- automate-auditSkill
- brain-dumpSkill
- chat-to-code-promptSkill
- cli-apifySkill
- cli-batSkill
- cli-duckdbSkill
- cli-fdSkill
- cli-ffmpegSkill
- cli-fzfSkill
- cli-ghSkill
- cli-httpieSkill
- cli-imagemagickSkill
- cli-jqSkill
- cli-lazygitSkill
- cli-pandocSkill
- cli-playwrightSkill
- cli-ripgrepSkill
- cli-sqliteSkill
- cli-yqSkill
- cli-yt-dlpSkill
- codebase-reviewSkill
- context-summarySkill
- decomposeSkill
- delegateSkill
- design-a-systemSkill
- design-doc-reviewSkill
- devils-advocateSkill
- ig-savesSkill
- interrogateSkill
- mentor-aristotleSkill
- mentor-attiaSkill
- mentor-aureliusSkill
- mentor-bloomSkill
- mentor-brownSkill
- mentor-buffettSkill
- mentor-builderSkill
- mentor-carnegieSkill
- mentor-clearSkill
- mentor-councilSkill
- mentor-cunninghamSkill
- mentor-dalioSkill
- mentor-davinciSkill
- mentor-demingSkill
- mentor-ferrissSkill
- mentor-feynmanSkill
- mentor-franklSkill
- mentor-garyveeSkill
- mentor-godinSkill
- mentor-gogginsSkill
- mentor-greeneSkill
- mentor-holidaySkill
- mentor-hormoziSkill
- mentor-houselSkill
- mentor-jockoSkill
- mentor-jungSkill
- mentor-kahnemanSkill
- mentor-kingSkill
- The first 60 shown.
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.

