spawn-planning-repo

Create a sibling planning repo for the current project, seed it with planning context moved out of the main repo, and push to GitHub. Use when the user says "create a planning repo alongside this", "spin off planning", or "split planning into its own repo".

Jump to install

Repository: danielrosehill/Claude-Hopper
Last source activity: April 29, 2026 at 09:05
Detected SKILL.md language: English
Stars: 0
Forks: 0

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

A direct command skips the review prompt. Inspect the source before running it.

npx skills add https://github.com/danielrosehill/Claude-Hopper --skill spawn-planning-repo

The command stays on one line. Scroll horizontally to inspect it before copying.

Prefer a local copy? Download the files currently available to SkillsMP.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

SKILL.md

Source instructions · Read-only preview

Back to search Back to installation

vscode-here

Open VS Code at the current working directory. Use when the user asks to "open in vs code", "open in vscode", "vscode here", or "code .".

2026-05-06

claude-and-shell

Launch a single Konsole window at a target directory split left/right — left pane runs Claude Code, right pane is a raw shell at the same path (no Claude). Use when the user asks for "claude with a terminal", "claude + shell", "claude and a free konsole", "paired konsole", or wants Claude visible alongside a hands-on shell for the same project.

2026-04-29

claude-grid

Launch a single Konsole window at a given path containing 2 or 4 split panes, each running a fresh Claude Code session in that path. Use when the user asks for a "claude grid", "2-pane claude", "4-pane claude", "split konsole with claudes", "quad claude", or similar — i.e. they want multiple parallel Claude sessions in the same path, visible side-by-side. Default count is 2; pass `4` (or "quad") for the 2×2 grid.

2026-04-29

View all from this repository

Spawn Planning Repo

Create a dedicated planning repository that lives alongside the current code repo. Planning material (roadmaps, notes, specs, brainstorms) is moved out of the main repo into the new one, keeping the code repo lean.

Steps

Identify the current repo root and parent directory:

root=$(git rev-parse --show-toplevel)
name=$(basename "$root")
parent=$(dirname "$root")

Propose a planning repo name (default: <name>-planning) and confirm with the user.

Survey the current repo for planning-flavored files/dirs — e.g. planning/, docs/planning, ROADMAP.md, NOTES.md, TODO.md, ideas/, brainstorm markdown. Present the list to the user and confirm what should move. Do not guess silently.

Create the new repo directory and initialize it:

mkdir "$parent/<planning-name>"
cd "$parent/<planning-name>"
git init -b main

Seed it with:

A README.md naming the sibling code repo and explaining this is its planning companion.
A CLAUDE.md briefly stating: this repo holds planning/spec/roadmap context for <name>, which lives at <path> / <github url>.
The planning files moved (via git mv in the source repo, then copied over — or mv if they're untracked) from the main repo.

In the main repo: remove the moved files with git rm (or rm if untracked), commit with a message like chore: move planning into sibling <planning-name> repo. Do NOT push the main repo unless the user asks.

In the new planning repo: git add -A, initial commit, then create the GitHub repo and push:

gh repo create danielrosehill/<planning-name> --private --source . --remote origin --push

Report: new repo path, GitHub URL, list of files moved, and the pending (uncommitted-pushed) state of the main repo.

Notes

Always confirm the file list before moving anything — planning material is subjective.

Use git mv then physically move when possible so history is preserved in the source commit that removes them.

The new repo is private by default; ask if the user wants public.