Files
cds-ai/git-guide.md
anthony.wen dda0a0b4c0 Require verification after git commit execution
- update the git guide to require post-commit verification before reporting success
- document that commit verification must confirm git commit exited successfully, HEAD advanced, and the new commit appears in git log
- document that failed or non-created commits must be reported clearly instead of being claimed as successful
2026-03-26 11:03:20 -04:00

3.0 KiB

Git Guide

This file records repo-specific git workflow preferences for /home/aw/code/cds.

Repository Reference

  • Active repository: https://git.devreser.com/anthony.wen/cds-ai.git
  • Treat this repository URL as the current origin for this workspace unless the user explicitly says it changed.

Commit Message Requests

  • If the user asks for a git commit description, draft the proposed commit message first.
  • When warranted by the size or complexity of the change, provide both:
    • a concise commit title/summary line
    • a detailed commit description/body listing the key changes
  • The proposed git commit command should match the full proposed message, including the detailed body when one is warranted.
  • After the proposed commit message, show the exact git commit command that would be used.
  • After the git commit command, show the exact git push -u origin main command that would be used.
  • If the user asks for a git commit, do not commit immediately.
  • First show both:
    • the proposed commit description/message
    • the exact git commit command planned for execution
  • When a detailed body is warranted, do not reduce the proposed commit to only the short title at execution time.
  • Do not run git commit immediately after drafting the message.
  • Do not run git push immediately after drafting the message.
  • Wait for explicit user approval before creating the commit or running the push command.
  • Do not treat a request such as "give me the git commit" or "make the commit" as approval by itself.
  • Only execute git commit after the user explicitly approves the displayed commit command.
  • If the user changes the requested commit message or scope after commands are shown, rebuild the proposal and wait for fresh approval.
  • After executing git commit, always verify that the commit actually succeeded before reporting success.
  • Verification must include checking that:
    • git commit exited successfully
    • HEAD advanced to a new commit
    • the new commit appears in git log --oneline -n 1
  • Do not claim a commit was created unless that verification has been completed.
  • If git commit did not actually create a commit, report that clearly and leave the changes as uncommitted.

Push Requests

  • When the user asks to push, use git push -u origin main by default unless the user explicitly asks for a different remote or branch.
  • Do not execute git push -u origin main or any other git push command from the assistant when credentials or an SSH key passphrase might be required.
  • Instead, show the exact push command and tell the user to run it directly in the terminal.
  • Do not accept passwords or passphrases through chat for git operations.
  • If the user asks the assistant to take the password/passphrase handoff, refuse and direct the user to complete the prompt from the terminal.

Commit Scope

  • When committing, include only the files relevant to the approved change.
  • Leave unrelated worktree changes uncommitted unless the user explicitly asks to include them.