/commit

Create a git commit for the current staged (or unstaged) changes using a structured commit message convention.

Instructions

1. **Inspect the working tree:**

• Run `git status` (never use `-uall`) to see untracked and modified files.
• Run `git diff --staged` to see what is already staged.

2. **Run tests:**

• Run `npm test` and verify all tests pass.
• If any test fails, stop and report the failure — do NOT proceed with the commit.

3. **Stage files if nothing is staged:**

• If there are no staged changes but there are modified/untracked files, stage the relevant ones.
• Only stage files that are relevant to the current task or session. Do NOT stage unrelated changes that happen to exist in the working tree.
• NEVER stage files that likely contain secrets (`.env`, `credentials.json`, `.key` files, etc.).
• Prefer staging specific files by name over `git add -A`.

4. **Analyze the changes and choose a prefix:** Pick the most appropriate prefix based on the nature of the changes:

| Prefix | When to use | Release Notes Section | |--------------|--------------------------------------------------|-----------------------| | `add` | New feature, file, or capability | Features | | `feat` | New feature (alternative to `add`) | Features | | `implement` | Completing a planned feature | Features | | `introduce` | Introducing a new concept or component | Features | | `support` | Adding support for something new | Features | | `fix` | Bug fix or correction | Fixes | | `resolve` | Resolving an issue | Fixes | | `patch` | Small targeted fix | Fixes | | `correct` | Correcting wrong behavior | Fixes | | `improve` | Enhancement to existing functionality | Changes | | `update` | Updating existing behavior or dependencies | Changes | | `remove` | Removing code, features, or files | Changes | | `refactor` | Code restructuring without behavior change | Changes | | `bump` | Version bump | Changes |

5. **Format the commit message:**

• Format: `<prefix> <concise lowercase description>`
• Examples: `add dark mode support`, `fix session resume on restart`, `refactor PTY lifecycle management`
• Keep it concise — one line, no period at the end
• Focus on the "what" and "why", not the "how"

6. **If `$ARGUMENTS` is provided**, use it as guidance or context for the commit message. It may be a description of what was done, a hint about the prefix to use, or a full message to refine.

7. **Create the commit** using a HEREDOC for the message:

   git commit -m "$(cat <<'EOF'
   <prefix> <description>
   EOF
   )"

8. **Verify** by running `git status` after the commit to confirm success.

9. Do NOT push to the remote unless explicitly asked.

$ARGUMENTS