メニュー
Standards for structuring git commits during automated task execution. Covers message format, project style detection, atomic commit principles, scope assessment, and commit splitting. Read by build agents before committing work.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | git-committing |
| description | Standards for structuring git commits during automated task execution. Covers message format, project style detection, atomic commit principles, scope assessment, and commit splitting. Read by build agents before committing work. |
Standards for how agents create git commits during task execution. This skill defines message format, style detection, atomicity rules, and scope assessment. It does not define a user-facing command — it is reference material for agents that commit as part of their work.
Before writing any commit message, detect the project's existing style:
git log --oneline -20 and examine the outputfeat:, fix:, chore:, etc.). Only drop them and use verb-only format if the majority of recent commits do NOT use prefixes.The detected style applies to all commits in the session. Do not mix styles.
<prefix>: <what changed>
- <what was done detail 1>
- <what was done detail 2>
<FEAT-XXXX>
- <UC-XXXX>: <use case name>
- <SC-XXXX>: <scenario name>
- <SC-XXXX>: <scenario name>
The first line is the subject. The body (bullet points) is optional but recommended for non-trivial changes. The spec references block is mandatory when the commit has PRD context (see Spec References below). Separate each section with a blank line.
Start with a verb — capitalize the first letter (or follow prefix convention):
Maximum 50 characters — if it exceeds 50, move details to the body.
Describe what changed, not what was wrong:
Use simple language — avoid jargon when plain words work:
Use conventional prefixes by default (see Style Detection). Only drop them if the project's history shows the majority of commits without prefixes.
| Prefix | Use When |
|---|---|
feat: | New features or functionality |
fix: | Bug fixes |
test: | Adding or updating tests |
chore: | Maintenance, dependencies, config |
docs: | Documentation changes |
refactor: | Code restructuring without behavior change |
perf: | Performance improvements |
Use bullet points (hyphens, not paragraphs) to explain why when:
For simple, obvious changes, a single subject line is enough.
Place issue references at the end of the subject line in parentheses:
Fixes payment processing error (#123)
Do not use issue tracker language as the subject — "Resolves #123" says nothing about what changed.
When a commit is part of a task that has PRD context (feature, use cases, scenarios), include a spec references block at the end of the commit body.
FEAT-XXXX
- UC-XXXX: Use case name
- SC-XXXX: Scenario name
- SC-XXXX: Scenario name
- UC-XXXX: Use case name
- SC-XXXX: Scenario name
Mandatory — no exceptions.
Commits must look like normal human development. Focus on what changed, not how it was produced.
Each commit represents one logical change:
Do not mix unrelated changes:
Small, frequent commits are better than large, infrequent ones: easier to review, easier to revert, better git history.
After completing work, assess whether the changes should be one commit or multiple.
Changes are one logical concern when they all serve the same intent:
Judge by intent, not by file count.
Changes contain multiple independent concerns when:
When changes need splitting:
Before committing, verify the diff:
console.log, print statements, debugger).env files)git add .| Reference | Purpose |
|---|---|
| references/message-format.md | Detailed format rules, verb table, body guidelines |
| references/examples.md | Good and bad commit message examples |
Decompose a use case into ordered, independently-executable slices. Owns the slice file format — one Markdown file per slice, holding the contract surface and the test plan as language-tagged snippets and nested bullets. Referenced by /m:plan (default and cover modes) to emit the per-slice files the build consumes.
Engineering principles that bind any code Molcajete plans, builds, or reviews — integration tests as the trust contract, hexagonal default, dependency injection, 80% coverage floor, universal software craft (small functions, clear boundaries, no god files, refactor to reuse), technology-agnostic. Loaded by /m:plan and /m:build. Mirrored to the host project at `.claude/rules/principles.md` by /m:setup.
Technology-agnostic rules for the test-first build loop. Implementer and Validator role contracts, outer-edge mocking, reading specs/TECH-STACK.md, Runner Inference, coverage gate scoped to touched files, reactive refactor.
Rules and templates for the /m:setup command. One-shot foundation setup from a single project description plus codebase detection. Generates PROJECT.md, TECH-STACK.md, ACTORS.md, GLOSSARY.md, MODULES.md, DOMAINS.md, FEATURES.md, and .molcajete/settings.json.
Conventions for generating README.md files as LLM-optimized navigation documents. Covers YAML frontmatter, file tables, subdirectory tables, Mermaid diagrams, and stack-specific variants (backend, frontend, config). Used by /m:doc and the documentation task in build plans.
Status as first-class state on slices, use cases, and features. Defines the three-value enum (pending | dirty | implemented), per-level semantics, the bottom-up roll-up rule, and which command writes which level's status. Status lives on the artifact's frontmatter and is the source of truth — the CHANGELOG is for context and markers, not state.