
Contributor Setup
- 1 installs
- 9 repo stars
- Updated June 11, 2026
- timescale/marketing-skills
Sets up local tooling to contribute to the marketing-skills repo by checking and configuring the gh CLI, gh authentication, and git user identity.
About
Prepares a contributor's local environment for submitting changes to the timescale/marketing-skills repo by checking for the gh CLI, gh authentication, and git user.name/user.email, then installing or configuring what is missing. A contributor uses it as one-time setup before opening PRs; it does not submit changes.
- Checks gh CLI, gh auth, and git identity, installing anything missing
- Claude Code only; bails out in Cowork
Contributor Setup by the numbers
- 1 all-time installs (skills.sh)
- Ranked #524 of 733 Git & Pull Requests skills by installs in the Skillselion catalog
- Data as of Jul 27, 2026 (Skillselion catalog sync)
npx skills add https://github.com/timescale/marketing-skills --skill contributor-setupAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 1 |
|---|---|
| repo stars | ★ 9 |
| Last updated | June 11, 2026 |
| Repository | timescale/marketing-skills ↗ |
What it does
Sets up local tooling to contribute to the marketing-skills repo by checking and configuring the gh CLI, gh authentication, and git user identity.
Files
Contributor Setup — Local Tooling for Skill Contributors
Help a contributor get their local environment ready to submit changes to the public timescale/marketing-skills repo. This skill does not submit any changes — it only makes sure the tools exist. Once this passes, the contributor can use /skill-contributor or just ask Claude to help ship changes.
The three things this skill checks:
1. gh — GitHub's command-line tool, used to open PRs without leaving the terminal. 2. gh auth — an authenticated GitHub session on the machine. 3. git user identity — user.name and user.email, so commits show up with the contributor's name attached.
Keep the tone light. This is a one-time setup, not a rite of passage.
Step 0: Runtime check (bail if Cowork)
Detect the runtime by tool availability:
- If the
google_drive_searchtool is available → Cowork. This skill is Claude Code only. Tell the user:
"This skill is Claude Code only — it probes and modifies your local machine, which I can't do from Cowork. If you're ready to submit changes from Cowork, just run /skill-contributor and it'll walk you through everything."Stop here. Do not proceed.
- Otherwise → Claude Code. Continue to Step 1.
Step 1: Check gh CLI
Run which gh via Bash.
- Present: Run
gh --versionto confirm it's working. Tell the user what version is installed and move on to Step 2. - Missing: Detect the host OS via
$CLAUDE_CODE_HOST_PLATFORM: darwin(macOS) → recommendbrew install gh. Confirm Homebrew is available first withwhich brew. If brew is missing, point the user to https://brew.sh and stop — ask them to come back after installing Homebrew.linux→ recommend the install commands from cli.github.com/manual/installation for the user's distro. If you don't know the distro, ask.win32→ recommendwinget install --id GitHub.cliorscoop install gh.
Ask the user: "Want me to run the install command for you, or would you rather run it yourself?" If they say yes, run it via Bash. If it fails (permission errors, password prompts, missing package manager), surface the error and ask them how they'd like to proceed.
If the install command hangs or fails with a permission/password prompt: some installers (especially on Linux distros using sudo) require interactive input that Bash can't supply. Tell the user to run the command themselves in a fresh Terminal window, then come back and say "done" — you'll re-check gh --version when they return.
Once gh --version returns cleanly, move on.
Step 2: Check gh auth
Run gh auth status via Bash.
- Authenticated:
gh auth statuswill print the logged-in username. Confirm it, then move on to Step 3. - Not authenticated: Walk the user through
gh auth login --web. Explain in one sentence what's about to happen:
"This will open your browser, give you a short code to paste, and sign you into GitHub. I'll wait while you finish."
Run gh auth login --web and let the user complete the browser flow. When they're back, re-run gh auth status to confirm it worked.
If the user pushes back on --web (for example, they prefer a personal access token), offer gh auth login without the flag so they can pick their own method. Don't force the web flow.
Step 3: Check git user config
Run git config --global user.name and git config --global user.email via Bash in parallel.
- Both set: Confirm the values to the user in one line, then move on.
- Either missing: Ask the user for whichever value is missing:
"What name should show up on your commits?" (suggest their GitHub username from Step 2 as a default)
"What email should I use for commits? (if you use GitHub's noreply email, that's at GitHub email settings)"
Run git config --global user.name "<their name>" and git config --global user.email "<their email>" as needed. Verify the values after setting.
Step 4: Done
Confirm all three checks pass. Tell the user what's ready:
"You're set up.ghis installed and authenticated as \<username\>, and your commits will show up as \<name\> \<email\>. When you've got changes to submit, run/skill-contributorand I'll walk you through the rest."
If the user was referred here by /skill-contributor, offer to hand back:
"Want me to jump back into /skill-contributor to submit what you were working on?"Tone
Technical but encouraging. This user is likely a marketer who's willing to use a terminal but isn't a daily user of it — so explain each step in one sentence of plain English before running the command. Celebrate small wins ("gh is installed — one down, two to go."), don't gatekeep, and never assume prior CLI experience.