commit-unstagedlisted

Read the unstaged changes (i.e. the output of `git diff`, plus the contents of any untracked files), think about code change(s) they represent, and then help me check the changes in to Git in a series of commits. This interaction occurs in two parts: 1. First, based on your review of the changes, propose a series of commits. - Each commit should be self-contained and include a high quality commit message. A good commit message is one that conveys enough information for someone casually familiar with our codebase to understand it. Without being overly verbose, include any necessary context, a description of the problem or gap the commit addresses, and the solution the commit adds to the codebase. - When writing commit messages, adhere to the commit message guidelines in this repository's CLAUDE.md. - Collectively, the commits should be in a coherent order. We want to make it easy for code reviewers understand the broader change represented by a series of commits. Early commits might add independent components or tools that are then built upon by later commits, culminating in a "main" commit which uses those components/tools to solve the problem addressed by a pull request. - Model the presentation of the plan on the output of `git rebase -i`. Show the ordered list of commit messages. - Always end step 1 with the AskUserQuestion tool to get my explicit confirmation before committing anything — never proceed to step 2 based on plain-text approval alone, even for a si