docs(kiro): add commit message and changelog format guidelines

[leongdl]

Fixes: No specific GitHub issue - proactive documentation improvement

What was the problem/requirement? (What/Why)

The repository lacked consistent standards for commit messages and changelog formatting, leading to:

• Inconsistent commit message formats across contributors
• Changelog entries that were difficult to parse and understand
• Missing migration guidance for breaking changes
• No clear guidelines for experimental feature documentation

What was the solution? (How)

Added two comprehensive steering documents:

1. .kiro/steering/commit_msg.md - Standardizes commit message format using conventional commits with:

   • Consistent type/scope/description structure
   • Clear examples of good vs bad commit messages
   • Breaking change notation guidelines
   • Repository-specific scope recommendations

2. .kiro/steering/changelog_format.md - Establishes changelog formatting rules with:

   • Structured sections (Breaking Changes, Features, Bug Fixes, Experimental)
   • Detailed sentence structure guidelines for descriptions
   • Commit-to-changelog mapping rules
   • Quality checks and automation guidelines

What is the impact of this change?

• Improved consistency: Future commits and changelog entries will follow standardized formats
• Better user experience: Changelog descriptions will be user-focused rather than technical commit messages
• Clearer breaking changes: Migration guidance will be consistently provided
• Automation-ready: Guidelines support both manual and automated changelog generation
• Contributor guidance: New contributors have clear standards to follow

How was this change tested?

This is documentation-only change. Testing involved:

• Analyzing existing git history to identify patterns and inconsistencies
• Reviewing current CHANGELOG.md format to understand improvement areas
• Validating examples against real repository commit messages
• Ensuring guidelines align with conventional commit standards

See DEVELOPMENT.md for information on running tests.

• Have you run the unit tests? N/A - Documentation only
• Have you run the integration tests? N/A - Documentation only
• Have you made changes to the download or asset_sync modules? No

Was this change documented?

• Are relevant docstrings in the code base updated? N/A - No code changes
• Has the README.md been updated? No - These are internal steering documents

Does this PR introduce new dependencies?

• This PR adds one or more new dependency Python packages. I acknowledge I have reviewed the considerations for adding dependencies in DEVELOPMENT.md.
• This PR does not add any new dependencies.

Is this a breaking change?

No - This is documentation only and does not modify any public contracts.

Does this change impact security?

No - This change only adds documentation files with formatting guidelines. No security implications.

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[leongdl]

This was generated by Kiro from datamining our own commit messages, change logs and how they correlate.

[leongdl]

I want to reduce the amount of time we spend thinking or debating the change log on release :)

[godobyte]

Finally! Love to see those automated improvements.

[godobyte]

Emm dependabot always use the former one, the latter one is better?

[leongdl]

Good point, I'll change this so Kiro keeps dependable names.

[epmog]

Should the steering docs not point at our existing documentation that we already provide on this topic? I dislike the idea of having to maintaining the same information in multiple places.

I think that pretty accurately describes what we're looking for. With maybe one caveat that we're missing info on the "how to phrase" which we could add info for. Does Kiro struggle with using that?

[leongdl]

Should the steering docs not point at our existing documentation that we already provide on this topic? I dislike the idea of having to maintaining the same information in multiple places.

I think that pretty accurately describes what we're looking for. With maybe one caveat that we're missing info on the "how to phrase" which we could add info for. Does Kiro struggle with using that?

I agree it should link to the CONTRIBUTION.md, but the contribution md is more human facing and not very "AI friendly".

The AI steering here gives it learned context of prior art to help us shape better commit messages. Its not necessarily a "human user guide".

[epmog]

Closing this now that there's now an Agent.md added in #955 and it points at the existing documentation for changelogs and commits which I think is the right spot for all of this. If we need to improve instructions, we can update the existing docs for humans/agents.