spawn-planning-repo
Skill1 starsChanged 7 months agoMITView on GitHub
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".
In this repository13 other files it gives its agents.
- claude-and-shellSkill
- claude-gridSkill
- clipboard-handoverSkill
- handoverSkill
- handover-with-tasksSkill
- new-claude-atSkill
- new-claude-hereSkill
- new-workspaceSkill
- sideclaudeSkill
- start-from-handoverSkill
- start-leftoverSkill
- terminal-hereSkill
- vscode-hereSkill
The file
We split this skill into the rules it gives an agent
4 rules. About 0 are common, 4 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 8
Create a dedicated planning repository that lives alongside the current code repo.
- Distinctive: line 20
Create the new repo directory and initialize it:
- Distinctive: line 39
Always confirm the file list before moving anything — planning material is subjective.
- Distinctive: line 40
Use git mv then physically move when possible so history is preserved in the source commit that removes them.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 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
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.mdnaming the sibling code repo and explaining this is its planning companion. - A
CLAUDE.mdbriefly stating: this repo holds planning/spec/roadmap context for<name>, which lives at<path>/<github url>. - The planning files moved (via
git mvin the source repo, then copied over — ormvif they're untracked) from the main repo.
- A
- In the main repo: remove the moved files with
git rm(orrmif untracked), commit with a message likechore: 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 mvthen 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.
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.

