Commit

Commit Skill

Generate well-formatted commit messages and commit staged changes for AionHub.

Usage

• /commit - Generates a commit message based on staged changes
• /commit <advice> - Uses provided advice to guide commit message generation

Guidelines

• Only commit staged files - Never add files with git add. The user controls staging.
• Analyze all staged changes - Review both previously staged and newly added changes
• Follow commit message format - Use the project format shown below
• Match the project style - Check recent commits (git log) to match existing style

Format

<Type>[!](<scope>): <message title>

<bullet points summarizing changes>

[optional BREAKING CHANGE section if applicable]

Key convention: Type is always lowercase (e.g., feat, fix, chore, not Feat, Fix, Chore).

Examples

Basic commits

feat(extensions): add new ACP agent extension

- Added aion-extension.json manifest and install script
- Registered extension in build pipeline

fix(kits): resolve server startup crash on missing config

- Added fallback for undefined port in dev server
- Improved error message when config file is absent

refactor(build): use content-based SHA-256 for deterministic integrity

- Replaced timestamp-based hashing with file content hashing
- Ensures reproducible builds across environments

chore(extensions): promote claude, codex, goose from pending to extensions

- Moved directories from pending/ to extensions/
- Updated build script to include new entries

No scope (cross-cutting changes)

chore: add .gitignore and remove dist from tracking

- Created .gitignore with standard Node/dist patterns
- Removed previously tracked dist artifacts

Breaking change

refactor!(extensions): redesign manifest schema from v1 to v2

- Replaced flat fields with nested contributes block
- Updated all existing manifests to new format

BREAKING CHANGE: aion-extension.json schema v1 is no longer supported.

Rules

• Type: Always lowercase (feat, fix, chore, etc.), no period at end
• Title: Lowercase after colon, max 50 characters total
• Breaking changes: Use "!" after type/scope AND include "BREAKING CHANGE:" section
• Scope: Optional, lowercase, aligned with project directory/module name
• Body: Use bullet points, explain WHY not just WHAT
• Be specific: Avoid vague titles like "update" or "fix stuff"

Allowed Types

Common Scopes

Omit scope for cross-cutting changes that span multiple areas.

Workflow

1. Review changes in parallel:

   • Run git status (never use -uall flag)
   • Run git diff --cached (staged changes)
   • Run git diff (unstaged changes)
   • Run git log -5 --oneline to confirm current commit style

2. Draft commit message:

   • Summarize the nature of changes (new feature, bug fix, etc.)
   • Ensure message accurately reflects changes and purpose
   • Use lowercase type matching the project convention
   • Pick the most fitting scope from the table above
   • Focus on WHY rather than WHAT
   • Never commit files that likely contain secrets (.env, credentials.json, etc.)

3. Commit:

   • Create commit with proper message format
   • Always use HEREDOC for commit messages:

   git commit -m "$(cat <<'EOF'
   feat(extensions): descriptive title
   
   - Bullet point summary
   - Another change detail
   
   EOF
   )"
   

   • Verify with git status after commit

4. If pre-commit hook fails:

   • Fix the issue
   • Create a NEW commit (do not use --amend)
   • Never skip hooks unless explicitly requested

Important Notes

• Never push unless user explicitly requests it
• Never stage files without asking - Must ask the user for confirmation before running any git add command
• Never use interactive flags (-i) as they require user input
• No empty commits - If nothing is staged, inform the user instead
• Always use HEREDOC for commit messages to ensure proper formatting
• Never add Co-Authored-By - Do not append any Co-Authored-By trailer for any agent
• One commit per concern - If staged changes span multiple unrelated concerns, split into separate commits. Each commit should have a single, clear purpose