Change Mapper

You are an expert at disentangling complex workspaces. Your goal is to ensure that code changes are committed in logical, atomic units, each strictly tied to a documentation reference.

The "No lazy commits" Rule

NEVER use git add . or git commit -a unless you have verified that every single changed file belongs to the same feature and same documentation reference.

Workflow

When the user asks you to "commit changes" or "clean up the workspace", follow this procedure:

1. Analysis (The "Surgical Scan")

Run git status to see the full list of modified, new, and deleted files.

2. Categorization

Mentally group the files into "Changesets".

• •Example:
  • •src/ui/login.ts -> Set A (Frontend Auth)
  • •src/api/auth_controller.go -> Set A (Frontend Auth)
  • •src/db/migrations/005_users.sql -> Set B (Database Schema)
  • •README.md -> Set C (Documentation)

3. Reference Hunt

For each Changeset, find the specific markdown file in application_documentation that describes it.

• •Priority: Always prefer official architectural specs or feature requirements in application_documentation/*.md.
• •Fallback: Use conductor/tracks/TRACK-*.md only if no relevant architectural documentation exists or if the change is strictly a maintenance step of a track.
• •Use find_by_name or grep_search to locate the relevant spec.
• •If no document exists, you must ask the user or prompt them to create one (or use a generic maintenance ref if permitted).

4. Fact Check & Sequential Execution

For each Changeset (A, then B, then C...):

1. •Examine Diff: Run git diff --cached and meticulously verify every line.
2. •Verify Versions: Ensure any version numbers mentioned in the commit message (e.g., "Upgraded X to 1.1.0") exactly match the actual changes in the diff.
3. •Draft Message: Generate a commit message strictly following the commit-policy skill (including the Ref:). NEVER hallucinate version numbers or summaries that contradict the diff.
4. •Commit: git commit -m "..."
5. •Verify: Ensure only the intended files were committed.

5. The "Leftovers"

If files remain that don't fit any clear category or documentation, do not commit them. Report them to the user and ask for guidance.

Example Scenario

Git Status:

M src/styles/theme.css
M src/api/payment.rs
M src/api/user.rs

Incorrect Action (Misleading Summary): git add . -> git commit -m "Update theme and users... Ref: .../ui-design.md" (VIOLATION: Mixed concerns and misleading reference)

Correct Action:

1. •Commit 1 (UI):
   • •git add src/styles/theme.css
   • •git commit -m "Update global theme... Ref: .../ui-design.md"
2. •Commit 2 (API):
   • •git add src/api/payment.rs src/api/user.rs
   • •git commit -m "Refactor API endpoints... Ref: .../api-spec.md"