git-workflow

What it does and when to use it

Inspect status and history, create scoped commits, perform authorized history operations, or prepare a draft PR safely. Use for explicit Git or PR requests; do not commit, rewrite, push, or open a PR during ordinary implementation.

How it works

1. Trigger
2. Non-trigger
3. Modes

---
name: git-workflow
description: Inspect status and history, create scoped commits, perform authorized history operations, or prepare a draft PR safely. Use for explicit Git or PR requests; do not commit, rewrite, push, or open a PR during ordinary implementation.
---

# Git Workflow

## Trigger

Use for `STATUS`, `HISTORY`, `COMMIT`, `REBASE`, or `PR` work explicitly requested by the user.

## Non-trigger

Do not activate to stage or deliver ordinary implementation implicitly. A request to edit code does not authorize commit, push, history rewrite, PR, merge, release, or deploy. The one standing exception is an approved plan whose `commits` strategy names local commits; the executor makes those with the COMMIT guidance and nothing beyond them.

## Modes

- **STATUS** — inspect branch, worktree, staged and unstaged changes, upstream, and conflicts without mutation.
- **HISTORY** — answer with log, show, blame, search, bisect, or reflog evidence.
- **COMMIT** — use [commit guidance](references/commit.md): inspect full diffs, preserve unrelated work, build atomic groups, stage specific paths or hunks, follow local message style, run relevant checks, and verify the resulting commit.
- **REBASE** — require explicit rewrite authorization, account for dirty and published work, define recovery, resolve by intent, and never bypass hooks or use plain force push.
- **PR** — use [PR guidance](references/pr.md) after readiness is proven.

Read [history guidance](references/history.md) for investigative or rewriting details. Never alter Git configuration, skip hooks, stage broad unknown changes, force-push a protected branch, or merge unless separately authorized.

Versions

Database snapshot: 13.11.2026 · package version 97e5ea953663 (SHA-256 digest of the entire package)

Downloads in the last 30 days: 0 · ranking

Report a problem with this skill: harmful content, incorrect descriptions or an author’s removal request.

Similar skills

• 90managing-git-workflow
  Safely inspects repository state and executes explicitly authorized commits, pushes, and pull-request creation through a constrained runner. Use when the user asks to commit selected work, push existing commits, create or inspect a pull request, save changes in Git, or publish a branch to GitHub.
• 100git-commit
  Inspect Git changes, organize logical commits, and write Conventional Commits messages. Use for /git-commit, explicit commit requests, message drafting, commit planning, and commit review. Excludes general Git troubleshooting, branch strategy, and history repair.
• 100commit-guidelines
  Dirty repo, uncommitted changes, commit, amend, split, changeset, PR history. Inspect repository state and prepare atomic Git commits or jj changesets. Use whenever the worktree is already dirty or you are about to commit or rewrite history.
• 96commit
  Creates atomic conventional git commits using git-agent. This skill should be used when the user requests "commit", "git commit", "create commit", or wants to commit changes using AI atomic commits.
• 92git-commit
  Use when creating Git commits.
• 90committing
  Makes clean git commits in the project's own style. Use when the user asks to commit, write a commit message, split changes into commits, or open a PR. Not for reviews or explaining history.