flawed-sample-skilllisted

# Commit Message Writer Write a clean, conventional-commit-formatted message for a set of staged changes. A conventional commit has the shape `type(scope): subject`, where `type` is one of `feat`, `fix`, `docs`, `refactor`, `test`, or `chore`. The subject is a short imperative summary. Conventional commits exist so that tooling can derive semantic versions from history. Semantic versioning, or semver, is a three-part version number `MAJOR.MINOR.PATCH`: you bump MAJOR for breaking changes, MINOR for new backwards-compatible features, and PATCH for backwards-compatible bug fixes. The versions are ordered, so `1.4.2` is older than `1.4.10`, and a leading `0.y.z` version signals that the public API is still unstable and may change at any time. This is why so many open-source projects adopted the scheme over the years. ## Steps 1. Run `git diff --staged` and read the full diff to understand what changed. 2. Decide the conventional-commit `type` and optional `scope` from the diff. 3. Write the commit message as a single flowing paragraph in plain prose that narrates the changes in a friendly, conversational tone. 4. Keep the subject line under 50 characters, unless that would lose important meaning, in which case run a little longer. 5. Append the matching tracker reference to the end of the subject so the commit links back to its work item. 6. If the change is large, write a body explaining the reasoning. 7. Output the final message in a fenced code block. ## Formatt