| name | contributor-setup |
| platforms | ["claude-code"] |
| description | Set up the local tooling needed to contribute changes to the marketing-skills repo from Claude Code. Checks for the gh CLI, gh authentication, and git user.name and user.email, then installs or configures anything missing. Use this skill when someone says 'contributor setup', 'I want to edit skills', 'I want to contribute', 'how do I contribute to marketing-skills', 'set me up to contribute', or is referred here by /plugin-doctor, /setup, or /skill-contributor. Also trigger when the user mentions installing 'gh', authenticating gh, or setting their git identity. Skip this skill in Cowork — it's Claude Code only because it needs to probe and modify the user's local machine. |
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:
gh — GitHub's command-line tool, used to open PRs without leaving the terminal.gh auth — an authenticated GitHub session on the machine.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_search tool 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 --version to 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) → recommend brew install gh. Confirm Homebrew is available first with which 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 → recommend winget install --id GitHub.cli or scoop 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 status will 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. gh is installed and authenticated as <username>, and your commits will show up as <name> <email>. When you've got changes to submit, run /skill-contributor and 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.
