MyAiConfiguration/shared/rules/git.md

Git Guidelines

General Rules

• Never commit changes unless explicitly instructed to do so.
• Never push changes unless explicitly instructed to do so.
• Never create a pull request unless explicitly instructed to do so.
• Never merge branches unless explicitly instructed to do so.
• Never rebase branches unless explicitly instructed to do so.
• Never amend an existing commit unless explicitly instructed to do so.
• Never create or delete Git tags unless explicitly instructed to do so.
• Never modify remote branches unless explicitly instructed to do so.
• Do not interpret general requests such as "finish this", "implement this", or "fix this" as permission to commit or push.
• Permission to commit does not imply permission to push.
• Permission to push does not imply permission to create or merge a pull request.
• Only perform Git write operations that the user explicitly requested.
• Read-only Git commands may be used when needed to inspect repository state.

Repository Safety

• Always inspect the current Git status before performing Git write operations.
• Never discard uncommitted user changes.
• Never overwrite unrelated changes.
• Never reset, clean, checkout, restore, or revert user changes unless explicitly requested.
• Never use destructive Git operations without explicit instruction.
• Never use git reset --hard unless explicitly requested.
• Never use git clean unless explicitly requested.
• Never force-push unless explicitly requested.
• Never use --force or --force-with-lease unless explicitly requested.
• Never rewrite shared history without explicit instruction.
• Never modify .gitignore unless required by the task.
• Never commit secrets, credentials, tokens, API keys, private keys, environment files, or other sensitive data.
• Never bypass Git hooks unless explicitly requested.
• Never use --no-verify unless explicitly requested.

Scope

• Only stage files related to the requested task.
• Never stage unrelated modified files.
• Prefer staging specific files instead of using broad commands such as git add ..
• Do not include generated files unless they are intentionally tracked by the repository.
• Do not include formatting-only changes unrelated to the task.
• Do not modify unrelated files merely to create a cleaner commit.
• Keep commits focused on one logical change.
• Split unrelated changes into separate commits when multiple commits were explicitly requested.

Commit Messages

Use Conventional Commits.

Format:

<type>(<optional-scope>): <description>

Allowed common types:

• feat: new functionality
• fix: bug fix
• refactor: code change without changing external behavior
• perf: performance improvement
• test: test changes
• docs: documentation changes
• style: formatting or style-only changes
• build: build system or dependency changes
• ci: CI/CD changes
• chore: maintenance work
• revert: revert of an earlier change

Commit message rules:

• Use lowercase commit types.
• Keep the subject concise and specific.
• Use imperative wording.
• Do not end the subject with a period.
• Describe what changed, not how hard the work was.
• Avoid vague messages such as fix stuff, update, changes, or cleanup.
• Use a scope when it improves clarity.
• Keep each commit limited to one logical purpose.
• Use ! or a BREAKING CHANGE: footer for breaking changes.
• Reference issue or ticket identifiers only when relevant and known.
• Never invent issue numbers, ticket IDs, or references.

Examples of valid commit messages:

• feat(auth): add refresh token rotation
• fix(api): handle missing user id
• refactor(storage): simplify cache abstraction
• perf(database): reduce duplicate queries
• test(users): add validation coverage
• docs(readme): document local setup
• build: update dotnet dependencies

Branches

• Do not create a branch unless explicitly requested.

• Do not switch branches unless necessary for the requested task.

• Never delete branches unless explicitly requested.

• Never rename branches unless explicitly requested.

• Never assume the target branch for a merge, rebase, or push.

• Preserve the repository's existing branch naming convention.

• If no branch naming convention exists and a branch was explicitly requested, prefer concise names such as:

  • feat/<name>
  • fix/<name>
  • refactor/<name>
  • chore/<name>

Pulling and Fetching

• Fetching remote state is allowed when required for inspection.
• Do not pull automatically unless explicitly requested or required for an explicitly requested Git operation.
• Never resolve pull or merge conflicts by discarding user changes.
• Do not automatically rebase after pulling.
• Do not automatically merge remote changes into the current branch.

Conflicts

• Stop before making destructive conflict-resolution decisions.
• Preserve both user work and repository history whenever possible.
• Resolve conflicts only when the correct resolution is clear from the task and surrounding code.
• Do not silently choose one side of a conflict when intent is ambiguous.
• Never use conflict resolution as an excuse to remove unrelated changes.

Before an Explicitly Requested Commit

Before creating a commit:

• Inspect git status.
• Inspect the staged diff.
• Confirm only task-related files are staged.
• Check for accidental secrets or sensitive files.
• Ensure the changes are consistent with the requested task.
• Run relevant tests, checks, or builds when practical.
• Do not include unrelated modifications.
• Use a Conventional Commit message.

Before an Explicitly Requested Push

Before pushing:

• Confirm that pushing was explicitly requested.
• Confirm the intended branch.
• Confirm the intended remote when multiple remotes exist.
• Ensure the commits being pushed are expected.
• Do not force-push unless explicitly requested.
• Do not push unrelated local commits unintentionally.

Autonomous Agent Rule

The agent may edit files and implement requested changes autonomously.

The agent must not autonomously:

• commit
• push
• merge
• rebase
• amend commits
• create pull requests
• create or delete tags
• delete branches
• rewrite Git history
• discard working-tree changes

These actions require explicit user instruction each time.

When in doubt, leave the repository changes uncommitted.