Git worktree creation/switching, submodule branch synchronization, and monorepo commit/push management. Triggers on "worktree", "submodule", "branch sync", "create feature branch", "서브모듈", "브랜치 동기화", "feature 브랜치 생성" requests.
How this skill is triggered — by the user, by Claude, or both
Slash command
/moonklabs-dev-workflow:git-submodule-managerThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Unified Git worktree and submodule management for any monorepo with git submodules — no per-repo edits needed.
Unified Git worktree and submodule management for any monorepo with git submodules — no per-repo edits needed.
Submodule paths and default branches are auto-detected from .gitmodules at runtime — nothing is hardcoded in the scripts:
.gitmodules (git config --file .gitmodules --get-regexp path)branch = ... entry in .gitmodules, if the repo owner set one via git submodule set-branch --branch <branch> <path>origin/HEAD)To pin a submodule to a non-default branch (e.g. an AI-only backend that tracks develop-ai instead of develop), run git submodule set-branch once in the target repo and commit the resulting .gitmodules change — the scripts pick it up automatically, no config file to maintain.
Every script accepts --quiet / -q alongside --yes / -y. It collapses output to one line per repo (no banner, no per-file diff dump) — prefer --quiet for routine status/commit/push checks so the tool output read back into context stays small. Only omit it when the user explicitly wants to see full file-level detail.
All scripts use plugin-root-relative paths:
skills/git-submodule-manager/scripts/
├── _config.sh # Shared config (auto-sourced)
├── create.sh # Create worktree
├── status.sh # Show status
├── commit.sh # Unified commit
├── push.sh # Unified push
├── pull.sh # Unified pull
└── switch.sh # Branch switching
Creates a new worktree plus matching submodule branches for feature development.
Triggers: "create a worktree", "new feature branch", "feature worktree", "worktree 만들어줘", "새 기능 브랜치"
Procedure:
main)../{repo-name}-{feature-name} (repo name is read from the current checkout, not hardcoded)feature/{feature-name} (from main)bash skills/git-submodule-manager/scripts/create.sh {feature-name} {base-branch} --yes
Displays the current worktree and the state of every submodule.
Triggers: "worktree status", "check branches", "submodule status", "상태 확인", "브랜치 확인"
Procedure:
--quiet unless the user wants full detail:
bash skills/git-submodule-manager/scripts/status.sh --quiet
switch commandpush commandCommits all changed submodules and the main repo with the same message.
Triggers: "commit", "commit changes", "commit all", "커밋해줘", "변경사항 커밋"
Procedure:
feat:, fix:, docs:, chore:, etc.)--quiet shows changed-file counts only, not every path)bash skills/git-submodule-manager/scripts/commit.sh "{commit-message}" --yes --quiet
.gitmodules order) → main (main includes submodule pointer updates)Pushes submodules and the main repo that have unpushed commits to their remotes.
Triggers: "push", "push to remote", "push all", "푸시해줘", "원격에 올려줘"
Procedure:
--force: warn about the risk and require explicit confirmationbash skills/git-submodule-manager/scripts/push.sh [--force] --yes --quiet
.gitmodules order) → mainFast-forward pulls the main repo and every submodule from their remote.
Triggers: "pull", "pull latest", "sync from remote", "풀받아줘", "최신 받아줘", "git pull"
Procedure:
bash skills/git-submodule-manager/scripts/pull.sh [branch-name] --yes
--ff-only — stops on non-fast-forward (prevents accidental merge commits).gitmodules order (main first so submodule pointers stay current)Switches branches on the main repo and every submodule at the same time.
Triggers: "switch branch", "checkout", "switch to", "브랜치 전환", "브랜치 바꿔줘", "체크아웃"
Procedure:
--create flagbash skills/git-submodule-manager/scripts/switch.sh {branch-name} [--create] --yes
--force push: do not use during team collaboration — requires explicit user consentnpx claudepluginhub moonklabs/skills --plugin moonklabs-dev-workflowGuides collaborative design exploration before implementation: explores context, asks clarifying questions, proposes approaches, and writes a design doc for user approval.
Creates structured, bite-sized implementation plans from specs or requirements before writing code. Useful for breaking down multi-step tasks into testable steps with file structure and task boundaries.
Resolves in-progress git merge or rebase conflicts by analyzing history, understanding intent, and preserving both changes where possible. Runs automated checks after resolution.