From 72f16d26b89b49bb8c6519301e5453801c0d9ae2 Mon Sep 17 00:00:00 2001
From: Team <team@common-skills.local>
Date: Sat, 18 Apr 2026 13:06:47 +0800
Subject: [PATCH] feat(commit-message): add commit-message skill and agent
 config

- Add SKILL.md with workflow and guidelines for generating Conventional Commits messages
- Add agent config (.kiro/agents/commit-message.json) with tool permissions and skill resource
- Add evals (evals.json) with 3 test cases covering feat/fix/refactor scenarios
- Add Conventional Commits 1.0.0 reference documentation
- Add compiled skill bundle (commit-message.skill)
---
 .kiro/agents/commit-message.json              |  10 ++++
 commit-message.skill                          | Bin 0 -> 3177 bytes
 skills/commit-message/SKILL.md                |  47 ++++++++++++++++++
 skills/commit-message/evals/evals.json        |  20 ++++++++
 .../references/conventional-commits.md        |  46 +++++++++++++++++
 5 files changed, 123 insertions(+)
 create mode 100644 .kiro/agents/commit-message.json
 create mode 100644 commit-message.skill
 create mode 100644 skills/commit-message/SKILL.md
 create mode 100644 skills/commit-message/evals/evals.json
 create mode 100644 skills/commit-message/references/conventional-commits.md

