원클릭으로
git-commit-helper
Create well-structured git commits from analyzed changes. Use when the user asks to commit, save work, or create a commit.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
Create well-structured git commits from analyzed changes. Use when the user asks to commit, save work, or create a commit.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
Write, refactor, restructure, edit, or audit technical documentation using the Diátaxis framework (tutorials, how-to guides, reference, explanation). Produces clear, concise, scannable docs and fights the default tendency toward bloated, over-explained AI prose. Use this skill for ANY documentation work — README and CONTRIBUTING files, API/reference docs, runbooks, guides, getting-started pages, conceptual write-ups, docs-site content, or doc reviews — even when the user just says "document this," "write docs for X," "clean up these docs," "explain how this works in the docs," or "what's missing from our documentation." If the deliverable is documentation, reach for this skill rather than writing prose freehand.
Retroactively create Linear tickets and PRs from untracked commits. Use for commits without tickets, "founder mode", or formalizing experimental work.
Find architectural friction and propose deep-module refactors as RFC issues. Use to improve architecture, find refactoring opportunities, or deepen shallow modules.
Initialize the AI Engineering Harness (AGENTS.md + thoughts/ structure). Use on /init_harness or when setting up the harness in a repo.
Interview the user relentlessly to stress-test a plan or design. Use to validate design decisions, "drill in", or "ask me questions" before implementation.
Observability Driven Development (ODD) — design the trace before the feature. Use for "ODD", "instrument first", "telemetry-driven", or a local OTel feedback loop with the Aspire dashboard.
SOC 직업 분류 기준
| name | git-commit-helper |
| description | Create well-structured git commits from analyzed changes. Use when the user asks to commit, save work, or create a commit. |
| allowed-tools | Read, Bash, Grep, Glob |
Run in parallel to understand the changes:
git status # changed files
git diff # unstaged modifications
git diff --staged # staged changes
git log --oneline -n 5 # recent commit style
Show the user before executing, then wait for confirmation:
I plan to create [N] commit(s) with these changes:
Commit 1:
Files: [specific files]
Message: [proposed message in imperative mood]
[Commit 2, 3, ... if multiple]
Shall I proceed?
# Add files explicitly by path — NEVER use `git add -A`, `git add .`, or `git commit -a`
git add path/to/file1.ts path/to/file2.ts
git commit -m "Add social login support"
git log --oneline -n [number of commits created]
Format: [Imperative verb] [what] [optional: why] with an optional detailed body.
Add user authentication to API endpoints, Fix race condition in event processingUpdated stuff, Fixed bug, Changes, WIPUse imperative mood ("Add", not "Added"/"Adding"). When the "what" isn't obvious from the diff, explain the "why" — e.g. Use Redis for rate limiting to support distributed deployment.
Multi-change example:
git add src/feature.ts src/feature.test.ts docs/feature.md
git commit -m "Add user analytics feature
- Implement tracking service
- Add unit tests
- Update documentation"
NEVER add co-author info, Co-Authored-By lines, or "Generated with Claude"-style messages. Write commit messages as if the user wrote them — authored solely by the user with no AI attribution.
You have full context of this session — use it to write meaningful messages. The user asked you to commit, so trust your judgment and don't ask unnecessary questions.
git status clean): tell the user there is nothing to commit.This skill does not push. It creates clean, atomic commits with the user's approval, and all git operations are shown transparently.