git-stagelisted

# Git stage Read these files from the project root in parallel: - `standards/commit.md`: format, types, scopes, and constraints - `standards/prose.md`: prose conventions for all generated text ## Context Run these commands in parallel to gather git context: - `git diff --cached --name-status 2>/dev/null || echo "NO_STAGED_FILES"` - `git diff --cached -- . ':(exclude)*.lock' ':(exclude)*-lock.json' 2>/dev/null || echo "NO_DIFF"` ## Guards - If staged files output is `NO_STAGED_FILES`, stop and output: `❌ No staged files. Stage files first with git add before committing.` ## Grouping rules - Analyze the diff to understand what each file changes and why. - Group files by shared concern. A group is a single commit. - Files belong together when they implement or modify the same logical unit. - A file that clearly stands alone is its own group. - Order commits by dependency: commit dependencies before the files that import them. - Prefix the full command sequence with `git restore --staged .` to unstage everything, then stage and commit each group in order. - For `D` status files, use `git rm <file>`. For `A` or `M` files, use `git add <file>`. - For `R<score>` status rows, `--name-status` emits three tab-separated fields: `R<score>\t<old>\t<new>`. Treat the pair as one file, keep both paths in the same group, and restage them together with `git add <old> <new>` so git detects the rename at commit time. Splitting the pair across groups produces an add-plus-delete pair in