# Pre Deployment Main Sync

> Use before any deployment, rollout, Helm upgrade, kubectl apply/replace/restart, live ConfigMap patch, release, or beta/main environment change from a git repo. This skill requires Codex to fetch and integrate origin/main first, check for merge conflicts including dirty local changes, run verification, and block deployment when main cannot be merged cleanly or tests fail.

- Skill: `giordanorogers/pre-deployment-main-sync` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add giordanorogers/pre-deployment-main-sync`
- Raw SKILL.md: https://api.skillmd.com/api/skills/giordanorogers/pre-deployment-main-sync/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: giordanorogers (https://skillmd.com/u/giordanorogers)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/giordanorogers/pre-deployment-main-sync

---


# Pre-Deployment Main Sync

## Rule

Before any deployment or live environment mutation, sync the working branch with `origin/main` and prove the result is clean enough to deploy. Do not deploy from a branch that has not incorporated the latest `origin/main`.

## Workflow

1. Identify the git repo that owns the files or manifests being deployed.
2. Record the current branch and dirty files with `git status --short --branch`.
3. Fetch main:

```bash
git fetch origin main
```

If this fails because a remote ref is locked, retry once after a few seconds. If it still fails, stop.

4. Run the bundled checker from the repo root:

```bash
python ~/.codex/skills/pre-deployment-main-sync/scripts/pre_deployment_main_sync.py --integrate
```

This checks whether local dirty changes can survive the main sync, stashes them when needed, integrates `origin/main`, and restores the changes. If it reports any conflict or unresolved file, stop and resolve that before deployment.

5. Run the relevant verification for the deployment. Prefer the project’s focused test command plus any smoke test needed for the changed surface. If no focused command is known, inspect project docs and scripts before choosing.

6. Deploy only after all of these are true:

- `origin/main` is fetched and integrated.
- `git diff --name-only --diff-filter=U` is empty.
- The relevant tests or validation command completed successfully.
- The final `git status --short --branch` has only expected local changes.

## Failure Policy

If main integration, replaying dirty changes, or verification fails, do not deploy. Report:

- the branch and `origin/main` commit,
- the files that conflict or tests that fail,
- whether the deployment was skipped,
- the exact next action needed.

Do not “deploy anyway” unless the user explicitly overrides after seeing the conflict or failure.

## Notes

- If the branch intentionally targets beta but the user asks to deploy, still integrate `origin/main` first unless they explicitly say not to.
- If the worktree is dirty, prefer the checker script or a stash-based flow over destructive commands.
- Never use `git reset --hard` or `git checkout --` to make the sync work unless the user explicitly asks for destructive cleanup.