Files
cds-ai/atvm/git-guide.md
anthony.wen 22da851f44 docs: narrow ATVM e2e cypress git drafting rules
Update the ATVM git instructions so controller-repo git drafting and the SSH-prefixed push example only apply when the operator explicitly asks for the e2e cypress repo or a close variation.

Align AGENTS.md with git-guide.md so generic ATVM git requests no longer assume the controller repo by default.
2026-04-27 14:54:33 -04:00

5.4 KiB

Git Guide

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

Repository Reference

  • Do not assume the controller repo by default for every ATVM git request.
  • Only switch the default drafted repo to /root/cdc-e2e-cyp-12.17.4 when the operator explicitly asks for the e2e cypress repo or a close variation such as give me a git for the e2e cypress.
  • When the operator explicitly targets the e2e cypress repo, draft the git command itself for that controller repo.
  • Do not wrap drafted git commands in an SSH login command to the controller unless the operator explicitly asks for the SSH wrapper too.

Execution Rule

  • For this ATVM workspace, do not automatically perform any git-related command.
  • Do not run git status, git add, git commit, git push, git pull, git fetch, git stash, git checkout, git switch, git rebase, git merge, git diff, or any other git command unless the operator explicitly asks for that exact command to be executed.
  • By default, git requests in this workspace are draft-only requests.
  • Respond by preparing the exact commands for operator review, not by executing them.
  • Always write the drafted ATVM git commands to /tmp/commit.txt so the operator can copy and paste them.
  • Assume the operator will always run ATVM git commands manually.

SSH Default

  • When drafting git commands for the explicitly requested e2e cypress controller repo and SSH-backed git access is needed, use this exact prefix: GIT_SSH_COMMAND='ssh -i ~/.ssh/id_ed25519_anthony -o IdentitiesOnly=yes'
  • Prefer complete copy-pasteable command sequences that include that prefix for git fetch, git pull, and git push examples when applicable.

Commit Message Requests

  • If the operator 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.
  • Write the proposed ATVM git commands to /tmp/commit.txt.
  • When drafting a commit for the explicitly requested e2e cypress controller repo, present the plain git add ... / git commit ... command sequence the operator should run after logging into the controller repo, not an SSH-wrapped controller-login command.
  • If the operator 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.
  • Wait for explicit user approval before creating the commit.
  • Do not treat a request such as "give me the git commit" or "make the commit" as approval by itself.
  • Do not treat a request such as "create a git for me", "show me a proposed git commit", "prepare the commit", or any similar commit-related wording as approval by itself.
  • Treat all of the following as approval-gated prepare-only requests, not as permission to run git commit:
    • create me a git
    • create a git
    • create a git description
    • make me a git
    • make a git
    • make me a git description
    • create me a git description
  • Treat close variations of those phrases with the same intent the same way.
  • If the request means "prepare or create git/commit wording or a commit", ask for approval first before running any commit action.
  • Treat every commit-related request as prepare-and-show-only until the operator explicitly approves the commit after seeing the proposed message or exact command.
  • Only execute git commit after the operator explicitly approves the displayed commit command.
  • If there is any ambiguity about whether the operator is asking for preparation versus execution, default to not committing.

Push Requests

  • For this workspace, never execute git push from the assistant.
  • When the operator asks to push, show the exact push command only.
  • Do not hardcode origin main in this ATVM-local guide.
  • When drafting a push command, use the operator's requested remote/branch if provided.
  • If the operator does not specify the remote/branch, either:
    • draft a generic SSH-prefixed git push command, or
    • draft the exact remote/branch already established in the current ATVM context
  • Default generic push form: GIT_SSH_COMMAND='ssh -i ~/.ssh/id_ed25519_anthony -o IdentitiesOnly=yes' git push
  • When reminding the operator about the push command after a commit proposal or completed commit for the explicitly requested e2e cypress controller repo, always display the SSH-prefixed push command without assuming origin main unless that remote/branch was explicitly established.
  • Every commit draft response for the explicitly requested e2e cypress controller repo must include the SSH-prefixed push example.
  • Every post-commit response for the explicitly requested e2e cypress controller repo must include the SSH-prefixed push example.
  • Write the proposed push command to /tmp/commit.txt.

Commit Scope

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