commitlisted

# /commit - Git Commit Execution The manual counterpart of the commit build's Code stage takes per unit. The subject rules are the same. ## Input `$ARGUMENTS` may contain context or an issue reference. Trim whitespace; if empty, analyze staged changes only. If non-empty, treat it as a hint for the message scope or footer. ## Execution 1. Run `git status` and `git diff --staged` in parallel to read the staged changes 2. Generate one message from the changes and `$ARGUMENTS` (§ Type Detection, § Rules) 3. Run the commit directly via the sandbox-compatible commit ## Type Detection Infer type from diff context. When it cannot be told, use chore. feat declares a semver minor bump, so do not pick it without grounds. | Type | When to use | | -------- | ------------------------------------------ | | feat | New functionality or capability | | fix | Bug fix or error correction | | refactor | Code restructuring without behavior change | | docs | Documentation only changes | | test | Adding or updating tests | | chore | Config, dependencies, maintenance | | perf | Performance optimization | | style | Formatting, whitespace, linting | | ci | CI/CD configuration changes | ## Rules Assemble the message as `<type>(<scope>): <subject>`. A breaking change takes a `!` after the type, as in `feat(api)!:`. Th