Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
직접 명령은 검토 Prompt를 거치지 않습니다. 실행하기 전에 소스를 확인하세요.
npx skills add https://github.com/tomevault-io/skills-registry --skill git-commit명령은 한 줄로 유지됩니다. 복사하기 전에 가로로 스크롤해 전체 내용을 확인하세요.
로컬 사본을 원하시나요? SkillsMP에서 현재 제공할 수 있는 파일을 다운로드하세요.
| Use when this capability is needed.
> Use when this capability is needed.
Review architecture and API design for the vfs-s3 project. Use when the user mentions @architect, asks to review an issue's design, discuss module boundaries, API shape, or architectural decisions for vfs-s3. Also trigger when the user wants to create an ADR (Architecture Decision Record) or evaluate a technical approach for the project. Intended for dispatch from Codex automation or Claude routines; GitHub trigger phrase: @vfs-s3-bot please prepare design doc Use when this capability is needed.
SOC 직업 분류 기준
SKILL.md 표시 중
| name | git-commit |
| description | > Use when this capability is needed. |
This skill gates every commit behind a test run and user confirmation. The goal is to avoid broken commits and ensure the message accurately reflects the change.
Run git status and git diff HEAD --name-only to see which files are modified,
staged, or untracked. Group them by area:
If nothing has changed, tell the user and stop.
Run only the tests relevant to what changed. This keeps the feedback loop fast.
| Changed area | Command |
|---|---|
src/ | mvn test |
webapp/ | cd webapp && npm run build && npm run lint && npm test --run |
Run each applicable command. If any test run fails, stop immediately and show the failure output. Do not proceed to staging or committing. Explain which area failed and what the user should fix.
If all tests pass, summarise the result briefly (e.g. "✓ 111 tests passed in api module") and continue.
List the files you intend to stage. Use git diff HEAD --name-only and
git ls-files --others --exclude-standard for untracked files.
Exclude files that should not be committed:
.claude/settings.local.json (personal local settings).env* filestarget/ or node_modules/ contents (should be gitignored, but flag if not)Present the proposed file list to the user clearly. If there are files you are unsure about, flag them and ask.
Analyse the diff with git diff HEAD and draft a commit message following the
project's convention:
<type>: <short description>
<optional body — bullet points describing key changes>
Types: feat, fix, refactor, docs, test, chore, perf, ci
Keep the subject line under 72 characters. Use the body to capture the why and
what when the change is non-trivial. Do not include Co-Authored-By lines.
Present a summary to the user before doing anything irreversible:
Files to stage:
<list of files>
Commit message:
<type>: <subject>
<body if any>
Proceed? (yes / edit message / cancel)
Wait for the user's response:
Stage only the files from Step 3 (add them individually, not with git add -A
or git add ., to avoid accidentally staging sensitive files).
Commit with the confirmed message using a heredoc to avoid shell escaping issues:
git commit -m "$(cat <<'EOF'
<type>: <subject>
<body>
EOF
)"
Do not append Co-Authored-By or any attribution footer.
After the commit, run git log --oneline -3 and show the user the result so they
can confirm everything looks correct.
git push.git push -u origin <branch>.Source: gessnerfl/fake-smtp-server — distributed by TomeVault.