重要なのは、AI にraw material、つまり実際の diff や code を渡し、specific で conventional な format を求めることです。AI は change を clear prose に変えるのが得意ですが、何が変わったかを見られる場合に限ります。
重要なのは、AI にraw material、つまり実際の diff や code を渡し、specific で conventional な format を求めることです。AI は change を clear prose に変えるのが得意ですが、何が変わったかを見られる場合に限ります。
git diff --staged | <your AI tool>。feat:、fix:、docs:)や project の changelog style。怠い commit message:
fixed stuff
diff を渡して Conventional Commit style を求めた後:
fix(auth): reject expired tokens in session middleware
The middleware only checked token signature, not expiry, so expired
sessions stayed valid. Added an `exp` claim check that returns 401.
2 つ目は reviewer に what と why を伝えます。6 か月後の git log でもはるかに有用です。
常に actual change と照合して読むこと。AI はあなたの intent を知りません。見せられた code だけを知っています。そのため fix を feat と誤分類したり、実際にはない side effect を主張したりします。
良い commit message と docs は、future self と teammate が code の why を理解する方法です。AI はそれを書く friction を下げますが、accuracy はあなたの責任です。自信満々に間違った changelog は、ないより悪いことがあります。real input を渡し、real convention を求め、commit 前に verify します。