Skip to main content

commit

Stage and commit changes with a clear, concise commit message.

소스 정보

저장소
antiwork/gumroad
최근 소스 활동
2026년 4월 29일 19:22
감지된 SKILL.md 언어
영어
스타
9,946
포크
2,080

설치 방법

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

소스 파일 검토

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

SKILL.md 표시 중

SKILL.md
소스 지침 · 읽기 전용 미리보기
name
commit
description
Stage and commit changes with a clear, concise commit message.
argument-hint
["optional message hint"]
allowed-tools
Bash(git *)
# Commit Create a commit for the current changes. ## Steps 1. Run `git status` (without `-uall`) to see untracked and modified files. 2. Run `git diff` and `git diff --cached` to understand staged and unstaged changes. 3. Run `git log --oneline -5` to see recent commit style. 4. **Run `bin/test-confidence` to verify your changes don't break anything.** Opus analyzes your diff and runs the right tests. Wait for 99% confidence (green bar) before proceeding. If any test fails, fix it first. 5. **Run linters on changed files before staging:** - Ruby files: `bundle exec rubocop --force-exclusion -a <files>` - JS/TS files: `npm run lint-fast -- --max-warnings 0 --fix --no-warn-ignored <files>` - TypeScript type check: `npx tsc --noEmit` (required, catches type errors that eslint skips) - CSS/SCSS/JSON/MD files: `npx prettier --write <files>` - SVG files: `npx svgo --multipass <files>` - Fix any lint errors or type errors before proceeding. Do not commit code that fails linting or type checking. 6. Stage the relevant files by name — avoid `git add -A` or `git add .`. 7. Write a commit message and commit. If `$ARGUMENTS` is provided, use it as a hint for the message. ## Commit message rules - Use the imperative mood ("Add", "Fix", "Remove", not "Added", "Fixes", "Removed"). - Be concise: one short sentence, ideally under 50 characters. - Do NOT use conventional commit prefixes (no `feat:`, `fix:`, `chore:`, etc.). - Do NOT add any `Co-Authored-By` or similar trailers. - Focus on **what** changed and **why**, not how. - If a second line is needed for context, keep it brief. ## Examples of good messages - `Prevent discount code from being cleared on edit` - `Add integration test for offer code persistence` - `Remove unused legacy export helper` - `Fix thumbnail missing in upsell insert` $ARGUMENTS
GitHub에서 보기