Menu
Push the current branch to the configured remote. Use when the user explicitly asks to push changes.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
| name | push |
| description | Push the current branch to the configured remote. Use when the user explicitly asks to push changes. |
Push the current branch to the remote. Work through each step in order and stop immediately if a hard stop condition is met.
Run in parallel:
git branch --show-current — current branch namegit status --short — check for uncommitted changesgit remote -v — list configured remotesThen run: git log @{u}..HEAD --oneline 2>/dev/null — show unpushed commits. If this fails (no upstream set), note that this is the first push for this branch.
If there are no configured remotes, stop here and say so.
If already up to date (zero unpushed commits AND upstream exists), report "already up to date" and stop — do not push unnecessarily.
If the working tree is dirty (uncommitted changes exist), warn the user but do not block.
If the branch is main or master:
<branch>. Pushing to main/master is not allowed. Switch to a feature/* branch first."Only allow pushes on branches matching feature/*.
Read the project steering files for any remote or branch push constraints. Look for:
Note any constraints — apply them in Step 3.
Push the current branch to origin:
# First push (no upstream set):
git push -u origin <branch>
# Subsequent pushes (upstream already set):
git push origin <branch>
Rules:
--force or -f unless the user explicitly requested it in their messageShow a clear summary:
Push Results:
- Branch: <branch>
- origin (<url>): ✓ pushed / ✗ failed: <error>
- Commits pushed: <n>
Then remind: "Create a merge request on GitLab if one doesn't exist yet."
--force or -f without explicit user instruction.Audits agents, prompts, skills, knowledge, and documentation for gaps, inconsistencies, and improvement opportunities. Proposes changes for user approval. Triggers on "agent-audit", "audit agents", "review config", "what can we improve".
Use before any creative work or spec creation. Explores intent, challenges assumptions, and produces specs. Triggers on "brainstorm", "let's design", "spec out", "define requirements", "write a spec", "challenge this", "poke holes", "what am I missing".
Detects documentation drift after structural changes. Dispatches parallel specialist reviewers and auto-fixes. Triggers on "check my docs", "audit docs", "doc drift", "check doc drift", or auto from post-implementation when tracked categories change.
Automated post-implementation workflow. Triggers when the orchestrator receives DONE from an implementation subagent. Runs quality gate, doc staleness check, auto-review, and improvement capture.
Periodic codebase health check. Use when the user says "health check", "technical debt", "what needs attention", "codebase audit", "codebase health".
Takes a spec phase and generates an execution plan with parallel stages, agent routing, review gates, and verification criteria. Use before dispatching implementation work. Triggers on "plan execution", "generate execution plan", "how should we execute this", or internally when the orchestrator is about to implement a spec phase.