mcpField
S
smart-commit

smart-commit

github.com/rohitg00Development2.9k173 installsUpdated 4w ago
Repository

About smart-commit

smart-commit is a commit workflow skill for coding agents. It runs quality checks, reviews staged production changes, and guides specific-file staging and conventional commit messages.

Key features

  1. 01Runs lint, typecheck, and affected tests
  2. 02Scans staged code for common issues
  3. 03Drafts conventional commit messages
  4. 04Stages named files and commits
  5. 05Reports checks and commit hash

Use cases

  1. 01Preparing a code change for commit
  2. 02Checking staged production code before committing
  3. 03Creating a commit that follows project guardrails

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/rohitg00/pro-workflow --skill smart-commit

After installing, type/smart-commitin Claude Code to confirm it loaded.

Details

From the project README

Smart Commit

Trigger

Use when saying "commit", "save changes", or ready to commit after making changes.

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

Before committing, check staged changes in production code (not test files) for:

  • 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

Flag any issues before proceeding.

Commit Message Format

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

<body - what changed and why>

Types: feat, fix, refactor, test, docs, chore, perf, ci, style

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

Do NOT flag these during the pre-commit scan. They add noise without catching real bugs:

  • 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

Comments

Markdown supported