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 | 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 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: ```bash 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