Commit

# Command: Commit (Conventional, No Emoji, One-Line, Efficiency-Aware)

Create conventional commits using **only Git** commands (`status`, `diff`, `add`, `commit`, `push`).
Commit messages are **single-line only** (no body/description), **no emojis**, and **never** include phrases like "generated by …".

**Key principle:** Optimize for **Coding Efficiency** metric while maintaining logical commit boundaries.

---

## Usage

```bash
/commit

Optional flags (recommended):

/commit --branch <target-branch> --push
/commit --max-files 25 --max-lines 800
/commit --interactive

---

Coding Efficiency (Critical)

Formula: Efficiency = Added Lines / (Added Lines + Deleted Lines)

Efficiency	Rating	Action
> 80%	Excellent	Commit as-is
60-80%	Good	Acceptable
40-60%	Low	Consider combining with additions
< 40%	Poor	Must combine with productive changes

Real Examples

Commit	Added	Deleted	Efficiency	Problem
chore: remove unused...	4	481	4.3%	Pure deletion = very low
refactor: clean up...	1142	110	86.2%	Add > Delete = good
feat: add streaming...	387	12	93.3%	Add >> Delete = excellent

Efficiency Rules

1. Never commit pure deletions alone - Always bundle with related additions
2. Small chore/docs changes - Combine with the main feat/fix they support
3. Refactors that delete code - Include in the same commit as the replacement code
4. File removals - Commit together with the files that replace their functionality

---

What This Command Does

1) Inspect working tree and staged changes (Git only)

Run:

git status --porcelain=v1
git diff --stat
git diff
git diff --staged --stat
git diff --staged

Calculate efficiency before committing:

git diff --numstat | awk '{add+=$1; del+=$2} END {print "Efficiency:", (add/(add+del))*100 "%"}'

2) Decide commit grouping strategy (Efficiency-First)

Primary goal: Maintain efficiency > 60% per commit while keeping logical coherence.

Default thresholds:

• max-files: 25 files changed
• max-lines: 800 total added + deleted lines (approx.)
• min-efficiency: 60% target

When to COMBINE (not split):

• Deletion-heavy changes + related additions = single commit
• Small docs/chore changes + the feat/fix they support = single commit
• Removed file + its replacement = single commit
• Config cleanup + new config = single commit

When to SPLIT:

• Changes are completely unrelated (different features)
• Single commit would exceed max-files/max-lines AND efficiency is already > 70%
• Different concerns that each have good efficiency independently

Goal: "Maximum efficiency with logical coherence" not "one commit per type".

3) Stage changes in controlled parts

If nothing is staged, do not blindly run git add . when the diff is large.

Hard rule (to prevent exclusion):

• Never stage all changed files in one shot (git add ., git add -A, git add --all) when the working tree contains many files/lines.
• Always stage only a subset per commit (by hunk or by path), then commit, then continue with the next subset.

Stage by path (grouping by directory/module):

git add path/to/moduleA
git add path/to/moduleB

If you must stage “everything” for a small change set, do it only when you are safely below thresholds (e.g., files/lines), otherwise split first.

After staging each part, confirm:

git diff --staged --stat
git diff --staged

4) Generate a single-line conventional commit message (no emoji, no body)

Commit message must be one line only, format:

<type>(optional-scope): <imperative subject>

Rules:

• No emoji.
• No second -m and no multiline body.
• No Co-Authored-By or any co-author attribution lines.
• Keep under ~72 characters.
• Imperative mood (e.g., "add", "fix", "remove", "refactor").

Create the commit:

git commit -m "<type>: <subject>"

5) Repeat for additional parts (if split)

For each commit part:

1. Stage the part
2. Review git diff --staged
3. Commit with a one-line conventional message
4. Continue until all intended changes are committed

6) Push to the requested branch (and main as required)

At the end, push using exactly:

git push -u origin main <branch>

Where <branch> is the target branch name (example: feature/xyz).

If --branch was not provided, use the current branch name:

git rev-parse --abbrev-ref HEAD

---

Conventional Commit Types (No Emoji)

Use one of:

• feat: new feature
• fix: bug fix
• docs: documentation only
• style: formatting only (no logic)
• refactor: code change without feat/fix
• perf: performance improvement
• test: tests only
• chore: tooling/config/housekeeping
• ci: CI/CD related

---

Commit Grouping Strategy (Efficiency-First)

COMBINE into single commit when:

Scenario	Why Combine	Example Type
Deletion + replacement	Avoid low efficiency	refactor
Small docs + main feature	Docs support the feature	feat
Config removal + new config	Related changes	chore
Cleanup + new implementation	Cleanup enables the new code	feat or refactor
Test removal + new tests	Tests are replaced	test

SPLIT into separate commits when:

Scenario	Why Split	Condition
Unrelated features	Different purposes	Each has efficiency > 60%
Independent bug fixes	Easier to revert	Each has efficiency > 60%
Very large changes	Avoid exclusion	> 25 files OR > 800 lines

Commit Type Selection (when combining)

Use the dominant change type:

• feat + small docs/chore → feat
• fix + related refactor → fix
• refactor + cleanup de