Git Workflow

Git Workflow

Overview

This skill defines the default git workflow for this environment: work directly on master unless explicitly asked otherwise, keep branches unprefixed, and commit only complete, verified slices with short commit messages.

Important: git work (staging/committing/pushing, etc) is not a signal to stop or report progress. After any commit, immediately return to the continuous loop: pick the next top-most unchecked PLAN.md Now item and keep going.

Only stop to report progress under exactly two conditions:

• All PLAN.md Now work is complete, or
• A hard blocker / high-risk gate / product decision is encountered.

Defaults (Rules)

• Work on master unless the human explicitly asks for a new branch.
• Do not create branches “just in case”.
• If asked to create a branch, use a plain branch name with no tool/model prefixes.
  • Do not prefix with codex/, claude/, agent/, etc.
• Commit only complete slices: done, verified, and ready to ship.
• Commit messages are short plain sentences (no feat:, chore:, etc.).
  • Prefer a single sentence.
  • If needed, use 2–3 short sentences total (no paragraphs).
• Never use git add .. Always stage by explicit filenames to avoid accidental commits.

Before Any Commit

Confirm the slice is complete:

• The intended outcome is achieved.
• Verification was run (tests or the project’s chosen verification step).
• Any required checklist/docs updates for the slice are included.

Then:

• Check working tree state: git status
• Review diff: git diff (and git diff --staged after staging)

Branching Rules

• Only create a branch when explicitly asked.
• Keep branch names simple and descriptive, like:
  • fix-login-timeout
  • billing-webhook-hardening
  • upgrade-rails-8

Commit Rules

• One commit per completed slice whenever feasible.
• Do not commit partial work, experiments, or “WIP” unless the human explicitly asks.
• If a change is essentially “more of the same” as the most recent commit (tight follow-up, fixup, small adjustment), prefer amending the most recent commit instead of making a new commit.
  • If it is unclear whether to amend vs make a new commit, ask.
• Do not add co-authoring trailers (no Co-authored-by:). The human is the sole author.

Commit Message Style

Good:

• Fix login redirect loop
• Add read-only admin audit view
• Reduce flaky checkout test timeouts

Avoid:

• feat: add admin audit view
• chore: stuff
• Long multi-paragraph explanations

Pushing

Pushing to master triggers a deploy. Treat git push as a production operation.

Hard gate:

• Do not push to master unless you are intentionally deploying to production.

Rules:

• Only push to master when all unpushed commits are complete, verified, and safe for production.
• Do not push if there are missing dependencies, unfinished work, or “it should work” assumptions.
• If the change set is not ready to deploy, keep commits local until it is ready.
• If the work is finished and verified, prefer pushing and deploying rather than accumulating completed work locally without a reason.

Gems/libraries:

• Only push to master when ready to release a new version.
• It is acceptable to keep collecting local commits until release-ready.

Safety Defaults

• Never run destructive git commands (git reset --hard, forced checkouts, force pushes) unless explicitly requested and confirmed.
• If unrelated changes exist in the worktree, do not revert them unless asked. Keep your work focused.

Source: kaka-ruto/skills — distributed by TomeVault.