Skip to main content

smart-commit

Run quality gates, review staged changes for issues, and create a well-crafted conventional commit. Use when saying "commit", "git commit", "save my changes", or ready to commit after making changes.

Informações da origem

Repositório
rohitg00/pro-workflow
Última atividade na origem
18 de julho de 2026 às 11:22
Idioma detectado do SKILL.md
inglês
Estrelas
2.936
Forks
300

Opções de instalação

Por padrão, está selecionado o prompt que primeiro revisa a origem. Você pode mudar para um comando direto ou baixar uma cópia local.

Revise os arquivos de origem

Leia o SKILL.md e os arquivos complementares exibidos pelo SkillsMP antes de decidir se vai instalar.

Exibindo SKILL.md

SKILL.md
Instruções da origem · Visualização somente leitura
name
smart-commit
description
Run quality gates, review staged changes for issues, and create a well-crafted conventional commit. Use when saying "commit", "git commit", "save my changes", or ready to commit after making changes.
user-invocable
true
# 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 ```bash 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
Ver no GitHub