bob walker
9d9bb52f93
Add comprehensive rules for Git usage, including branching protocols, worktree suggestions, safety checks (git diff), and history management. Establish discovery steps for repo-specific branching and worktree suitability. Ensure commits are atomic and separate functional logic from linting/whitespace changes.
2.9 KiB
2.9 KiB
Core Guidelines
- Persona: Assume the user is a 30-year veteran system administrator. Skip explanations of basic concepts. Be direct, technical, and concise.
- Direct Action: Edit files directly. Do not commit or branch autonomously; always ask for permission first. Proactively suggest logical points for atomic commits and suggest new branches if the work deviates from the current scope or a significant task shift occurs.
- Code Comments: Use them sparingly. Only explain complex "why" logic. Never explain "what" the code is doing.
- Project Discovery:
- Always check for a
Makefileorscripts/directory first for build/test/lint commands. - Identify language stacks via manifests (
package.json,go.mod,Cargo.toml,requirements.txt).
- Always check for a
- Language Defaults:
- Ruby: Assume
bundler. - Python: Assume
virtualenv. - Node.js: Check for
package-lock.json(npm) vsyarn.lock. - Go: Assume
go modules.
- Ruby: Assume
- Standards & Testing:
- Mimic local indentation (tabs vs spaces) and naming conventions exactly.
- Always write a test if a framework exists. Match the existing style (e.g., table-driven tests in Go).
- Respect
.gitignoreand.editorconfig.
- Shell Usage: Prefer non-interactive commands with silent/quiet flags (e.g.,
apt-get -y,npm install --quiet). - Git Branching:
- Discovery: On new repo entry, ask "Does this repo require feature branches?". Record answer in the repo's
GEMINI.md. - Use a new branch for each feature or bug fix.
- include ticket/issue number in branch name if available (e.g.,
123-add-login). - Naming convention:
description(e.g.,add-login,memory-leak). - Branch from the default branch (
mainormaster) and keep branches short-lived. - Rebase from the default branch frequently to avoid conflicts.
- Discovery: On new repo entry, ask "Does this repo require feature branches?". Record answer in the repo's
- Git Worktrees:
- Suggest
git worktreefor parallel tasks or frequent context switching. - Discovery: On new repo entry, ask "Is this repo suitable for worktrees?". Record answer in the repo's
GEMINI.md.
- Suggest
- Git Safety & History:
- Pre-commit: Always run
git diff(orgit diff --staged) to verify changes before asking to commit. - Force Push: Permitted only on private feature branches (
--force-with-lease). Never on shared/main branches. - Conflicts: If a rebase/merge encounters complex conflicts, abort and ask for guidance.
- Cleanup: Squash "wip" or "fix typo" commits into the main feature commit before final merge instructions.
- Pre-commit: Always run
- Git Commits:
- Use present tense, imperative mood (e.g.,
resolve memory leak). - Keep summary <= 50 chars; wrap body at 72 chars.
- Explain why in the body, not what.
- Reference issue/ticket numbers if available (e.g.,
Fixes #456). - Keep commits atomic; one logical change per commit.
- Separate whitespace and linting changes into their own commits, distinct from functional logic changes.
- Use present tense, imperative mood (e.g.,