git-submodule-push
Use when pushing changes in a repository that contains git submodules, especially when the submodule has its own commits that must not be left stranded. Triggers include "push", "git push", "submodule", "commit submodule", "workspace push"
Best use case
git-submodule-push is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Use when pushing changes in a repository that contains git submodules, especially when the submodule has its own commits that must not be left stranded. Triggers include "push", "git push", "submodule", "commit submodule", "workspace push"
Teams using git-submodule-push should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/git-submodule-push/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How git-submodule-push Compares
| Feature / Agent | git-submodule-push | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Use when pushing changes in a repository that contains git submodules, especially when the submodule has its own commits that must not be left stranded. Triggers include "push", "git push", "submodule", "commit submodule", "workspace push"
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# Git Submodule Push ## When to Use - The repo contains git submodules with uncommitted or unpushed changes - Pushing the outer repo would leave submodule work stranded locally - A submodule pin needs updating in the outer repo - Mirroring or syncing a workspace submodule to a standalone clone ## When NOT to Use - No submodules in the repo (use standard `git push`) - Submodule has no new commits since last outer-repo push ## Core Workflow Always push submodule first, then outer repo, then mirror. 1. **Submodule first** ```bash git -C <submodule-path> add -A git -C <submodule-path> commit -m "<message>" git -C <submodule-path> push ``` 2. **Outer repo** (bumps the submodule pin) ```bash git add <submodule-path> git commit -m "<message>" git push ``` 3. **Mirror clone** (if configured) ```bash git -C <mirror-path> pull --ff-only ``` ## Common Mistakes | Mistake | Fix | |---------|-----| | Pushing outer repo before submodule | Submodule commits are stranded; reverse the order | | Forgetting `git add <submodule-path>` | Pin doesn't update; outer repo still points to old commit | | Using `git push --recurse-submodules=on-demand` without checking | Fails silently if submodule remote rejects; explicit push is safer | | Skipping the mirror sync | Standalone clone drifts out of date | ## Anti-Patterns - **Bare outer push**: Pushing only the outer repo when submodule is dirty - **Manual pin editing**: Editing `.gitmodules` or the gitlink directly instead of `git add <submodule-path>` - **Force push in submodule**: Risks breaking collaborators' checkouts