# Git Deploy Release

> Disciplined git, release, and deployment workflow. Use when the agent is asked to commit, push, branch, merge, release, deploy, publish, clean up git state, or prepare production web changes; enforces main-first work, semantic version increments when present, local testing before deploy, live testing after deploy, and neutral branch/commit naming.

- Skill: `dreamers-laboratory/git-deploy-release` (Agent Skill)
- Install (CLI): `npx skillmds@latest add dreamers-laboratory/git-deploy-release`
- Raw SKILL.md: https://api.skillmd.com/api/skills/dreamers-laboratory/git-deploy-release/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: dreamers-laboratory (https://skillmd.com/u/dreamers-laboratory)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/dreamers-laboratory/git-deploy-release

---


# Git Deploy Release

## Operating Rules

- Treat `main` as the default working and production branch unless the user explicitly asks for a feature branch or the change is risky enough to justify proposing one.
- Never use assistant-branded branch names or commit messages. Do not include strings such as `codex`, `claude`, or other AI assistant names in git metadata.
- Keep commit messages concise, human, and descriptive of the product change.
- Before committing, inspect `git status --short --branch` and avoid staging unrelated user changes.
- If deleting files or branches, only do so when the user requested it or when the cleanup is clearly part of the task.

## Release Prep

- Check for an existing semantic version before deployment or release prep. Inspect common locations such as `package.json`, `package-lock.json`, `pyproject.toml`, `Cargo.toml`, `VERSION`, app config files, and docs that already carry a version.
- If a semver exists, increment it deliberately during deploy prep. Prefer patch increments for small fixes, minor increments for visible feature/content additions, and major increments only for breaking changes or explicit user instruction.
- Do not introduce placeholder versions into projects that do not already carry semver unless the user asks.
- Regenerate lockfiles or generated metadata when the version source requires it.

## Testing Gate

- Test locally before deploying. Use the repo's existing commands first, then add targeted checks that match the change.
- First determine whether the repository actually has CI/CD; do not invent a remote pipeline gate where none is configured. When a repository has no CI/CD, run the relevant available local checks and report that no CI/CD verification exists.
- When CI/CD is configured, inspect the remote run for the exact pushed commit and wait for a terminal result. Do not call the work finished, ready, or deployed while required CI is pending, running, failed, or unverified.
- If configured CI fails, read the exact failing step and log before changing code. Distinguish a product regression from CI-environment or inherited test-harness failure, fix only the demonstrated cause, rerun relevant local checks, push, and verify the replacement run is green.
- For webapp deploys, keep a checklist, audit the changed path, run deterministic tests, use browser or DOM checks when the UI changed, and capture live verification after deploy.
- Do not describe a deployment as complete until the changed route or behavior has been tested against the live target.
- If a check cannot run, report exactly why and what residual risk remains.

## Commit And Push

- Stage only intended files. Use pathspec exclusions when unrelated local files exist.
- Run `git diff --cached --check` before committing.
- Commit after the relevant test batch passes, not before.
- Push to `origin main` by default when the user asked to deploy or converge work onto production.
- If a temporary feature branch was used and the user asks to converge, fast-forward or merge into `main`, push `main`, and delete the temporary local and remote branch after confirming `main` contains the work.

## Deployment Flow

1. Confirm the working branch and repo state.
2. Apply the requested change without reverting unrelated work.
3. Increment existing semver if the task includes deployment or release.
4. Run local tests and build checks.
5. Commit and push intended files.
6. If the repository has required remote CI, verify it is green for the pushed commit; otherwise record that the repository has no CI/CD gate.
7. Deploy with the repo's documented command or deployment script.
8. Verify live health, changed pages, and any sitemap or SEO routes affected by the change.
9. Report the exact tests, CI result, deploy command, live URLs checked, commit hash, branch state, and any unproven items.