Stage Related Files Skill
Group changes logically for git add and decide when to split into one or more commits.
When to Use
- •Use when staging files for commit (e.g. as part of shipit or any commit workflow)
- •Use when grouping related changes into logical commits
- •Use when deciding whether to make one commit or several
Instructions
Grouping Criteria
Group by logical change: one feature/fix/docs refactor per commit when possible.
- •Same type of change: Same scope (e.g. one area of codebase), no unrelated edits in one commit
- •When to split: Separate commits for distinct features, fixes, or doc-only vs code
Steps
- •Run
git statusto see modified, added, and deleted files - •Propose groupings (paths or patterns) based on the criteria above
- •For each group, run
git add <paths>. Avoid staging everything in one blob unless it truly is one logical change - •Run
git statusagain to verify what is staged
Single vs Multiple Commits
- •Single: All changes are one logical unit — use one
git addfor the full set - •Multiple: If the working tree has clearly separate logical changes, do multiple
git add+ commit cycles (group 1 → add → commit, then group 2 → add → commit)