---
name: commit
description: Use when ready to commit and push — runs quality gates (lint, typecheck), stages changes across repos, and pushes to the active feature branch
---

# /commit - Commit & Push Changes (Humand Tech Plugin)

Stage, commit, and push changes across all repos in the current feature with a consistent commit message.

## Plugin-first adaptation

```bash
eval "$(bash "${CLAUDE_SKILL_DIR}/../../scripts/workflow-setup.sh" <workspace_root>)"
```

- Use `$REPOS_FILE`, `$LOCAL_CONFIG_FILE` from `workflow-setup.sh`.
- Runtime checks: `bash "$PLUGIN_ROOT/scripts/check-runtime.sh"`.
- Feature resolution: see `docs/feature-resolution.md`.

After running `workflow-setup.sh`, if `LOCAL_CONFIG_FILE` is empty, use **AskUserQuestion** before proceeding:

```
⚠️ No local-config.json found — I can't resolve repo paths without it.

[1] Run /initial-setup now (takes ~2 min, only needed once)
[2] Skip and continue anyway (some steps may fail)
```

If the user chooses **[1]**: invoke `/initial-setup` and stop this skill.  
If the user chooses **[2]**: continue, substituting `$LOCAL_CONFIG_FILE` references with best-effort guesses or skipping repo-dependent steps gracefully.

## Superpowers-first hooks

- Before success claim: `verification-before-completion`.
- If gate fails: follow `systematic-debugging` for root-cause-first fixes.

## Feature Resolution

See `docs/feature-resolution.md` for the full algorithm. Summary: use session context if clear; otherwise resolve from `git branch --show-current` in CWD + `git worktree list --porcelain` per repo in `$LOCAL_CONFIG_FILE`.

This skill accepts an optional branch argument (example: `/commit feat/SQSH-1234-foo`) to override CWD detection.

Read `$REPOS_FILE` for repo-specific settings (lint commands, base branch, etc.).

## Workflow

### 1. Load Context

Run the Feature Resolution algorithm above. The result gives you the active repos and their paths, and the branch name.

If no repo is found on a non-base branch: stop and tell the user to run `/start` first or check out the feature branch manually.

Ticket info (for the commit message) comes from the branch name — extract the ticket key if present (e.g. `feat/SQSH-1672-desc` → `SQSH-1672`). If the branch has no ticket key pattern (e.g. `NO-CARD-fix-header`), commit without a ticket reference.

### 2. Show Changes Per Repo

For each repo in context (or with changes):

```bash
cd <repo_path>
git status --short
git diff --stat
```

If a repo has `has_translations: true` in `$REPOS_FILE` AND hu-translations repo path resolves to a non-base branch (per feature resolution), also check:

```bash
cd <hu_translations_path>
git status --porcelain
```

Display in a unified view:

```
Changes detected:

humand-web (3 files):
  M  src/components/Profile.tsx
  M  src/pages/profile/index.tsx
  A  src/hooks/useProfile.ts

material-hu (1 file):
  M  src/components/Avatar/Avatar.tsx

hu-translations (2 files):
  M  locale/es/feed.json
  M  locale/en/feed.json

humand-main-api (0 files):
  No changes
```

### 3. Get Commit Info (Single Prompt)

If changes exist, ask all questions in ONE message:

```
Changes detected: {summary above}

Please answer:

1. What to commit:
   [1] All changes across all repos (default)
   [2] Select specific repos
   [3] Select specific files

2. Commit message:
   [1] {auto-generated suggestion based on diff analysis}
   [2] Enter custom message

Example: "1, 1" or "2, Fix validation bug in user form"
```

### Auto-generating Commit Message Suggestion

Analyze the staged/changed files and generate a meaningful suggestion:

- Look at file names and paths to understand the domain
- If possible, read a sample of the diff to understand the nature of changes
- Suggest something like "Update user validation logic" or "Add error handling to API calls"

### Handle No-Ticket Branch

If the branch has no recognizable ticket pattern (e.g. `NO-CARD-fix-header`, `chore/no-ticket-update-deps`), skip the ticket reference in the commit message and proceed normally.

### Parsing User Response

- Accept answers separated by commas or on multiple lines
- For file selection: accept number (1-3)
- For commit message: if user picks "1", use suggestion; otherwise use their text
- Do NOT ask for confirmation of the commit message

### 4. Format Commit Message

```
[{Type}] {Summary} ({TICKET_ID})
```

Or without ticket:

```
[{Type}] {Summary}
```

Examples:

