메뉴
Conventional Commits v1.0.0 standards for git messages. Use when (1) creating git commits, (2) writing or drafting commit messages, (3) reviewing commit message format, (4) explaining commit conventions, or (5) validating commit message compliance.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | conventional-commit |
| description | Conventional Commits v1.0.0 standards for git messages. Use when (1) creating git commits, (2) writing or drafting commit messages, (3) reviewing commit message format, (4) explaining commit conventions, or (5) validating commit message compliance. |
| argument-hint | [commit message or description of changes] |
Create git commits following Conventional Commits v1.0.0.
When invoked with arguments, commit staged changes with a message for: $ARGUMENTS
This skill applies only to git commit messages. Do not apply these conventions to PR titles, branch names, changelog entries, or release notes unless explicitly requested.
git diff --cached to inspect staged changesgit commit -m "<message>" (use a HEREDOC for multi-line messages)<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
| Type | Purpose |
|---|---|
feat | New feature |
fix | Bug fix |
docs | Documentation only |
style | Formatting, whitespace |
refactor | Neither fix nor feature |
perf | Performance improvement |
test | Adding or updating tests |
build | Build system or dependencies |
ci | CI configuration |
chore | Maintenance tasks |
Scope is optional. When used, set it to the module, component, or area of the codebase affected.
Derive scopes from the project structure. Use directory names or module names, not file names.
Examples: feat(auth):, fix(api):, docs(readme):, refactor(db):
Omit scope when the change is cross-cutting or affects the project root.
Use imperative mood: "add feature" not "added feature" or "adds feature". Lowercase the first letter after the type prefix. Omit trailing period. Limit to 50 characters.
Wrap at 72 characters. Explain what changed and why, not how.
Separate the body from the description with one blank line.
Use the body for context the diff alone does not convey: motivation, trade-offs, or constraints that influenced the approach.
Do not include any of the following in commit messages:
Simple:
docs: correct spelling of CHANGELOG
With scope:
feat(lang): add Polish language
Breaking change:
feat!: send email to customer when product ships
BREAKING CHANGE: customers now receive emails by default.
With body:
fix: prevent duplicate form submissions
Disables submit button after first click and adds
debounce to the handler.
With footer:
fix: resolve race condition in auth flow
Refs: #123
Reviewed-by: Alice
Fetches a Jira ticket and starts implementation with a branch and plan. Use when (1) starting work on a Jira ticket, (2) creating a feature branch from a Jira issue, (3) beginning implementation of a story or task, (4) picking up a ticket from the backlog, or (5) user provides a Jira ticket ID to work on.
Cleans up code files by removing dead code, simplifying structure, and eliminating redundancy without changing behavior. Use when (1) cleaning up code after implementation, (2) reducing complexity in a file or function, (3) removing dead code and unused imports, (4) simplifying control flow and expressions, (5) applying modern language idioms to legacy patterns, or (6) improving readability of dense or convoluted code.
Resolve open PR review discussions by evaluating applicability and value, then fixing valid feedback with conventional commits. Use when (1) addressing reviewer feedback on a pull request, (2) resolving open PR discussions systematically, (3) triaging PR review comments for actionability, (4) batch-fixing code review feedback, or (5) cleaning up unresolved PR conversations.
Optimizes markdown documents for token efficiency, clarity, and LLM consumption. Use when (1) a markdown file needs streamlining for use as LLM context, (2) reducing token count in documentation without losing meaning, (3) converting verbose docs into concise reference material, (4) improving structure and scannability of markdown files, or (5) preparing best-practices or knowledge docs for agent consumption.
Convert complex implementation plans into focused, autonomous agent sprints with measurable acceptance criteria. Use when (1) decomposing a large plan into agent-executable chunks, (2) breaking down multi-endpoint migrations or multi-step projects, (3) creating sprint definitions with acceptance criteria for autonomous agents, (4) planning dependency chains across implementation sprints, or (5) structuring work for parallel agent execution.
Analyzes and improves LLM prompts and agent instructions for token efficiency, determinism, and clarity. Use when (1) writing a new system prompt, skill, or CLAUDE.md file, (2) reviewing or improving an existing prompt for clarity and efficiency, (3) diagnosing why a prompt produces inconsistent or unexpected results, (4) converting natural language instructions into imperative LLM directives, or (5) evaluating prompt anti-patterns and suggesting fixes. Applies to all LLM platforms (Claude, GPT, Gemini, Llama).