← DXD SkillsCONTENT HISTORYWHAT CHANGED · RULE-BASED ANALYSIS
Update to DXD Skills
Snapshot Sep 30, 2026 · 23:18 UTC · version 0.3.0
Collection source: not recorded for this historical snapshot.
First saved snapshot
No earlier snapshot is available to establish a change.
Compare saved observations
Download comparison JSONFull technical diff · 0 changed fields
Full snapshot data
{
"name": "quick-fix-deploy-sync",
"description": "Sync production and staging git branches with fast-forward merges and push. Use when the user wants a quick fix deploy, hotfix promotion, backport to staging, sync main and dev/staging, fast-forward branches, or keep staging and production in sync after a commit.",
"included_files": [],
"skill_md_contents": "---\nname: quick-fix-deploy-sync\ndescription: >-\n Sync production and staging git branches with fast-forward merges and push.\n Use when the user wants a quick fix deploy, hotfix promotion, backport to\n staging, sync main and dev/staging, fast-forward branches, or keep staging\n and production in sync after a commit.\n---\n\n# Quick Fix Deploy Sync\n\n## Goal\n\nFind the production and staging branches in the current project, then sync them\nwith fast-forward-only merges so both tips match — no merge commits, no force\npush, and the cleanest possible branch history.\n\n## When to Use\n\nUse this skill when the user asks to:\n\n- Quick fix deploy, hotfix, or ship a fix to production or staging.\n- Promote staging to production or backport a production fix to staging.\n- Sync `main` and `dev` / `staging` / `develop` / `preview`.\n- Fast-forward branches and keep staging and production aligned.\n- Commit a fix on one branch and mirror it to the other.\n\nExample prompts:\n\n- \"Quick fix deploy — backport this to staging.\"\n- \"Ship what's on staging to main.\"\n- \"Keep main and dev in sync after this hotfix.\"\n- \"Commit, push main, and sync staging.\"\n\n## Workflow\n\n### 1. Resolve branch names\n\nDiscover production and staging branch names before any git writes. Check, in\norder:\n\n1. Project docs: `AGENTS.md`, `README.md`, `docs/setup.md`, `.github/workflows/*`\n2. Remote default branch: `git remote show origin | grep 'HEAD branch'`\n3. Common defaults:\n - **Production:** `main` or `master`\n - **Staging:** `dev`, `staging`, `develop`, or `preview`\n\nIf still ambiguous, ask once:\n\n> Which branch is production and which is staging?\n\nRecord the mapping for the rest of the session. Example:\n\n| Role | Branch |\n|------|--------|\n| Production | `main` |\n| Staging | `dev` |\n\n### 2. Preflight (always)\n\nRun in parallel:\n\n```bash\ngit status\ngit branch -vv\ngit fetch origin\n```\n\nThen compare remote tips:\n\n```bash\ngit rev-parse origin/<production> origin/<staging>\ngit log --oneline origin/<staging>..origin/<production>\ngit log --oneline origin/<production>..origin/<staging>\n```\n\n**Stop and report** if:\n\n- Working tree is dirty — commit or stash first; never commit secrets\n- Branches **diverged** (each has unique commits) — fast-forward is impossible\n- Either branch is missing locally or on `origin`\n\nDo **not** use plain `git merge`, `git rebase`, or `git push --force` unless\nthe user explicitly approves after you explain the divergence.\n\n### 3. Choose sync direction\n\n| Situation | Action |\n|-----------|--------|\n| Fix committed on **production**; staging should match | Fast-forward **staging → production** |\n| Fix tested on **staging**; ready to ship | Fast-forward **production → staging** |\n| User says \"backport to staging\" | Staging ← production |\n| User says \"promote to prod\" / \"ship staging\" | Production ← staging |\n| User says \"keep them in sync\" / \"both branches\" | Sync the lagging branch to the leading one |\n\n**Leading branch** = the branch with commits the other lacks (ahead after\n`git fetch`).\n\nIf both sides are equal, report already synced — no push needed.\n\n### 4. Fast-forward sync\n\nSubstitute resolved branch names below. Example uses production = `main`,\nstaging = `dev`.\n\n**A — Production ahead (backport hotfix to staging)**\n\n```bash\ngit checkout <staging>\ngit pull --ff-only origin <staging>\ngit merge --ff-only origin/<production>\ngit push origin <staging>\ngit checkout <production>\ngit status\n```\n\n**B — Staging ahead (promote to production)**\n\n```bash\ngit checkout <production>\ngit pull --ff-only origin <production>\ngit merge --ff-only origin/<staging>\ngit push origin <production>\ngit checkout <staging>\ngit status\n```\n\nReturn to the branch the user was on unless they asked to stay elsewhere.\n\n### 5. Commit + sync (when the user includes a fix)\n\nWhen the user wants **commit, push, and sync both branches**:\n\n1. Stage **only** files for the fix — exclude unrelated changes\n2. Commit with a concise message focused on why, not what\n3. Push the branch where the commit was made\n4. Run workflow **A** or **B** from step 4 based on which branch received the commit\n5. Verify both remote tips match:\n\n```bash\ngit rev-parse origin/<production> origin/<staging>\ngit log -1 --oneline --decorate origin/<production> origin/<staging>\n```\n\n### 6. Verify and report\n\nAfter sync:\n\n```bash\ngit rev-parse origin/<production> origin/<staging>\ngit log -3 --oneline --decorate origin/<production> origin/<staging>\n```\n\nReport using this template:\n\n```markdown\n## Branch sync\n\n- **Production:** `<branch>` @ `<sha>` — `<subject>`\n- **Staging:** `<branch>` @ `<sha>` — `<subject>`\n- **Direction:** `<staging ← production | production ← staging | already synced>`\n- **Pushed:** yes/no\n- **Current branch:** `<branch>`\n\n### Next step (optional)\n- [ ] Verify staging deploy / production deploy if applicable\n```\n\nIf CI or deploy hooks exist, mention which branch deploys where. Do not trigger\na deploy unless the user asks.\n\n### 7. Diverged branches (escape hatch)\n\nIf `git merge --ff-only` fails, stop and present:\n\n1. Commit lists on each side: `git log --oneline --left-right <production>...<staging>`\n2. Options: open a merge PR, rebase staging onto production (needs approval), or\n reset staging to production (destructive — needs approval)\n\nDo not pick an option without user confirmation.\n\n## Guardrails\n\n- **Never** `git push --force` to production or staging unless the user explicitly requests it\n- **Never** amend or rebase pushed commits without explicit approval\n- **Never** update `git config`\n- **Never** use plain `git pull` — prefer `git pull --ff-only`\n- **Never** use `git merge` without `--ff-only` in this workflow\n- **Never** commit secrets, credentials, or `.env` files\n- If fast-forward is impossible, **report** the divergence — do not silently rebase or force-push\n\n## Completion Checklist\n\n- [ ] Production and staging branch names were resolved from the repo or confirmed with the user\n- [ ] Preflight ran: clean working tree, fetch completed, ahead/behind state is known\n- [ ] Sync direction matches user intent (promote vs backport vs already equal)\n- [ ] Only `--ff-only` merges were used; no merge commits were created\n- [ ] Both remote branch tips match after sync (or divergence was reported with options)\n- [ ] Final report includes both SHAs, direction, push status, and current branch\n- [ ] No force push, rebase, or git config changes were made without explicit approval\n"
}SHA-256: b7cf04f297b0a2afb9fae981a4781f8f554f22c5348f4ed57d2e62023a2ac3cc