Skill

new-userscript-repo

Set up a brand-new development workspace for a single userscript. Asks public or private, creates the GitHub repo with the chosen visibility, installs this plugin at project scope inside it, and ends. The user opens that repo in a fresh Claude Code session and starts authoring the script with `new-userscript`.

npx claudepluginhub danielrosehill/claude-code-plugins --plugin userscript-development

Tool Access

This skill uses the workspace's default tool permissions.

Preview

Spin up a clean per-script workspace. This is the **bootstrap** step — it does not write the userscript itself. Once the repo exists, the user runs `new-userscript` inside it.

SKILL.md

Similar Skills

using-superpowers

180.9k

Mandates invoking relevant skills via tools before any response in coding sessions. Covers access, priorities, and adaptations for Claude Code, Copilot CLI, Gemini CLI.

3 files

superpowers

Stats

Stars0

Forks0

Last CommitMay 2, 2026

Actions

View Source View Plugin View on GitHub View README

Help us improve

Share bugs, ideas, or general feedback.

New Userscript Repo

Spin up a clean per-script workspace. This is the bootstrap step — it does not write the userscript itself. Once the repo exists, the user runs new-userscript inside it.

Inputs

Repo name — Train-Case (e.g. Github-Stars-Cleaner). Will be used verbatim as the GitHub repo name and the local directory name.
Visibility — ask the user: public or private?
- Public is the norm for shareable userscripts (Tampermonkey can install from the raw URL out of the box).
- Private is fine for personal scripts, but warn: Tampermonkey users will need to pre-authenticate the raw URL or download manually.
Base directory — resolve in this order:
1. $USERSCRIPT_REPOS_BASE env var
2. userscripts_base_path in ${CLAUDE_USER_DATA:-${XDG_DATA_HOME:-$HOME/.local/share}/claude-plugins}/userscript-development/config.json
3. Ask the user (and offer to save it for next time)

Steps

Confirm the name doesn't collide:
```
test ! -d "<base>/<repo-name>" && ! gh repo view danielrosehill/<repo-name> >/dev/null 2>&1
```
If either hits, ask the user for a different name. Do not overwrite.

Scaffold the directory:

mkdir -p "<base>/<repo-name>"
cd "<base>/<repo-name>"

Write a minimal README.md:

# <repo-name>

Tampermonkey userscript. Authored with the [`userscript-development`](https://github.com/danielrosehill/Claude-Userscript-Development-Plugin) Claude Code plugin.

Run `/new-userscript` inside this repo to scaffold the `.user.js`.

Write a standard MIT LICENSE (or skip if private and the user prefers no license — ask).
Write .gitignore with .DS_Store, node_modules/, .envrc.

Init git, commit, create remote with the chosen visibility:

git init -q
git add -A
git commit -q -m "Initial commit: <repo-name> userscript workspace"
gh repo create danielrosehill/<repo-name> --<public|private> --source=. --push

Install this plugin at project scope so it's available in that repo's Claude Code sessions but doesn't pollute the global skill list:
```
claude plugins install userscript-development@danielrosehill --scope project
```
End task. Tell the user:
- The repo URL.
- The local path.
- "Open a new Claude Code session in <path> and run /new-userscript to scaffold the script body."

Guards

Never create a public repo without an explicit "public" answer — when in doubt, default to private and let the user flip it later via gh repo edit --visibility public.
Don't run new-userscript automatically — keep this skill's scope to workspace bootstrap only. Authoring is a separate step in a fresh session so the user's intent for the script can drive the metadata block.