dotfiles/opencode/command/commit.md

description
Create well-formatted commits with conventional commit messages

Commit Command

You are an AI agent that helps create well-formatted git commits with conventional commit messages, follow these instructions exactly. Always run and NEVER push the commit, you don't need to ask for confirmation unless there is a big issue or error.

Instructions for Agent

When the user runs this command, execute the following workflow:

1. Analyze git status:

   • Run git status --porcelain to check for changes
   • If no files are staged, run git add . to stage all modified files
   • If files are already staged, proceed with only those files

2. Analyze the changes:

   • Run git diff --cached to see what will be committed
   • Analyze the diff to determine the primary change type (feat, fix, docs, etc.)
   • Identify the main scope and purpose of the changes

3. Generate commit message:

   • Create message following format: <type>: <description>
   • Keep description concise, clear, and in imperative mood
   • Show the proposed message to user for confirmation

4. Execute the commit:

   • Run git commit -m "<generated message>"
   • Display the commit hash and confirm success
   • Provide brief summary of what was committed

Commit Message Guidelines

When generating commit messages, follow these rules:

• Atomic commits: Each commit should contain related changes that serve a single purpose
• Imperative mood: Write as commands (e.g., "add feature" not "added feature")
• Concise first line: Keep under 72 characters
• Conventional format: Use <type>: <description> where type is one of:
  • feat: A new feature
  • fix: A bug fix
  • docs: Documentation changes
  • style: Code style changes (formatting, etc.)
  • refactor: Code changes that neither fix bugs nor add features
  • perf: Performance improvements
  • test: Adding or fixing tests
  • chore: Changes to the build process, tools, etc.
• Present tense, imperative mood: Write commit messages as commands (e.g., "add feature" not "added feature")
• Concise first line: Keep the first line under 72 characters

Reference: Good Commit Examples

Use these as examples when generating commit messages:

• feat: add user authentication system
• fix: resolve memory leak in rendering process
• docs: update API documentation with new endpoints
• refactor: simplify error handling logic in parser
• fix: resolve linter warnings in component files
• chore: improve developer tooling setup process
• feat: implement business logic for transaction validation
• fix: address minor styling inconsistency in header
• fix: patch critical security vulnerability in auth flow
• style: reorganize component structure for better readability
• fix: remove deprecated legacy code
• feat: add input validation for user registration form
• fix: resolve failing CI pipeline tests
• feat: implement analytics tracking for user engagement
• fix: strengthen authentication password requirements
• feat: improve form accessibility for screen readers

Example commit sequence:

• feat: add user authentication system
• fix: resolve memory leak in rendering process
• docs: update API documentation with new endpoints
• refactor: simplify error handling logic in parser
• fix: resolve linter warnings in component files
• test: add unit tests for authentication flow

Agent Behavior Notes

• Error handling: If validation fails, give user option to proceed or fix issues first
• Auto-staging: If no files are staged, automatically stage all changes with git add .
• File priority: If files are already staged, only commit those specific files
• Never push the commit: You must never under any circumstances execute git push.
• Message quality: Ensure commit messages are clear, concise, and follow conventional format
• Success feedback: After successful commit, show commit hash and brief summary