Isolated workspace creation for parallel development work. Use when starting feature work that needs isolation from the current workspace. Creates git worktrees with proper setup and safety verification.
/plugin marketplace add bostonaholic/rpikit/plugin install rpikit@rpikitThis skill inherits all available tools. When active, it can use any tool Claude has access to.
Create isolated workspaces for parallel development without disrupting current work.
Git worktrees allow multiple branches to be checked out simultaneously in separate directories. This enables parallel work without stashing, context switching, or polluting the main workspace. This skill provides structured worktree creation with safety verification.
Use worktrees when:
Skip worktrees when:
When creating worktrees, check these locations in order:
Look for:
- .worktrees/ (hidden, preferred)
- worktrees/ (visible)
If both exist, prefer .worktrees/
Look in CLAUDE.md or project documentation for:
- Stated worktree location preference
- Project-specific conventions
If no preference found:
"Where should worktrees be created?"
- .worktrees/ (project-local, hidden)
- worktrees/ (project-local, visible)
- External location (e.g., ~/worktrees/project-name/)
Critical for project-local worktrees:
Before creating a worktree in .worktrees/ or worktrees/:
MUST verify directory is ignored in git.
Check .gitignore for:
- .worktrees/
- worktrees/
If NOT ignored:
1. Add to .gitignore
echo ".worktrees/" >> .gitignore
(or "worktrees/" depending on choice)
2. Commit the change
git add .gitignore
git commit -m "Add worktree directory to .gitignore"
3. Then proceed with worktree creation
Why this matters: Accidentally committing worktree contents creates massive, confusing commits with duplicate code.
Get project name: basename $(git rev-parse --show-toplevel)
Get current branch: git branch --show-current
Get default branch: git symbolic-ref refs/remotes/origin/HEAD
For new feature branch:
git worktree add <worktree-path> -b <branch-name>
For existing branch:
git worktree add <worktree-path> <existing-branch>
From specific base:
git worktree add <worktree-path> -b <branch-name> origin/main
Detect project type and run appropriate setup:
If package.json exists:
npm install (or yarn, pnpm based on lockfile)
If Cargo.toml exists:
cargo build
If requirements.txt exists:
pip install -r requirements.txt (in venv if present)
If Gemfile exists:
bundle install
If go.mod exists:
go mod download
Verify clean state before starting work:
# Run project test command
npm test / cargo test / pytest / etc.
If tests fail:
"Baseline tests fail in the new worktree.
This could mean:
- Missing dependencies
- Environment configuration needed
- Pre-existing failures on the base branch
Options:
- Investigate and fix (recommended)
- Proceed anyway (acknowledge failures exist)
- Abort worktree creation"
"Worktree created and ready:
Location: <worktree-path>
Branch: <branch-name>
Base: <base-branch>
Tests: <pass/fail status>
To work in this worktree:
cd <worktree-path>
To return to main workspace:
cd <main-repo-path>"
git worktree list
# From main repository
git worktree remove <worktree-path>
# If worktree has changes, force removal
git worktree remove --force <worktree-path>
# Remove worktrees whose directories no longer exist
git worktree prune
When planning involves isolated implementation:
Plan approved
→ Create worktree for implementation
→ Run setup in worktree
→ Verify baseline tests
→ Begin implementation in isolated environment
After implementation in worktree:
Implementation complete
→ Use finishing-work skill
→ If merging locally: cleanup worktree
→ If creating PR: keep worktree for review cycle
→ If discarding: cleanup worktree
Pros:
Cons:
Pros:
Cons:
Wrong: Create project-local worktree without checking .gitignore Right: Always verify gitignore before creating project-local worktrees
Wrong: Start working without running npm install / cargo build / etc. Right: Run appropriate setup for project type
Wrong: Assume worktree is ready without verification Right: Run tests to establish clean baseline
Wrong: Leave stale worktrees indefinitely Right: Remove worktrees after work is merged or abandoned
Wrong: New worktree for every small change Right: Worktrees for substantial, isolated work
Before removing a worktree:
# Create worktree with new branch
git worktree add <path> -b <new-branch> <base>
# Create worktree with existing branch
git worktree add <path> <existing-branch>
# List all worktrees
git worktree list
# Remove worktree
git worktree remove <path>
# Force remove (with uncommitted changes)
git worktree remove --force <path>
# Prune stale entries
git worktree prune
Creating algorithmic art using p5.js with seeded randomness and interactive parameter exploration. Use this when users request creating art using code, generative art, algorithmic art, flow fields, or particle systems. Create original algorithmic art rather than copying existing artists' work to avoid copyright violations.
Applies Anthropic's official brand colors and typography to any sort of artifact that may benefit from having Anthropic's look-and-feel. Use it when brand colors or style guidelines, visual formatting, or company design standards apply.
Create beautiful visual art in .png and .pdf documents using design philosophy. You should use this skill when the user asks to create a poster, piece of art, design, or other static piece. Create original visual designs, never copying existing artists' work to avoid copyright violations.