- `[Fix] Standardize token_info schema across all chains (SQRN-1234)`
- `[Feat] Add user profile component (SQSH-5678)`
- `[Feat] Add user authentication`

Type capitalization:

- fix → Fix
- feat → Feat
- chore → Chore
- docs → Docs
- test → Test
- style → Style

### 5. Stage and Commit

**Scope guard (required before staging):**

- Only stage changes from repos resolved in the current feature.
- If changed files include unrelated work from previous tasks, ask the user to select specific files or repos; do not stage everything by default.
- Never force-add ignored files (`git add -f` is not allowed). Respect each repo's `.gitignore`.

For each repo with changes:

```bash
cd <repo_path>
git add --all
git commit -m "[Type] Summary (TICKET)"
```

If hu-translations has changes and resolves to a non-base branch (per feature resolution):

```bash
cd <hu_translations_path>
git add --all
git commit -m "[Type] Summary (TICKET)"
```

Use the same commit message across all repos for traceability.

### 6. Pre-Push Gate (Mandatory)

**After committing and before pushing**, run the lint and type-check commands from `$REPOS_FILE` for every repo that has changes. This gate is mandatory and cannot be skipped silently.

For repos using `npm`/`pnpm`, run checks through the shared runtime guard so runtime is auto-corrected with `nvm use` only when needed.

For each repo with commits to push:

```bash
cd <repo_path>

# npm/pnpm repos (auto runtime correction + command execution)
bash "$PLUGIN_ROOT/scripts/check-runtime.sh" <repo_path> -- bash -lc "<lint_cmd>"
bash "$PLUGIN_ROOT/scripts/check-runtime.sh" <repo_path> -- bash -lc "<type_check_cmd>"

# non-node repos
<lint_cmd>
<type_check_cmd>
```

Display results:

```
Pre-push checks:

humand-web:
  Lint (pnpm biome:check): No issues
  TypeScript (pnpm tsc): No errors

material-hu:
  ESLint (npm run lint): 2 errors in Avatar.tsx
```

If checks fail:

1. Show errors clearly
2. If runtime check still fails after the automatic `nvm use` attempt, stop and ask the user to run `nvm use` manually before retrying.
3. **Determine whether the errors are introduced by this branch** — compare against the base branch if needed. Pre-existing errors on the base branch do not block the push.
4. If the branch introduced new errors: ask "Fix issues and retry?" or "Skip push?" — **do not push**.
5. If fixing, run `lint_fix_cmd`, create a **new** follow-up commit, then re-run the gate.
6. If all errors are pre-existing on the base branch, note this explicitly and proceed.

> **IMPORTANT**: This gate applies to every push, not just /pr. Any time code is pushed to a remote — whether via /commit, /pr, or a manual `git push` during a conversation — the gate must pass first. Never push code that introduces lint or type-check failures.

### 7. Push Branches

After the gate passes, push each repo's branch to the remote:

```bash
cd <repo_path>
git push -u origin <branch_name>
```

If the push fails because the remote is ahead, pull with rebase and retry:

```bash
git pull --rebase origin <branch_name>
git push -u origin <branch_name>
```

If the push is rejected for other reasons, report the error and continue with the next repo.

### 8. Confirmation & Chaining

Show the commit and push summary:

```
Committed and pushed to 2 repos:

humand-web:
  [Feat] Add user profile component (SQRN-1234)
  3 files changed, 142 insertions(+), 12 deletions(-)
  Pushed to origin/feat/SQRN-1234-add-user-profile

material-hu:
  [Feat] Add user profile component (SQRN-1234)
  1 file changed, 23 insertions(+), 5 deletions(-)
  Pushed to origin/feat/SQRN-1234-add-user-profile
```

Then offer the next skill:

```
Would you like me to run /pr to create or update PRs?
```

If the user accepts, immediately invoke `/pr`. If they decline, stop.

## Files to Always Ignore

Never stage or commit agent working files from `.claude/` or `$STATE_HOME`. When showing changes, filter these out.

## Error Handling

- If repo not on feature branch: Warn and skip (or offer to checkout)
- If nothing to commit: Skip repo silently
- If commit fails: Show error, continue with other repos, report at end
- If `$LOCAL_CONFIG_FILE` is missing: Tell user to copy from `local-config.example.json` into `$CONFIG_HOME`

## Notes

- Commits are pushed immediately after staging
- Use /pr to create PRs (push is already done by /commit)
- Same commit message maintains traceability across repos
- Do NOT use co-authored-by in commit messages
- Do NOT use --no-verify unless user explicitly asks
- Do not amend commits in this workflow; create follow-up commits when fixes are needed