commitlisted

# Commit Authoring ## Workflow ### Step 1: Read Run `git diff --staged` first. - If there IS staged content, use that diff and proceed. - If there is NO staged content, run `git diff` to see unstaged changes. - If unstaged changes exist in a single logical area (one file, or a few closely related files), stage them all with `git add` and proceed. - If unstaged changes span multiple unrelated areas, list the changed files grouped by likely concern and ask the user which files to include. Stage only the confirmed files, then proceed. - If there are no changes at all (staged or unstaged), tell the user there's nothing to commit and stop. ### Step 2: Analyze Read through the full diff output. Determine: 1. **What changed and why** — understand the intent behind the change (new feature, bug fix, refactor, etc.) 2. **Scope** — how many files are affected, which area of the codebase 3. **Red flags** — scan for every one of these: - Secrets or credentials (API keys, tokens, passwords, private keys, connection strings) - `.env` files or other config files that typically contain secrets - Debug code left behind (`console.log`, `console.debug`, `console.warn` used for debugging, `debugger` statements, `print()` statements that look like debug output, `binding.pry`, `byebug`, `pdb.set_trace`) - Large binary files (images, videos, compiled artifacts, archives) - Generated or vendored files (lock files are fine; `dist/`, `build/`, `node_modules/`, `