chore: add git workflow skills

.codex/skills/git-atomic-commit/SKILL.md

@@ -0,0 +1,77 @@
+---
+name: git-atomic-commit
+description: Analyze the current Git working tree and create purpose-based atomic commits. Use when the user asks to commit changes, split changes into atomic commits, make suitable commit units, preview commit grouping, or run a dry-run commit plan.
+---
+
+# Git Atomic Commit
+
+Create commits by logical purpose, not by file count or directory. Preserve user changes, never revert unrelated work, and never skip hooks.
+
+## Workflow
+
+1. Gather context in parallel when possible:
+   - `git status --short --branch`
+   - `git diff --stat`
+   - `git diff --staged --stat`
+   - `git log -30 --oneline`
+   - `git branch --show-current`
+2. Detect commit style from recent history:
+   - Language: Korean or English.
+   - Shape: semantic (`feat: ...`), plain, or short imperative.
+   - Announce the detected style before committing.
+3. Inspect changed files and diffs enough to understand intent.
+4. Group changes by logical purpose:
+   - Same feature, fix, or refactor belongs in one commit, even across many files.
+   - Different purposes belong in different commits, even in the same directory.
+   - Tests belong with the implementation they verify.
+   - Config and lockfile changes belong with the change that required them unless they are independently meaningful.
+5. Present a concise commit plan with files and justification.
+6. If the user requested `--dry-run` or preview only, stop after the plan.
+7. Otherwise, stage and commit each group in dependency order.
+8. Verify the final status and report created commits.
+
+## Non-Negotiable Rules
+
+- Do not create one commit per file or one commit per directory.
+- Do not split tests from the implementation they cover.
+- Do not use `--no-verify`.
+- Do not amend pushed commits unless explicitly requested.
+- Do not commit secrets, `.env` files, credentials, or tokens. Stop and warn if they appear.
+- Do not revert or discard changes unless explicitly requested.
+- Match the detected repository commit style instead of defaulting blindly to semantic commits.
+
+## Commit Planning Heuristics
+
+- Prefer fewer, clearer commits over mechanical splitting.
+- Separate user-facing behavior, test infrastructure, documentation-only changes, and CI/release changes when they are independently reviewable.
+- Keep generated lockfile changes with dependency/package manifest changes.
+- If a clean atomic split is impossible because hunks in one file are interleaved, either use patch staging carefully or explain why a combined commit is the safer unit.
+
+## Output
+
+For a dry run:
+
+```text
+COMMIT PLAN (dry-run)
+=====================
+Would create N commits:
+
+COMMIT 1: feat: add OAuth2 login
+  - src/auth/oauth.ts
+  - src/auth/oauth.test.ts
+  Justification: implementation and tests for one feature
+```
+
+After committing:
+
+```text
+COMMIT SUMMARY
+==============
+Created N commits:
+
+1. abc1234 feat: add OAuth2 login
+   - src/auth/oauth.ts
+   - src/auth/oauth.test.ts
+```
+
+Also report whether the working tree is clean.

.codex/skills/git-atomic-commit/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: 'Git Atomic Commit'
+  short_description: 'Create purpose-based atomic commits.'
+  default_prompt: 'Use this skill to split my current Git changes into purpose-based atomic commits.'

.codex/skills/git-branch-name/SKILL.md

@@ -0,0 +1,74 @@
+---
+name: git-branch-name
+description: Generate conventional Git branch names from a task description, Korean or English request, work summary, or current Git changes. Use when the user asks for a branch name, wants to create a branch, or asks to infer a branch name from current work.
+---
+
+# Git Branch Name
+
+Generate a concise, safe branch name and show the ready-to-run checkout command. Do not execute Git commands unless the user explicitly asks to create the branch.
+
+## Workflow
+
+1. Parse the user's description for action, target, and context.
+2. If the request refers to "current work", "현재 작업", or similar, inspect local context with `git status --short`, `git diff --stat`, and available task context.
+3. Detect the branch type.
+4. Convert the core meaning into English kebab-case.
+5. Return the branch name, command, and brief analysis.
+
+## Branch Types
+
+Use these triggers to choose the prefix:
+
+| Type | Korean triggers | English triggers |
+| --- | --- | --- |
+| `feat` | 추가, 구현, 기능, 새로운, 만들기 | add, implement, feature, create, new |
+| `fix` | 수정, 버그, 오류, 에러, 해결, 고치기 | fix, bug, error, resolve, correct |
+| `chore` | 설정, 환경, 의존성, 빌드, 배포 | config, setup, build, deploy, dependency |
+| `docs` | 문서, README, 주석, 설명 | doc, readme, comment, documentation |
+| `refactor` | 리팩토링, 개선, 정리, 구조 | refactor, improve, cleanup, restructure |
+| `test` | 테스트, 검증, 스펙 | test, spec, verify |
+| `style` | 스타일, 포맷, 린트 | style, format, lint, css |
+
+Default to `feat` only when the type is genuinely unclear.
+
+## Naming Rules
+
+- Format: `{type}/{kebab-case-description}`
+- Use lowercase ASCII letters, numbers, and hyphens only.
+- Translate Korean keywords to concise English.
+- Keep the full branch name under 50 characters when practical.
+- Keep 2-4 essential words after the slash.
+- Remove filler words, punctuation, and implementation details that do not clarify the branch purpose.
+
+## Examples
+
+| Input | Output |
+| --- | --- |
+| `사용자 로그인 기능 추가` | `feat/user-login` |
+| `fix: 버튼 클릭 안됨` | `fix/button-click` |
+| `OAuth2 인증 구현` | `feat/oauth2-auth` |
+| `README 업데이트` | `docs/update-readme` |
+| `코드 정리 및 리팩토링` | `refactor/code-cleanup` |
+| `API 응답 에러 수정` | `fix/api-response-error` |
+| `테스트 케이스 추가` | `test/add-test-cases` |
+| `CI/CD 파이프라인 설정` | `chore/cicd-pipeline` |
+
+## Output
+
+For a successful request:
+
+```markdown
+**Branch Name:** `{generated-branch-name}`
+
+```bash
+git checkout -b {generated-branch-name}
+```
+
+**분석:**
+- Type: {detected-type}
+- Keywords: {extracted-keywords}
+```
+
+If the type is ambiguous, state that `feat` was chosen as the default.
+
+If there is no usable description and current work cannot be inferred, ask for a short task description.

