---
alwaysApply: true
---
# Directive: Peaceful Co-Existence with Developers

## 1) Version-Control Ownership

* **MUST NOT** run `git add`, `git commit`, or any write action.
* **MUST** leave staging/committing to the developer.

## 2) Source of Truth for Commit Text

* **MUST** derive messages **only** from:

  * files **staged** for commit (primary), and
  * files **awaiting staging** (context).
* **MUST** use the **diffs** to inform content.
* **MUST NOT** invent changes or imply work not present in diffs.

## 3) Mandatory Preview Flow

* **ALWAYS** present, before any real commit:

  * file list + brief per-file notes,
  * a **draft commit message** (copy-paste ready),
  * nothing auto-applied.

---

# Commit Message Format (Normative)

## A. Subject Line (required)

```
<type>(<scope>)<!>: <summary>
```

* **type** (lowercase, Conventional Commits): `feat|fix|refactor|perf|docs|test|build|chore|ci|revert`
* **scope**: optional module/package/area (e.g., `api`, `ui/login`, `db`)
* **!**: include when a breaking change is introduced
* **summary**: imperative mood, ≤ 72 chars, no trailing period

**Examples**

* `fix(api): handle null token in refresh path`
* `feat(ui/login)!: require OTP after 3 failed attempts`

## B. Body (optional, when it adds non-obvious value)

* One blank line after subject.
* Wrap at \~72 chars.
* Explain **what** and **why**, not line-by-line “how”.
* Include brief notes like tests passing or TS/lint issues resolved **only if material**.

**Body checklist**

* [ ] Problem/symptom being addressed
* [ ] High-level approach or rationale
* [ ] Risks, tradeoffs, or follow-ups (if any)

## C. Footer (optional)

* Issue refs: `Closes #123`, `Refs #456`
* Breaking change (alternative to `!`):
  `BREAKING CHANGE: <impact + migration note>`
* Authors: `Co-authored-by: Name <email>`
* Security: `CVE-XXXX-YYYY: <short note>` (if applicable)

---

## Content Guidance

### Include (when relevant)

* Specific fixes/features delivered
* Symptoms/problems fixed
* Brief note that tests passed or TS/lint errors resolved

### Avoid

* Vague: *improved, enhanced, better*
* Trivialities: tiny docs, one-liners, pure lint cleanups (separate, focused commits if needed)
* Redundancy: generic blurbs repeated across files
* Multi-purpose dumps: keep commits **narrow and focused**
* Long explanations that good inline code comments already cover

**Guiding Principle:** Let code and inline docs speak. Use commits to highlight what isn’t obvious.

---

# Copy-Paste Templates

## Minimal (no body)

```text
<type>(<scope>): <summary>
```

## Standard (with body & footer)

```text
<type>(<scope>)<!>: <summary>

<why-this-change?>
<what-it-does?>
<risks-or-follow-ups?>

Closes #<id>
BREAKING CHANGE: <impact + migration>
Co-authored-by: <Name> <email>
```

---

# Assistant Output Checklist (before showing the draft)

* [ ] List changed files + 1–2 line notes per file
* [ ] Provide **one** focused draft message (subject/body/footer)
* [ ] Subject ≤ 72 chars, imperative mood, correct `type(scope)!` syntax
* [ ] Body only if it adds non-obvious value
* [ ] No invented changes; aligns strictly with diffs
* [ ] Render as a single copy-paste block for the developer