commit-message
Reviews working-tree changes, then drafts a Conventional Commits title/body and states the semantic-release version bump a single such commit would imply. Also notes which defensive-code categories were touched. Use when the user wants to commit recent work, prepare a Conventional Commits message, or asks for semantic-release / semver-consistent messaging before git commit.
- License 许可
- MIT
- 最近更新
- 2026-11-10
- Stars
- ★ 290
- Forks
- 24
01 前言 Front Matter
- name
- commit-message
- model
- haiku
- effort
- standard
- description
- Reviews working-tree changes, then drafts a Conventional Commits title/body and states the semantic-release version bump a single such commit would imply. Also notes which defensive-code categories were touched. Use when the user wants to commit recent work, prepare a Conventional Commits message, or asks for semantic-release / semver-consistent messaging before git commit.
02 资源文件 1
- 参考文档REFERENCE.md4.0 KB
03 SKILL.md 正文
<!-- story: e82s02 -->
Commit Message
HARD GATE — HARD GATE — Commits must follow Conventional Commits spec (type(scope): description). Do NOT use vague messages like 'fix' or 'updates.' The message must explain the 'why,' not the 'what.'
Modes
- Default: standard Conventional Commits message
- --fix-type: Forces type=fix. Use when commit type is unambiguous.
What "last chat" means
- Primary source of truth: Read
state.yamlvcs.kind. Git usesgit status,git diff, andgit diff --cached; Jujutsu usesjj status,jj diff, andjj log -r @. Run in the repo root. - Context: use the current conversation to summarize intent and to spot breaking API/behavior changes that diff alone may not show.
- If the user tracks a session baseline (e.g. branch, tag, or
git stash createat start), you maygit diff <baseline>..HEADplus uncommitted diffs; otherwise use only the index and working tree.
Quick workflow
- Inventory — List changed paths; group by feature vs chore vs docs vs test-only.
- Decide commit shape — One atomic commit is ideal. If the diff mixes unrelated concerns, recommend multiple commits (each with its own type/scope) before suggesting one message.
- Classify for semantic release —
fix→ patch,feat→ minor, breaking → major. - Write the message —
type(optional-scope)!: description(see REFERENCE.md). Use!or aBREAKING CHANGE:footer when behavior contracts change. - Note defensive-code categories touched — from CONVENTIONS.md: Rate limit | Retry with backoff | Circuit breaker | Timeout | Graceful degradation
- Note fix-ratio contribution — Each
fix:commit counts towardmetrics.commit_ratio.fixinspecs/state.yaml. Afterrelease-branch,session-staterecalculates the ratio automatically. A high fix rate (>30%) triggers a deploy + smoke-test suggestion. - Deliver — Output:
- Proposed full commit message (title + optional body + footers).
- Release bump this commit would drive:
patch|minor|major|none. - Optional native command: Git
git commit -m; Jujutsujj commit -m. Never omit-mor run destructive commands unless asked.
Checklist before finalizing
- [ ] Audit pass confirmed (HARD GATE — Issue #182): In active epic flow,
bash scripts/lib/assert-epic-gate.sh commitpasses. - [ ] Type matches the dominant user-visible outcome (
featvsfixvsperf, etc.). - [ ] Scope is a short noun in parentheses if it helps (e.g.
fix(api): …). - [ ] Breaking changes are explicit (
!and/orBREAKING CHANGE:in the body/footer). - [ ] Description is imperative, lowercase start after the prefix, no trailing period in the title line.
- [ ] NO
Co-authored-byorCo-Authored-Byfooters — P1 rule (CONVENTIONS.md § Git Attribution). All commits must appear as if authored solely by the human user. The git hook andland-branch.shboth block these.
When not to invent a bump
If the repo uses a custom @semantic-release/commit-analyzer preset, note that your bump is heuristic and they should match .releaserc / release.config.*. See REFERENCE.md.
Further reading
- REFERENCE.md — Message shape, footers, release mapping, squashing notes.
Handoff
Gate: READY -> next: release-branch Writes: state.yaml handoff.next_skill = release-branch
04 同仓库更多 Skills
skill-verify-fail-open-fixture
Negative-path fixture for run-skill-verify.sh — must never PASS.
negative-path
暂无简介
write-document
Write, organize, and sync high-integrity technical documents using the BMAD methodology. Ensures every document is Bold, Minimal, Actionable, and Durable. Use when creating architectural docs, technical guides, or organizing the specs/ directory.
wire-observability
Add structured JSON logging, observability commands, and idempotent setup scripts to a project. Use when a project needs production-readiness instrumentation, when user wants structured logging, or as a production-readiness gate at any phase of development.
wire-ci
CI pipeline setup with bundled, forge-neutral templates and local validation. Detects the forge from the git remote, generates workflows for supported forges, and skips honestly for the rest. The CI equivalent of wire-observability.
visual-dashboard
Start a browser-based dashboard that visualizes architecture, implementation plans, and project status. Persists artifacts in .bigpowers/dashboard/. Reads specs/state.yaml, release-plan.yaml, epics, and planning-status via HTTP API or opencode panel.