post.md

Stage all unstaged and untracked files, analyze them semantically, and create well-structured conventional commits. Do NOT ask for user input - operate fully autonomously.

Step 1: Gather Repository State

Run these commands to understand the current state:

git status
git diff --stat
git diff --name-only
git diff --name-only --cached
git ls-files --others --exclude-standard

If there are no changes (nothing to commit), output "No changes to commit" and stop.

Step 2: Analyze Changes

For each modified/added file, read the diff to understand what changed:

git diff <filename>
git diff --cached <filename>

For new untracked files, read the file content to understand its purpose.

Step 3: Semantic Grouping

Group related changes into logical commit units by analyzing:

File Relationships:

• Files in the same feature directory
• Files with shared imports/dependencies
• Test files with their corresponding source files

Change Nature:

• All documentation changes together
• All test additions together (unless paired with features)
• Configuration/build changes together

Logical Units:

• A new feature + its tests = one commit
• A bug fix + its test = one commit
• Pure refactoring = separate commit
• Unrelated changes = separate commits

Step 4: Determine Commit Types

Auto-detect the conventional commit type for each group:

Type	When to Use
feat	New feature, new functionality, new capability
fix	Bug fix, error correction, resolving an issue
docs	Documentation only (README, comments, JSDoc, docstrings)
style	Formatting, whitespace, semicolons (no logic change)
refactor	Code restructure without behavior change
perf	Performance improvements
test	Adding or correcting tests
build	Build system, dependencies, package.json, .csproj
ci	CI/CD configuration (GitHub Actions, Azure Pipelines)
chore	Maintenance, config files, .gitignore
revert	Reverting a previous commit

Step 5: Write Commit Messages

Format (NO SCOPE):

type: subject line in imperative present tense

Description explaining WHY this change was made (not what).
Provide context for reviewers in 1-3 sentences.

Co-Authored-By: Claude <noreply@anthropic.com>

Rules:

• Use imperative mood: "add" not "added" or "adds"
• No capitalization of first letter after type
• No period at end of subject line
• Subject under 72 characters
• Blank line between subject and body
• Body explains the WHY, not the WHAT

DO - Good Examples:

feat: add user authentication with JWT tokens

Implement JWT-based authentication flow including login endpoint,
token validation middleware, and automatic token refresh.
This enables secure API access for registered users.

Co-Authored-By: Claude <noreply@anthropic.com>

fix: prevent null reference in order processing

The order processor crashed when customer address was missing.
Added null check and graceful fallback to default shipping address.

Co-Authored-By: Claude <noreply@anthropic.com>

refactor: extract payment logic into dedicated service

Moved payment processing from OrderController to PaymentService
to improve testability and follow single responsibility principle.

Co-Authored-By: Claude <noreply@anthropic.com>

docs: add API authentication examples to README

Include curl examples for login, token refresh, and authenticated
requests to help developers integrate with the API.

Co-Authored-By: Claude <noreply@anthropic.com>

test: add unit tests for discount calculation

Cover edge cases including zero quantity, negative prices,
and maximum discount limits.

Co-Authored-By: Claude <noreply@anthropic.com>

DO NOT - Bad Examples:

update code                    # Too vague, no type
Fixed stuff                    # Past tense, vague, no type
feat: Updated the user auth.   # Past tense, ends with period
WIP                            # Meaningless
fix: fix                       # Redundant, no information
feat: add feature              # Circular, no actual description
changes                        # No type, completely uninformative
FEAT: ADD LOGIN                # Don't use caps
feat: Add auth, fix bug, update docs  # Multiple unrelated changes

Step 6: Execute Commits

For each logical group, execute in sequence:

# Stage specific files for this commit
git add <file1> <file2> ...

# Create commit with HEREDOC for proper formatting
git commit -m "$(cat <<'EOF'
type: subject line here

Description body explaining why this change was made
and providing context for reviewers.

Co-Authored-By: Claude <noreply@anthropic.com>
EOF
)"

After all commits, run git status to verify success and show the commit log:

git log --oneline -10

Edge Cases

1. No changes: Output "No changes to commit" and stop
2. Only untracked files: Stage and commit with appropriate type
3. Binary files: Include in commits, note in description
4. Sensitive files: SKIP these files and warn the user:
   • .env, .env.*
   • *credentials*, *secrets*
   • *.pem, *.key, *.p12
   • appsettings.*.json with connection strings
5. Merge conflicts: Abort and tell user to resolve manually

Important

• Do NOT ask for user confirmation
• Do NOT use git push
• Do NOT modify git config
• Create as many commits as needed for proper semantic separation
• Each commit should be atomic and focused on one logical change