Smart Commit

Trigger

Workflow

1. Check current state and identify what to commit.
2. Run quality gates (lint, typecheck, tests on affected files).
3. Scan staged changes for issues.
4. Draft a conventional commit message from the diff.
5. Stage specific files, create the commit.
6. Prompt for learnings from this change.

Commands

git status
git diff --stat

npm run lint 2>&1 | tail -5
npm run typecheck 2>&1 | tail -5
npm test -- --changed --passWithNoTests 2>&1 | tail -10

git add <specific files>
git commit -m "<type>(<scope>): <summary>"

Code Review Scan

• console.log

  /

  debugger

  statements (suppressed in test files — see Review Suppressions)
• TODO/FIXME/HACK comments without ticket references (e.g.,

  TODO(JIRA-123)

  is fine)
• Hardcoded secrets or API keys
• Leftover test-only code

Commit Message Format

<type>(<scope>): <short summary>

<body - what changed and why>

Guardrails

• Never skip quality gates unless user explicitly says to.
• Stage specific files by name. Never

  git add -A

  or

  git add .

  .
• Summary under 72 characters. Body explains why, not what.
• No generic messages ("fix bug", "update code").
• Reference issue numbers when applicable.

Output

• Quality gate results (pass/fail)
• Issues found in staged changes
• Suggested commit message
• Commit hash after committing
• Prompt: any learnings to capture?

Review Suppressions

• Threshold, config value, or feature flag changes (limits, timeouts, retry counts)
• Import reordering that does not change runtime behavior
• Whitespace-only or formatting-only changes
• Adding or removing

  console.log

  in test files
• TODO/FIXME comments (tracked separately in issue trackers)
• Variable or parameter renames that do not change behavior