Git Local Workflow

Local git status, diff, commit, and branch discipline.

Skill metadata

Source	Bundled (installed by default)
Path	skills/software-development/git-local-workflow
Version	1.0.0
Author	VibeOS
License	MIT
Platforms	linux, macos, windows
Tags	git, commit, branch, workflow, local
Related skills	github-pr-workflow, plan, internet-starter

Reference: full SKILL.md

info

The following is the complete skill definition that VibeOS loads when this skill is triggered. This is what the agent sees as instructions when the skill is active.

Git Local Workflow

Use this for local git hygiene before GitHub PR flows. Prefer terminal for git commands. For opening PRs on GitHub, load github-pr-workflow.

When to Use

• User asks to commit, branch, or review local changes
• After implementing a feature and before push/PR
• When the working tree is dirty and you need a clean checkpoint

Prerequisites

• Inside a git repository (git rev-parse --is-inside-work-tree)
• User intent to commit (never commit secrets or .env)

How to Run

Always inspect first:

git status --short
git diff
git diff --staged
git log -5 --oneline

Then stage and commit only relevant files:

git add <paths>
git commit -m "$(cat <<'EOF'
Concise why-focused message.

EOF
)"
git status

Quick Reference

Step	Command
Status	git status --short
Unstaged diff	git diff
Staged diff	git diff --staged
Recent log	git log -5 --oneline
New branch	git checkout -b feat/short-name
Commit	HEREDOC message (why, not what)

Procedure

1. Run status + diff. Summarize risk (secrets, large binaries, unrelated files).
2. If multi-step work is unclear, load plan first.
3. Create a branch when not already on a feature branch.
4. Stage intentional paths only — never git add . blindly in mixed trees.
5. Commit with a 1–2 sentence why message via HEREDOC.
6. Re-run git status. Do not push unless the user asked.
7. Hand off to github-pr-workflow when a PR is requested.

Pitfalls

• Never update git config.
• Never force-push to main/master.
• Never commit .env, credentials, or private keys.
• Do not amend commits you did not create in this session / already pushed.
• Prefer several small commits over one giant dump when the user wants history.

Verification

• git status is clean or only shows expected leftovers.
• git log -1 shows the new message.
• No secret files in git show --stat HEAD.