diff --git a/.kiro/agents/commit-message.json b/.kiro/agents/commit-message.json
new file mode 100644
index 0000000..96d48ef
--- /dev/null
+++ b/.kiro/agents/commit-message.json
@@ -0,0 +1,10 @@
+{
+  "name": "commit-message",
+  "description": "Agent specializing in generating Conventional Commits messages.",
+  "prompt": "You are an expert at generating git commit messages following the Conventional Commits 1.0.0 specification. Your goal is to analyze staged changes and provide a high-quality, professional commit message. Always use the `commit-message` skill for guidance.",
+  "tools": ["fs_read", "execute_bash", "grep", "glob"],
+  "allowedTools": ["fs_read", "execute_bash", "grep", "glob"],
+  "resources": [
+    "skill://skills/commit-message/SKILL.md"
+  ]
+}
diff --git a/commit-message.skill b/commit-message.skill
new file mode 100644
index 0000000000000000000000000000000000000000..25cdbac0a6216acc1d8b26da324d8f6ee9f660ea
GIT binary patch
literal 3177
zcmai%X*d*)_Q%JXD8kqi*|LTaVT>#zWGPKC_I(+~FqUi$*<~5~7-R`Em5}X6WDSjE
zZ7`Hk_UzGEl63w4|L5N4zPR_f=e#)2InVQb`~7^+9TNsdAOHYh0kD=v**VqNp42e{
z02OEdz5oC)6Jt};tG;gWmS%o4Y8TqqtxPG2pWb<si3+S6gztueuXQuJ&~y40P6%|P
zi$W%=@utnsJ&gXX_4JBw-Ec+Kg0LUU?Q=MHYxu-Yfh;9h3MZUc+GOX&o_ig0ZMbGt
z!FFFZp!6NGaQ8>44L3=0Z+0TdFx4C3GoKSjl!*4GG@<-9a95vD>(Vr6V)0C@7S`2m
z>~cpcN}EDWKq2Dg+Gp+cERRv<HmU<+D_Qal>=n}IY#-+3JYPV6Z#&BJ_o5H84A0Su
zcoi-f&Ulk&%gW&KY)bjrbL}O9idgKo9_;Vo?;X-8K{u8IqVJ2jCXQ>Z(M{aKf4)Q^
z?@17Z_T^bBn*F%P0^Pk~G8&F!JPv|o>s(8_S$g030eusCpKyDoXD%VS>r@K3WyUz}
zU(^zl0t!G0;Tl7$scDZg98~RJRZ52~b<c)f5C_i8cM3LSD;m<ol@Pl2=`<NiXa8Qx
zdiTeh;b&^p<I-q|<tdD7Wr8=ERn1??IS=h#nb9n@-oa{3FJ9JasKEkHO*7R?9!Ghp
z{<W;FTsW&aiYHft_9=3j+(#Ws_64nxG4KVsTz5icLNI*|v8z|Zt2fD`*bKKkqbsY^
zS)OSbmV>h!_1LVWgALRbv6c2AeFdu_M({X+gc{gv=_D0jZ{`(cGe)oqHa+WMR=kG+
z6SF%zBuhHeA(RY!wR&4+F=I~tV(l93eK+#sGwmEaG-ge*sCYINQc_%_Y_~#xL+xp}
zQPsgss0gP%N%dvYgQ1?R#+RdENv>=obZ3(SFMWu{v`a|yqeEg5%H)Bsuh80k-L5-s
zxdV}vb~O>lPe=N1e>3&TY|zU0&>p)|jIxjCp~b^g*3er;Wc?30OA}x=v4Hpwq+qFF
zRJ-n#dS#?L{nsvL7evECeW3a61p!aT#Q}|p7V-jHl}N*%j9UG`3JqD)d)zl@3KF@N
z;|-VU$C+F|aL`kJtaMk1!+$u_W3Us!B{<JW<H`=*Td;f<2>c3UDsyZ3HJ?qjuvlBg
zm%=Fkb@|QEaTTd_ut%b`#L6qWr;WR2r$0bh#5j~|kX$s+J{;G6LdJ!fD;2O3qM@4c
zFv1@Jy^Rd@#q*F(X=aP}hGI)bqlw7LHtejH^qj0)8^wvO)rRb1GuwZGedcO1ne4;P
zA7xZ#V`t%HUiiiW9ND6y+b?yv#-oO6NQOJ<>1rBN=NL`aehH6!(Dl@F3o%*@Vl#^y
zp-_LMIN2k66-jsJ-OjUK`;Cr(&Axbqy!=Jfi6nL}X&Tu4*g*FQe&g^x1n(iR<WNxm
zrz!OPfbBQ9LwJ}ZvF~#lVkoNbW0)R;sPuYCoj7w8Av{*K-umOj45&5hiqFgo8{VF2
zlAO!S2+zfN++74ZVpeeG)_bPH`Huv!bl4P?Y&n=Pdq<^N*YAw_i}(}0-L8plJnd3l
z%)Lli`K~z^V>U0iHYkQ^G$Co-0V&6+MOussxCeI&v3J`pzXO^CFKcs*g{HzTjG|-R
zHg0>>9+o;rN=IQ721BdVpTinIgH5+<mh{c*wo^d@+PA;5+lr&>r>-x=jB-T+`zMe~
z&^{(%5jP&eW)8Bl+G6LOf7u%SsjUUr(`Pj?0|1&F0D#!3tp&JyxCgkST-^f|UHwoG
z+)+UYKa?|4!PU>#7ZDVAYIqo{&!`2p3mA%3ZNGkYm!%pNrMTr1jZ~XD-^zFGJ+Cw`
z9TX;Bm;_~&SnBorop$2TS>b8)K6A4|C!=@VOFeLTFn=dnz1hP+%FD+sjl--wmhaim
zlw$)NRep7Kr9+Y+S1nP(wiyrn%R#;evg7wuZJXto@iVLKT*eok^I?j7i-BkX==#R3
zytsoj(N)S@n3FAKLcOYrdw}z*a*Ef^=%mf6(rX)Ukt*9iQd@a83I^ia-?@h8jI(>%
z=Vw=S^d5Apf$lsOxBW%J2cQ{57W_@#l!>aQZUw`W{V3zd##{UT0(xMu#?E+E|I(xa
zR?4M=m&INKvT{gYTY14}rT;dRAaa;~jer-A1vlL>L1d`U%Nu(&oH2SE@$23pVbfc^
zJE}W4nVP2uQVaIo{w@C@xvbwIG1$bfW4h^8wpA11bAD(MeJaVXeq+oD^<i)Gu(Vz+
z157h)9&>)+FN*p~_ME<VQ6$iXL{dRZouhIfh*yp-L+~MN!<v_HmSNf$&-)aB^)&3M
z1BWP7MPyR7jvAJ33LkjH#o`*9ao<1|3Kz;spkq|lgR&e7mn}yVJ93ky27y3)7>F}%
zzqr~$4syS#i8;Qs6gyvpm3`4w01OJs)w`7^q&MAN1iw*R&;TlZDsOV4KHMg01z9k-
zZi-ZQ5@H{EPBRxR@s~GYN3-On>zdS3H503Tre5mW8tOURZzBh{BvM$Odx;)@I^#Vh
z3@IhrQL}77k^+RC$;*&_Vzo?N??`XiOWV<DYo^yUD89+qNv1uxkf$kd{y0mB_%UUe
z&}!L=6;3S_rxd@QYiAc}ZBd6E(+{8*7H=(Vw>+r4`FmE=KYu1TV+|!%<NoYh`IBGT
z$%NocDMuH?xSI9gffujs8teQV&~xY!q4X%Z++BRlYUf6cYl^-v_)Caw#V;Nob6nA~
zQ0_0<-cbUWV{$MNgopvoAm=k$E(k&D<!%(vAZNkS42#}xgtGaK(7`(-%7>RJAuMFo
z0ue*3)G>Z2Y@cDBi{NvJGZQUZ5ydgC>s|?W!G6kGZ(P=Uk6WtWhMb8m2Cq(r?FVc)
z+&C@?G3=+7$0j;BMc|gGY`YsIyC<8=^4dkea{;NKbefzSRh;ElcQOOunHK+u88!&%
z`EFizY)Dpe_c>kQYIp6h27lh!Jxfi-HxeU@We+oNL!&b|(Cp#DL&+OFj^Mj}K`kgj
zS=F12K-v3so$fC|n8T-Mwj~TorZSa;!B`mQ?k0T<Qc$N;(g~7AavqKgGJhvuCa)u`
zd5Z_ps`+io;vx%?TVtOAF~R)8wZKX1YmwMU<or3#gO~`(+{}rSd>el)nSP6n>{(eo
zju&e_0|&ZyHIHAKW!ahE8}{Yf=Q4RzQOMoRTi^*8_C{>!7^*M_1w|D9eqwkZlPV0i
z#Ci?ny$kmTxxT~yrDU&?sPa%x#k4%)_9GB`<jEWVdV80_ldKfQP!`_n7jTigKOql`
z&*zE{^u_lMWX@t@x(+6Hn$U(Gw!B9>Vg||)!X`h7Uv-jCdUTb0kyLCkjfq#zIu@81
z&Bu45+%a)=+TWi|hxeiy9{$_;mBv7WqW~GW-5K>~0p>3gaIHg{$kgz>I)BCJGM3UC
z4jgy(pf5jfJu)twOa9sVjludZHJpyKCP^p*ETaHDTQXpsqmUWeDr3O7D?Pvrk^U59
zHj@r_OK!H}^Xzntj8q)H@dOhYWnp?`mTn^H<9EGMvW4PuGwi{U%N24Qe1so`M+cZn
zeUCSp+4j*tFz^b`WXA{vm@_MMX$Nam@F{9f1KBS%E<iUfmNk@dDLYrTQK<}Ps1rmt
z9y8zLiq{h6gao{jquVFE*`wz)MFQNPhe&ddhusfZ0+@xXJ9B=)x}>*mRQl94OIuo@
zLh4}g_6|2QpCm<cyD~QCRCo?zvjt)t5uWE?CF+n78Y>EKYj<7JS9*DN-qEYoaOKqn
zRMfF&f-x;cOM(4n`;=|Wl&fH0NZ%ws9@e+k<&a{{>6ap<4cdB~nyjlUU)hTiUpKTL
zO|Ol!2({ZI=`S3eQZQY}#x?6eUx}$co6V_fJk6)I*21cmJHHY1T^RlP8NLks2)MF8
z%$IJK7V2B_^vE5`ba+<VxzSNlb^F{agQibee_ki<gebQCq&4>?9j+*H?sa`x;ZhLq
zskI9o%;Q1xTvJRNOnR=0{yg6(GC^mx-K8!4wzlWoxWOoYT<lKc^-F`tpWqFsP=?gz
z4GXOYzp#x;kpX1SKXi9Y=;(nA|2@v1qVNBzG5YWE&v5_ms{cgG|JMKjjnS0T*WiD%
W^NtDADQf`$`qNH0okMJYZ~p+y`RSJc

literal 0
HcmV?d00001

diff --git a/skills/commit-message/SKILL.md b/skills/commit-message/SKILL.md
new file mode 100644
index 0000000..8d3346a
--- /dev/null
+++ b/skills/commit-message/SKILL.md
@@ -0,0 +1,47 @@
+---
+name: commit-message
+description: Generates high-quality, professional git commit messages following Conventional Commits standards. Use when the user wants to commit changes, needs a suggestion for a commit message, or is ready to wrap up a task.
+---
+
+# Commit Message
+
+## Overview
+
+This skill helps you generate professional git commit messages that adhere to the Conventional Commits specification. It automates the analysis of staged changes and provides a structured message that captures the intent and impact of the work.
+
+## Workflow
+
+### 1. Identify Staged Changes
+Run `git status` to identify which files are staged for commit. If no files are staged, inform the user and ask if they would like to stage specific files.
+
+### 2. Analyze Diffs
+Run `git diff --cached` to analyze the actual changes in the staged files. For large diffs, focus on the most significant changes or summarize by file.
+
+### 3. Draft the Message
+Apply the [Conventional Commits](references/conventional-commits.md) standard to draft the message.
+
+- **Type**: Choose the most appropriate type (feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert).
+- **Scope**: (Optional) Add a scope if the change is localized to a specific module or component.
+- **Description**: Write a concise, imperative-mood summary of the change.
+- **Body**: (Optional) Provide a more detailed explanation if the changes are complex or require context.
+- **Breaking Changes**: Explicitly note any breaking changes in the footer or with a `!` in the prefix.
+
+### 4. Present and Refine
+Present the drafted message to the user. Ask if they would like to use it as-is, make adjustments, or if they want a different version.
+
+## Examples
+
+### Request: "Commit these changes"
+**Response**: "I see you have staged changes in `src/auth.ts` and `src/user.ts`. I've analyzed the diff and suggest the following commit message:
+`feat(auth): add JWT-based session management`
+Would you like me to commit with this message?"
+
+### Request: "Give me a commit message for my work"
+**Response**: "Based on your changes in `docs/api.md`, I suggest:
+`docs: update API endpoints for user registration`
+Does this look good to you?"
+
+## Guidelines
+- **Imperative Mood**: Use "add", "fix", "update" instead of "added", "fixed", "updates".
+- **Conciseness**: Keep the first line (header) under 50-72 characters if possible.
+- **Context**: Use the commit body for "why" rather than "what" (the diff shows "what").
diff --git a/skills/commit-message/evals/evals.json b/skills/commit-message/evals/evals.json
new file mode 100644
index 0000000..e72c440
--- /dev/null
+++ b/skills/commit-message/evals/evals.json
@@ -0,0 +1,20 @@
+{
+  "skill_name": "commit-message",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Commit the changes in src/auth.ts where I added JWT logic.",
+      "expected_output": "Suggests a feat(auth) or similar Conventional Commit message, uses imperative mood (e.g., 'add JWT authentication logic')."
+    },
+    {
+      "id": 2,
+      "prompt": "What's the commit message for fixing a typo in the README?",
+      "expected_output": "Suggests 'docs: fix typo in README' or similar."
+    },
+    {
+      "id": 3,
+      "prompt": "I refactored the database connection pool. What's a good commit message?",
+      "expected_output": "Suggests 'refactor: refactor database connection pool' or similar, mentions it's a refactor type."
+    }
+  ]
+}
diff --git a/skills/commit-message/references/conventional-commits.md b/skills/commit-message/references/conventional-commits.md
new file mode 100644
index 0000000..73727ad
--- /dev/null
+++ b/skills/commit-message/references/conventional-commits.md
@@ -0,0 +1,46 @@
+# Conventional Commits 1.0.0
+
+The Conventional Commits specification is a lightweight convention on top of commit messages. It provides an easy set of rules for creating an explicit commit history; which makes it easier to write automated tools on top of. This convention dovetails with [SemVer](http://semver.org), by describing the features, fixes, and breaking changes made in commit messages.
+
+The commit message should be structured as follows:
+
+```
+<type>[optional scope]: <description>
+
+[optional body]
+
+[optional footer(s)]
+```
+
+## Types
+
+- **feat**: A new feature
+- **fix**: A bug fix
+- **docs**: Documentation only changes
+- **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
+- **refactor**: A code change that neither fixes a bug nor adds a feature
+- **perf**: A code change that improves performance
+- **test**: Adding missing tests or correcting existing tests
+- **build**: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
+- **ci**: Changes to our CI configuration files and scripts (example scopes: GitHub Actions, Travis, Circle, BrowserStack, SauceLabs)
+- **chore**: Other changes that don't modify src or test files
+- **revert**: Reverts a previous commit
+
+## Rules
+
+1. Commits MUST be prefixed with a type (feat, fix, etc.), followed by an optional scope, and a REQUIRED terminal colon and space.
+2. The type feat MUST be used when a commit adds a new feature to your application or library.
+3. The type fix MUST be used when a commit represents a bug fix for your application.
+4. An optional scope MAY be provided after a type. A scope MUST consist of a noun describing a section of the codebase surrounded by parenthesis, e.g., `fix(parser):`
+5. A description MUST immediately follow the colon and space after the type/scope prefix. The description is a short summary of the code changes, e.g., `fix: array parsing issue when multiple spaces were contained in string`.
+6. A longer commit body MAY be provided after the short description, providing additional contextual information about the code changes. The body MUST begin one blank line after the description.
+7. A commit body is free-form and MAY consist of any number of new-line separated paragraphs.
+8. One or more footers MAY be provided one blank line after the body. Each footer MUST consist of a word token, followed by either a `:<space>` or `<space>#` separator, followed by a string value (this is inspired by the git trailer convention).
+9. A footer’s token MUST use `-` in place of whitespace characters, e.g., `Acked-by` (this helps differentiate the footer from a multi-paragraph body). An exception is made for `BREAKING CHANGE`, which MAY also be used as a token.
+10. A footer’s value MAY contain whitespace and newlines, and parsing MUST terminate when the next valid footer token/separator pair is observed.
+11. Breaking changes MUST be indicated in the type/scope prefix of a commit, or as an entry in the footer.
+12. If included as a footer, a breaking change MUST consist of the uppercase text BREAKING CHANGE, followed by a colon, space, and description, e.g., `BREAKING CHANGE: environment variables now take precedence over config files`.
+13. If included in the type/scope prefix, breaking changes MUST be indicated by a `!` immediately before the `:`. If `!` is used, `BREAKING CHANGE:` MAY be omitted from the footer section, and the commit description SHALL be used to describe the breaking change.
+14. Types other than feat and fix MAY be used in your commit messages, e.g., `docs: updated ref docs`.
+15. The units of information that make up Conventional Commits MUST NOT be treated as case sensitive by implementers, with the exception of BREAKING CHANGE which MUST be uppercase.
+16. BREAKING-CHANGE MUST be synonymous with BREAKING CHANGE, when used as a token in a footer.