.codex/skills/git-branch-name/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: 'Git Branch Name'
+  short_description: 'Generate conventional branch names.'
+  default_prompt: 'Use this skill to generate a safe conventional branch name and checkout command from my task description.'

.codex/skills/git-draft-pr/SKILL.md

@@ -0,0 +1,90 @@
+---
+name: git-draft-pr
+description: Create or update GitHub draft pull requests with concise Summary and Test sections. Use when the user asks to create a PR, make a draft PR, update an existing PR body, or prepare a pull request from the current branch.
+---
+
+# Git Draft PR
+
+Create a new draft PR or update an existing PR description with a concise body. Prefer GitHub CLI (`gh`) when available.
+
+## Mode Selection
+
+- Create mode: user asks to create a PR and does not specify update.
+- Update mode: user says update, `-u`, `--update`, or provides an existing PR number to edit.
+
+## Create Mode
+
+1. Validate Git state:
+   - `git status --porcelain`
+   - `git branch --show-current`
+   - `gh auth status`
+2. Stop if uncommitted changes exist. Tell the user to commit changes first unless they explicitly asked you to commit them as part of the task.
+3. Stop if the current branch is `main` or `master`; ask for or create a feature branch first depending on the user's request.
+4. Gather PR content from commits and diffs. If the purpose or implementation cannot be inferred confidently, ask:
+   - `이 PR의 목적이나 해결하려는 문제는 무엇인가요?`
+   - `구체적으로 어떻게 구현했나요? 주요 변경사항은?`
+5. Compose the body:
+
+```markdown
+## Summary
+- ...
+
+## Test
+- [ ] ...
+```
+
+6. Push the branch if it has no upstream:
+
+```bash
+git push -u origin $(git branch --show-current)
+```
+
+7. Create a draft PR:
+
+```bash
+gh pr create --draft --title "$TITLE" --body "$BODY"
+```
+
+## Update Mode
+
+1. Find the PR:
+   - If a PR number was provided: `gh pr view <number> --json number,title,url,body`
+   - Otherwise: `gh pr view --json number,title,url,body`
+2. Gather updated context from commits, diffs, and user-provided requirements.
+3. Show a concise preview of the new body before editing when the change is substantial.
+4. Update the PR:
+
+```bash
+gh pr edit <number> --body "$BODY"
+```
+
+## Body Guidelines
+
+- Keep the Summary focused on what changed and why.
+- Keep the Test section to commands actually run, or clearly mark unchecked items.
+- Mention UI screenshots only as a follow-up note when UI changes need visual evidence.
+- Do not invent tests.
+- If CI/release behavior changed, include the relevant workflow or command in Test.
+
+## Safety
+
+- Create PRs as draft by default.
+- Do not create a ready-for-review PR unless the user explicitly asks.
+- Do not edit an unrelated PR; verify the PR number, title, and URL first.
+- Do not push uncommitted changes.
+
+## Output
+
+For create success:
+
+```text
+Draft PR created: https://github.com/user/repo/pull/123
+```
+
+For update success:
+
+```text
+PR #123 updated: https://github.com/user/repo/pull/123
+```
+
+For failure, state the reason and the next concrete action.

.codex/skills/git-draft-pr/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: 'Git Draft PR'
+  short_description: 'Create or update GitHub draft PRs.'
+  default_prompt: 'Use this skill to create or update a draft GitHub PR for the current branch.'