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 - 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

[!](): 

[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

| Type | Description | | -------- | -------------------------------------- | | feat | New feature or extension | | fix | Bug fix | | chore | Maintenance (deps, config, file moves) | | perf | Performance improvements | | refactor | Code restructure (no behavior change) | | docs | Documentation changes | | test | Adding or refactoring tests | | style | Code formatting (no logic change) | | build | Changes to the build system or scripts | | ci | Changes to CI/CD workflows |

Common Scopes

| Scope | When to use | | ---------- | ---------------------------------------------------- | | extensions | Changes under extensions/ (manifests, installs) | | kits | Changes under kits/ (server, fake agent, toolkits) | | build | Build scripts under .github/scripts/ | | ci | CI workflows under .github/workflows/ | | docs | Documentation under docs/ |

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

1. 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.)

1. Commit:

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

```bash git commit -m "$(cat <<'EOF' feat(extensions): descriptive title

• Bullet point summary
• Another change detail

EOF )" ```

• Verify with git status after commit

1. 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

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: iOfficeAI
• Source: iOfficeAI/AionHub
• License: Apache-2.0

Install and usage instructions live in the source repository linked above.