Git Discipline

Git discipline

This skill writes the ## Git and pull requests section into the repository's agent rules file: four rules for commits, the index, subject lines and pull requests, and the repository's answers to three decisions. Every session in the repository reads that file from its first turn, so the rules cover the agent's first commit, which usually comes before anyone invokes a skill.

The section

Write this block, with the three decision lines filled in by step 3 below:

## Git and pull requests

- **Commit, amend, push or rewrite history only when the user confirms it in the current turn.**
  A request to write the code, or approval of an earlier commit, does not cover the next commit.
  When the work is ready, stop, summarize what changed, and ask.
- **Leave the index and the working tree as the user left them.** Run `git add`, `git reset`,
  `git stash` or `git checkout -- <path>` only when the user asks for it in this turn. What is
  staged is the reviewer's record of how far they have read. When a commit is confirmed and the
  index is partly staged, ask which scope to commit before running anything.
- **Write the subject line in the imperative, naming the change**: "Fail the build on a missing
  license header". Work that follows a spec carries the spec's directory name as a prefix,
  `[NNN-slug]`, starting with the commit that writes the spec. Work without a spec carries no prefix.
- **A change reaches the default branch through a pull request**, so CI runs before it lands.
  Create a branch when the work starts; when finished work sits on the default branch, ask which
  branch to move it to. Pushing, opening a pull request and merging each need their own go-ahead.

Decisions for this repository:

- **Default branch:** DEFAULT_BRANCH
- **Merge strategy:** MERGE_STRATEGY
- **Branch names:** BRANCH_NAMES

*Maintained by the `git-discipline` skill down to this line. This repository's own lines go below.*

Write the section

The agent rules file is AGENTS.md, and every byte-identical per-agent copy the repository carries, CLAUDE.md among them.

1. List which of AGENTS.md and CLAUDE.md the repository has. With neither, stop: say so, and name the repository-init skill, which writes both. With both, run cmp AGENTS.md CLAUDE.md before editing; a CLAUDE.md that matches is a copy.
2. Find ## Git and pull requests in AGENTS.md when it exists, otherwise in the one file present, and make every edit below in that file. Also list any other section that states git rules, such as a heading naming git, commits, branches or pull requests, to show the user in step 5.
3. Settle the three decisions, each as the next section describes, and replace DEFAULT_BRANCH, MERGE_STRATEGY and BRANCH_NAMES with the answers. When the user leaves a decision open, delete its line, and name the open decision in the report.
4. When the heading is absent, insert the block after the last section that ends at a line naming the writing-style or spec-driven-development skill, and after any lines the repository added below that line. With neither section present, append the block at the end of the file.
5. When the heading is present, or step 2 found other git sections, compare the block with that text: from the heading to the line naming this skill, or to the next ## heading when there is no such line. Show the user the difference, and replace the text only when the user confirms. An existing section often carries examples and exceptions the repository wrote for itself; offer to move those below the skill's line. Lines already below it are the repository's own; leave them.
6. Copy the edited file over each file that was a copy in step 1: cp AGENTS.md CLAUDE.md. Leave a symlink or an @AGENTS.md import as it is. Report a CLAUDE.md that differed before the edit as drift, and ask the user which file holds the rules they want.
7. Stage nothing and commit nothing. Report the files changed, the section's line range and any decision left open, and propose a commit subject, such as "Add the git and pull-request rules to the agent rules file". The section's first rule covers this commit.

The three decisions

Ask the user for each decision, state what each option costs, and write the wording in the "write" column. Where the repository already shows an answer, such as a merge setting on the hosting provider or a pattern in its branch names, propose that answer first.

Default branch

Read it; never assume a name.

• With a remote: the name after origin/ in git symbolic-ref --short refs/remotes/origin/HEAD. On GitHub, gh repo view --json defaultBranchRef --jq .defaultBranchRef.name gives the same.
• Without a remote: git branch --show-current, confirmed with the user, since the current branch may be a feature branch.

Write the name in backticks, followed by a period.

Merge strategy

Branch names