---
name: ami-plan-commits
description: Analyzes the working tree for uncommitted work, proposes a structured set of commits, waits for user approval, and executes them.
allowed-tools: Bash, Read
---

# Skill: Commit Planner

When this skill is invoked (either by the user or by an agent), you must act as a Git Commit Strategist. Your goal is to group related changes into meaningful commits and propose a clear and concise commit plan to the user for approval. Clear commits makes it easier to find regressions and revert unwanted changes.

## Workflow
1. **Analyze Working Tree & Local History:** Use git commands (`git status`, `git diff`, `git diff --cached`, and `git log @{u}..HEAD` or `git log -n 5 --oneline`) to identify all uncommitted modified/new/deleted files and review recently created unpushed commits.
2. **Security & Data Leak Audit:** Actively scan all diffs and uncommitted files to ensure no sensitive data (API keys, secrets, passwords, tokens, PII) is being committed. If any leak is detected, **ABORT** the process immediately, alert the user, and refuse to stage or commit the sensitive files.
3. **Structure & Group Changes:** Carefully analyze the modifications and group them into logical, distinct commits. Avoid lumping unrelated changes into a single monolithic commit. Consider the following grouping strategies:
   - **Amend Strategy:** If the current uncommitted work consists of minor fixes, typos, or additions to the most recent **unpushed** commit, propose amending it (`git commit --amend`) instead of adding a redundant commit.
   - **Squash / Consolidation Strategy:** If there are multiple unpushed local commits that represent iterative WIP or fragmented fixes for a single feature/component, propose squashing them into a single clean commit.
   - **By Conventional Commit Type:** Separate new features (`feat:`), bug fixes (`fix:`), refactors (`refactor:`), documentation updates (`docs:`), and maintenance chores (`chore:`).
   - **By Component or Architectural Layer:** Group changes related to a specific domain (e.g., frontend UI versus backend logic, or a specific module).
   - **By Feature or Logical Unit:** Group files that work together to solve a single problem or complete a specific sub-task.
   *Note: If all changes are tightly coupled and represent a single cohesive unit of work, grouping them into a single commit (or amending) is perfectly acceptable. Avoid over-fragmenting commits unnecessarily.*
4. **Draft Messages & Plan:** For each proposed commit group (or amend/squash operation), formulate a clear and descriptive commit message in English. You **must** use the appropriate Conventional Commit prefix (`feat:`, `fix:`, `docs:`, `chore:`, `refactor:`, `test:`, `style:`). List the specific files associated with each commit. Your messages should be concise but highly descriptive, explaining *why* the change was made, not just *what* changed.
5. **Request Approval:** Present the complete commit plan (including security audit confirmation and any proposed amend/squash operations) to the user in the chat. Ask for their approval and iterate if necessary. **NEVER** stage, commit, amend, or rebase anything until the user gives their explicit approval.
6. **Execute:** Once approved, use `git add`, `git commit`, `git commit --amend`, or rebase/squash commands to execute the plan exactly as agreed.
7. **Reporting:** After executing the plan, show the user the commits you just created using the `git log -n 5 --oneline` command to confirm the changes and that the skill worked as expected.

---
**Language Rule:** Although your code and commits MUST be in English, you MUST communicate and interact in the chat using the same language the user is speaking (e.g., Spanish, French, etc.).