Commit Work

Commits should be easy to review and safe to ship: only intended changes included, logically scoped, messages whose subject says what and body says why. Speed matters: keep the common case to two command rounds without hiding Git operations inside shell constructs that permission policies cannot inspect.

Rules

• Read CLAUDE.md (or .claude/CLAUDE.md) if it exists and is not already in context — use it for commit message language (Turkish or English), project-specific scopes, subject limits, and trailer rules. Default to English if absent.
• For GitHub-hosted repositories, prefer gh for every supported GitHub-side operation: repository identity and ownership, authentication, default-branch and fork metadata, pull requests, checks, and other remote state. Use git for local repository operations (status, diff, staging, commits, history, and branches) and for transport operations such as fetch and push when push is in scope. Do not reimplement native Git operations through gh api; if gh is unavailable or unauthenticated, fall back to git only where it provides equivalent evidence.
• Use Conventional Commits: type(scope): subject (max 72 chars)
• Body explains WHY, not what (the diff shows what)
• No Co-Authored-By or AI attribution of any kind — not in subject, body, or trailer; explicit project policy, applies even if a commit template includes it
• If the diff contains secrets or tokens, stop and report — do not commit
• Do not put .workflow/ on the default branch. On a task branch it may be intended lookback. Git has no merge path-exclude: drop those paths after merge or before squash. Deleting the feature branch loses lookback.
• Never use --no-verify
• No debug logs or unrelated formatting churn — leave them unstaged and note them in the report
• Keep mutating Git commands policy-readable. A single && chain is fine when every segment is a direct, literal command, but never construct commit messages with heredocs, $(), backticks, redirection, or a sh -c/zsh -lc wrapper. Pass the subject and body as static, shell-safe arguments with repeated -m flags. If the environment cannot authorize the flat segments independently, run the same commands as separate tool calls instead of requesting broad shell approval.
• Never modify the working tree. No git restore, git checkout -- <path>, git stash, git reset --hard, or any command that discards or rewrites uncommitted changes. (Unstaging with a plain git reset <file> is fine — it touches only the index.) Your job is to stage and commit what exists — if something looks wrong, report it, don't "clean it up".
• Commit does not imply push. Push only when the user query explicitly asks to push (examples: “push”, “commit and push”, “push the branch”, “push to origin/remote”). “Commit” / “commit the changes” alone → commit and verify without pushing.