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.

소스 정보

저장소
rohitg00/pro-workflow
최근 소스 활동
2026년 7월 18일 11:22
감지된 SKILL.md 언어
영어
스타
2,936
포크
300

설치 방법

기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.

소스 파일 검토

설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.

SKILL.md 표시 중

SKILL.md
소스 지침 · 읽기 전용 미리보기
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
GitHub에서 보기