Commit Command

Create git commits, automatically grouped into logical units, with optional push and PR creation.

Usage

• /mella:commit — Commit all changes (auto-grouped if genuinely unrelated)
• /mella:commit push — Commit and push to current branch
• /mella:commit push origin/feature-branch — Commit and push to specific branch
• /mella:commit pr — Commit, push, and create or update a PR
• /mella:commit pr draft — Same, but a new PR is created as a draft

Argument Parsing

Check $ARGUMENTS for flags: pr, draft, push. For push, extract the next token as the target branch if present. pr implies push; draft only has effect alongside pr.

Committing

1. Analyze: git status, git diff HEAD, and git log -5 --oneline to understand the changes and the repo's commit style.
   • Clean working tree is not an error. If there is nothing to commit, skip the remaining commit steps. With push or pr, continue with the branch's existing commits — push mode still pushes, PR mode still creates or updates the PR. Only stop if the tree is clean and no flags were given (report that there is nothing to commit).
2. Decide the split: default to a single commit. Split into multiple commits only when the changes contain clearly unrelated sets — e.g. a dependency bump alongside an unrelated bug fix. When in doubt, one commit. Never separate tests, docs, or config from the feature they belong to.
3. Commit: for each unit, git add <files> → conventional commit message (type(scope): subject, imperative mood) → commit.
4. Verify: git log --oneline -n <N> and git status to confirm everything is committed.

Push Mode (push flag)

After all commits are created:

• Branch specified after push: git push origin HEAD:<branch>
• No branch: git push (use git push -u origin <branch> if the branch has no upstream)

If push fails, stop and explain the error.

Pull Request Mode (pr flag)

pr implies push. If the current branch is the repository's default branch (main/master), stop and report — do not invent a branch. A clean working tree does not block this mode: if the branch already has unpushed or pushed commits, proceed straight to the PR steps below.

Run gh pr view --json number,title,url,body to check for an existing PR:

• No PR: after committing and pushing, compose the title and description yourself per the standards below and run gh pr create --title ... --body ... (add --draft if the draft flag was given). Never use --fill. Display the new PR URL.
• PR exists: push the new commits and display the PR URL. Update the PR's title/description only if the new commits materially change what the PR proposes (new behavior, changed scope). A trivial addition — review fixes, a typo, a small follow-through — leaves the existing title and description untouched.

PR title

The title is the merge commit's subject line. Same rules as commit subjects: type(scope): subject, imperative mood, ≤ 70 characters, describing the change itself — not the activity ("feat(auth): add rate limiting to login endpoint", never "Updates and fixes for auth"). If the branch can't be titled in one crisp line, say so — it is doing too many things.

PR description

The reviewer can already see the diff. The description's only job is what the diff cannot say. Write 2–6 sentences of plain prose — no section headings like "Why", "What", "Summary", or "Tests" (bullets only if there are multiple distinct behavioral changes) — covering:

1. Why — the problem or goal that motivated the change; the context a reviewer needs before reading code.
2. What, at the behavior level — the user-visible or API-visible effect. Not file-by-file mechanics.
3. Only when genuinely present: breaking changes, deliberate trade-offs, or a non-obvious decision a reviewer would otherwise question.
4. Issue link — Closes #N when the change resolves a tracked issue.

Scale to the change: a one-line fix gets a one-line description.

Never include:

• How the change was implemented — the diff shows that.
• Tests, in any form: no "Tests"/"Test plan" section, no listing of new or existing test cases, no narration ("ran the tests, all passing") — passing tests are implied by the PR existing.
• Follow-ups, future work, or "next steps".
• Process artifacts: plans, phases, "as discussed", tool or agent mentions.
• File-by-file change lists.

Rules

• Respect staged changes — keep them staged and include them in the appropriate commit.
• Always use conventional commit style (imperative mood).
• Never use --amend, --force, or other destructive operations.
• Stop and explain on commit failure — do not continue with remaining commits.