Push

---
name: push
description: Validate, commit, and push.
practices:
- continuous-delivery
- gitops
- dora-metrics
hexagonal_role: driving-adapter
consumes:
- git-changes
produces:
- git-changes
context_rel: []
skill_api_version: 1
user-invocable: true
context:
  window: isolated
  intent:
    mode: none
  sections:
    exclude:
    - HISTORY
    - INTEL
    - TASK
  intel_scope: none
metadata:
  tier: execution
  dependencies: []
  triggers:
  - push
  - ship it
  - commit and push
  - push changes
output_contract: git commit + push
---

# Push Skill

Atomic test-commit-push workflow. Catches failures before they reach the remote.

## Steps

### Step 1: Detect Project Type

Determine which test suites apply:

- **Go:** Check for `go.mod` (or `cli/go.mod`). If found, Go tests apply.
- **Python:** Check for `requirements.txt`, `pyproject.toml`, or `setup.py`. If found, Python tests apply.
- **Shell:** Check for modified `.sh` files. If found, shellcheck applies (if installed).

### Step 2: Run Tests

Run ALL applicable test suites. Do NOT skip any.

**Go projects:**
```bash
cd cli && go vet ./...
cd cli && go test ./... -count=1 -short
```

**Python projects:**
```bash
python -m pytest --tb=short -q
```

**Shell scripts (if shellcheck available):**
```bash
shellcheck <modified .sh files>
```

If ANY test fails: **STOP.** Fix the failures before continuing. Do not commit broken code.

### Step 3: Stage Changes

```bash
git add <specific files>
```

Stage only the files relevant to the current work. Do NOT use `git add -A` unless the user explicitly requests it. Review untracked files and skip anything that looks like secrets, temp files, or build artifacts.

### Step 4: Write Commit Message

Write a conventional commit message based on the diff:

- Use conventional commit format: `type(scope): description`
- Types: `feat`, `fix`, `refactor`, `docs`, `test`, `chore`, `style`, `perf`
- Keep subject line under 72 characters
- Focus on WHY, not WHAT

### Step 5: Commit

```bash
git commit -m "<message>"
```

### Step 6: Sync with Remote

```bash
git pull --rebase origin $(git branch --show-current)
```

If rebase conflicts occur: resolve them, re-run tests, then continue.

### Step 7: Push

```bash
git push origin $(git branch --show-current)
```

### Step 8: Report

Output a summary:
- Files changed count
- Tests passed (with suite names)
- Commit hash
- Branch pushed to

## Guardrails

- NEVER push to `main` or `master` without explicit user confirmation
- NEVER stage files matching: `.env*`, `*credentials*`, `*secret*`, `*.key`, `*.pem`
- If tests were not run (no test suite found), WARN the user before committing
- If `git pull --rebase` fails, do NOT force push — ask the user

## Examples

### Pushing Changes

**User says:** `/push`

**What happens:**
1. Runs Go and Python tests
2. Commits with conventional message
3. Pushes to current branch

**Result:** Verified, committed, and pushed changes in one atomic workflow.

## Troubleshooting

| Problem | Cause | Fix |
|---------|-------|-----|
| Tests fail | Code has errors | Fix failing tests before retrying |
| Push rejected | Remote has new commits | Pull and rebase, then retry |
| No changes to commit | Working tree is clean | Make changes first |

## Reference Documents

- [references/push.feature](references/push.feature) — Executable spec: detect project type, run tests first, block push on failure, commit+push on green (soc-qk4b)