Git Commit Standards

1. Format

• Structure: <type>(<optional scope>): <subject>

2. Allowed Types

Full Conventional Commits v1.0.0 type set (Angular convention):

3. Subject Line

• Rules: Use imperative mood (e.g., add, not added), maximum 50 characters, lowercase start, and no trailing period.

4. Body

• Content: Explain why the change was made, not what changed. Do not write line-by-line file summaries.
• Formatting: Hard wrap lines at 72 characters.

5. Footers

• Breaking Changes: Must begin with BREAKING CHANGE: followed by a migration path. Applies to any type and forces a MAJOR version bump.
• References: Append related issues at the bottom (e.g., Resolves #12).

6. Attribution

• Do not add AI co-authorship. Never include Co-Authored-By: Claude or any other AI-attribution footer. Commits belong to the human author who reviewed and approved the change.

7. Execution Protocol

• User-initiated only. This skill activates only when the user explicitly asks to commit — phrases like "commit this", "write the commit message", "let's commit", or invoking /commit. Never volunteer to commit unprompted. Don't propose commits at the end of a task, don't pre-emptively stage files, and don't run git add / git commit as cleanup after other work.
• Consent to execute. When asked to draft a commit message: ask whether the user will run the commit themselves or wants you to. Never run git commit without explicit go-ahead for the specific commit being created.
• Scope per ask. Permission to commit one set of changes is not blanket permission for future commits in the same session. Each commit needs its own confirmation.
• Signing: Delegated commits must be GPG signed if configured, unless the user explicitly opts out.