Smart Commit

Step 1: Analyze All Changes

!git status !git diff !git diff --cached

Step 2: Plan Logical Commits

Group changes by these dimensions:

• •Feature work vs refactoring vs bug fixes
• •Area/scope (which part of the wiki? config, content, infra, skin, extensions?)
• •Content vs infrastructure
• •Deps/config vs behavior changes
• •Docs vs code

If everything belongs together -> single commit. If changes span multiple concerns -> plan multiple commits.

Step 3: Present the Plan (CONCISE)

Show a brief table - one row per commit group:

Do NOT:

• •List every file individually
• •Explain what each file does
• •Provide detailed breakdowns
• •Add commentary about the changes

Just: commit message + file count. User can ask for details if needed.

Wait for confirmation before proceeding.

Step 4: Execute

For each planned commit:

1. •Stage only the relevant files: git add <files>
2. •For mixed files, use patch staging: git add -p <file>
3. •Commit with the planned message
4. •Verify with git status

After all commits, show git log --oneline -n <count> to confirm.

Rules

• •Never commit unrelated changes together
• •If a commit can't be described in one line, it's too broad--split it
• •Each commit should be independently meaningful
• •Think: "Will this make sense when generating the changelog?"