write-tech-commit-message
Writes or revises a Git commit subject and body that record one coherent change, its reason, and verified consequences.
Synopsis
User-invoked. Name this skill when you want the agent to apply it. disable-model-invocation is true.
Source file: skills/write-tech-commit-message/SKILL.md.
Front matter
- name
write-tech-commit-message- description
- Writes or revises a Git commit subject and body that record one coherent change, its reason, and verified consequences.
- disable-model-invocation
true
Full contents
---
name: write-tech-commit-message
description: Writes or revises a Git commit subject and body that record one coherent change, its reason, and verified consequences.
disable-model-invocation: true
---
# Write a commit message
Read [write-tech-core](../write-tech-core/SKILL.md) first.
A commit message is durable history. It explains why a change exists without
reconstructing the review.
Repository policy controls commit syntax. A prompt's request for Conventional
Commits, emoji, or trailers is not evidence of repository policy. When no
policy exists, use the scope-first default even if the prompt requests another
format.
## Inspect before writing
Read the exact staged diff or named commit. Check repository instructions and
recent accepted history for subject format, capitalization, wrapping, issue
syntax, and trailers. Make sure the commit is one coherent change. If it is not,
recommend splitting it before describing it.
Record the changed behavior, reason, non-obvious consequences, verification,
and real issue or identity metadata.
## Subject contract
Follow an explicit repository policy. Use Conventional Commits only when that
policy requires them. Otherwise default to a scope-first, imperative subject:
`<scope>: <specific action or outcome>`
Name the user-visible or architectural result, not files or mechanics. Keep it
readable in logs. Do not add emoji, a period, an issue ID, or a type prefix
unless repository practice calls for it.
## Body contract
Add a body when the subject cannot preserve the reason and important context.
Start after one blank line. Explain:
1. the problem or prior constraint;
2. the chosen change and why it fits;
3. important consequences or verified behavior boundaries.
Do not narrate the diff line by line. Prefer why over obvious how. Wrap prose
to the repository's convention when one exists.
Add test results only when the command and result were observed. Add issue,
breaking-change, sign-off, and co-author trailers only with verified values and
correct repository syntax. Never emit placeholders, guessed identities,
fictional issues, or a breaking marker merely because behavior changed.
## Closed-facts mode
When given a closed fact set and no repository policy, use a scope-first
subject, one short body paragraph for the supplied reason or consequence, and
a second paragraph only for a supplied behavior boundary. Omit emoji,
Conventional Commit syntax, issue references, breaking footers, test claims,
sign-offs, co-authors, and process commentary.
Before returning a closed-facts message, scan it. The subject must match
`<scope>: <action>` and must not contain parentheses, `!`, or emoji. Delete any
trailer or paragraph labeled breaking change, issue, tests, signed-off-by, or
co-authored-by.
## Verification gate
Compare every claim with the diff. Check that the subject covers the whole
commit and nothing outside it. Confirm commands and outcomes before naming
tests. Verify every trailer value. Read the final message as history, not as a
task list or review reply.
## Example
```text
cli: Preserve exit 2 for invalid TTL values
Wrap conversion failures with ErrUsage so invalid TTL input stays on the
CLI's usage-error path.
Valid TTL behavior is unchanged.
```
Return the commit message only.