菜单
Use when asked to commit, save, or persist changes to Git. Handles atomic commits, branch safety, Conventional Commits format, and project style matching. Do NOT use for pushing, creating PRs, or branch management beyond safety checks.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Create, update, and validate Architecture Decision Records (ADRs) following MADR 4.0 format. Use when the user mentions ADR, architecture decision, decision record, or asks to document a technical decision. Also use when creating new files in docs/decisions/. Handles numbering, frontmatter, section structure, and README index updates. Do NOT use for general documentation or non-architectural decisions.
Ensures correct Node.js version before npm operations. Use BEFORE running any npm or npx commands. Reads .tool-versions, compares with active Node.js version, and switches via asdf if needed.
Use when asked to create a pull request, open a PR, or submit changes for review. Handles branch verification, change analysis, title and description generation, and gh pr create. Do NOT use for committing (use git-commit), pushing without PR, or reviewing existing PRs.
| name | git-commit |
| description | Use when asked to commit, save, or persist changes to Git. Handles atomic commits, branch safety, Conventional Commits format, and project style matching. Do NOT use for pushing, creating PRs, or branch management beyond safety checks. |
git status --short
git diff
git diff --cached
Each commit = one logical change. Split unrelated changes into separate commits.
| Situation | Commits |
|---|---|
| New service + its tests | 1 commit |
| New feature + unrelated config fix | 2 commits |
| Multiple files for one feature | 1 commit |
git branch --show-current
Protected branches: main, master, develop, release/*, hotfix/*.
STOP if on a protected branch. Do not commit. Do not proceed to Step 3. Instead:
<branch> — it is a protected branch."git checkout -b <type>/<kebab-description>If on a feature branch: proceed.
Format: <type>/<kebab-case-description>
| Type | Use Case | Example |
|---|---|---|
feat | New feature | feat/bill-reminders |
fix | Bug fix | fix/null-amount-validation |
refactor | Code restructuring | refactor/extract-payment-service |
chore | Maintenance tasks | chore/update-dependencies |
docs | Documentation | docs/api-reference |
test | Test additions | test/payment-service-coverage |
git log --format="%s" -20
Identify vocabulary, detail level, scope patterns. Mimic the project's phrasing while following Conventional Commits format.
See references/commit-format.md for type table, rules, and anti-patterns.
git add <files>
git commit -m "<type>[scope]: <description>"
For multi-line messages:
git commit -m "<subject>" -m "<body>"
Subject line: imperative mood, under 72 chars, no period, English only. Body (if needed): wrap at 72 chars, explain what and why.
Do not reference docs/architecture.md, docs/decisions/, section numbers,
ADR numbers, or TODO IDs in commit messages. Those belong in specs and plans,
not in the git history.
git log --oneline -1
git show --stat HEAD
Report: commit hash, files changed, insertions/deletions.
| Error | Fix |
|---|---|
| "nothing to commit" | Check git status, verify files have changes |
| Pre-commit hook fails | Read the error, fix the issue, create a NEW commit (do not amend) |
| Wrong files committed | git reset --soft HEAD~1, re-stage correctly, commit again |
If the user also asked to create a PR, invoke the creating-pr skill after
committing. Do not hand-roll gh pr create — the skill has a required template.