commit-and-push
Create a well-formatted git commit and push to remote repository
What this skill does
# Commit and Push
You are a Git Version Control Specialist. Create clear, well-structured commits following project conventions.
## Task
When invoked with `/commit-and-push [commit-message-summary]`:
1. **Review** changes using `git status` and `git diff --stat`
2. **Stage** appropriate files (exclude generated files, secrets)
3. **Craft** commit message following conventions below
4. **Commit** with proper formatting (HEREDOC for multi-line)
5. **Push** to remote repository
## Commit Message Format
```
<type>(<scope>): <subject>
<body>
<footer>
```
### Type (Required)
- `feat`: New feature
- `fix`: Bug fix
- `docs`: Documentation only
- `style`: Formatting, no code change
- `refactor`: Code change that neither fixes bug nor adds feature
- `perf`: Performance improvement
- `test`: Adding or correcting tests
- `chore`: Build process or auxiliary tools
- `ci`: CI/CD configuration
- `build`: Build system or dependencies
- `revert`: Reverts a previous commit
### Scope (Optional)
Component or area affected. Project-specific scopes for AIWG:
- `agents`, `commands`, `templates`, `tools`, `docs`, `intake`, `flows`
- `cli`, `config`, `tests`, `api`, `ui`
### Subject (Required)
- Imperative mood ("add feature" not "added feature")
- Lowercase first letter, no period at end
- Maximum 50 characters
- Be specific and concise
### Body (Optional but Recommended for Multi-Area Changes)
- Separate from subject with blank line
- Wrap at 72 characters
- Explain **what** and **why**, not **how**
- Use bullet points for multiple changes
- Reference issues if applicable
### Footer (Optional)
- Breaking changes: `BREAKING CHANGE: <description>`
- Issue references: `Closes #123`, `Fixes #456`, `Refs #789`
## CRITICAL: No AI Attribution
**DO NOT include** in commit messages:
- `Generated with Claude Code` or any AI tool name
- `Co-Authored-By: Claude` or any AI co-author
- Any AI tool attribution or signatures
## Workflow
### Step 1: Review Changes (stat-first approach)
```bash
git status
git diff --stat # file-level summary, not full content
git diff --cached --stat # staged changes summary
git log --oneline -5 # recent commit style reference
```
Only read full diff for specific files when the stat is insufficient to understand the change:
```bash
git diff -- <specific-file> # targeted full diff when needed
```
**Rule**: For files you already modified in this session, the stat is sufficient. Only read full diffs for unfamiliar files or when the filename alone doesn't clarify the change.
### Step 2: Stage Files
Stage specific files by name. Exclude: `.env`, secrets, `dist/`, `build/`, `node_modules/`, `*.log`, IDE files.
```bash
git add path/to/file1 path/to/file2
```
If files are unrelated (e.g., bug fix + docs), make separate commits.
### Step 3: Commit
**Standard**:
```bash
git commit -m "type(scope): subject"
```
**HEREDOC** (for messages with body/footer):
```bash
git commit -m "$(cat <<'EOF'
type(scope): subject
Body paragraph explaining the change.
- Bullet point 1
- Bullet point 2
Closes #123
EOF
)"
```
**DO NOT use**: `--no-verify`, `--allow-empty-message`, `--amend` (unless explicitly correcting last commit).
### Delivery policy resolution (before staging)
Before staging or committing, consult `.aiwg/aiwg.config` `delivery` (#995) via `resolveDelivery()` — the resolved policy controls **how** this commit gets shipped:
| Field | Effect on this skill |
|-------|----------------------|
| `mode: direct` | Commit and push directly to `default_branch` — skip branch creation |
| `mode: feature-branch` | Create a feature branch (per `branch_naming`), commit, push the branch, but don't open a PR |
| `mode: pr-required` (default) | Feature branch + push + open PR via the resolved primary remote (#994) |
| `force_push_policy: never` (default) | Refuse `git push --force` / `--force-with-lease` regardless of branch |
| `force_push_policy: own-branch-only` | Allow force-push only on the agent's own feature branch, never `default_branch` |
| `force_push_policy: allowed` | No force-push restriction (rare; signal of an unusual workflow) |
| `require_signed_commits: true` | Add `-S` to `git commit` |
| `branch_naming.prefix_by_type` | Interpolate `{issue}` and `{slug}` to compute the new branch name when creating one |
When the project has no `delivery` block, `resolveDelivery(undefined)` returns the conservative defaults — same behavior as today. No regression for existing projects.
### Step 4: Push
Default to `git push` (uses the branch's tracked upstream). When the project declares a `remotes` block in `.aiwg/aiwg.config` (#994), push to the resolved primary remote — not whatever was hard-coded as `origin`.
**Resolution rule** (consult `.aiwg/aiwg.config`):
1. If `remotes.primary` is set → push to that remote name.
2. Otherwise → fall back to the default `origin`.
The `resolveRemotes()` helper in `src/config/aiwg-config.ts` returns the resolved remote topology with these defaults applied. Skills don't need to re-implement the rule — read it, use it.
```bash
# Default — branch tracks an upstream
git push
# Explicit primary (when not the branch's tracked upstream)
git push <resolved-primary>
```
### Release-time mirroring
When pushing tags as part of a stable release cut, also mirror the tags to every `secondary[]` entry whose `push_on_release` flag is `true`. Example for this repo's topology (`origin` = Gitea primary, `github` = public mirror):
```bash
git push origin --tags # primary CI / release
git push github --tags # mirror — only because push_on_release: true
```
Skip secondary remotes that don't have `push_on_release: true`. Don't push branches to mirrors — only tags on stable releases.
**NEVER** force push to shared branches unless explicitly required and safe.
## References
- @$AIWG_ROOT/agentic/code/addons/aiwg-utils/README.md — aiwg-utils addon overview
- @$AIWG_ROOT/agentic/code/addons/aiwg-utils/rules/human-authorization.md — Confirmation before destructive git operations
- @$AIWG_ROOT/agentic/code/addons/aiwg-utils/rules/instruction-comprehension.md — Correct interpretation of commit message intent
- @$AIWG_ROOT/docs/cli-reference.md — CLI reference for AIWG versioning and release workflow
Related in General
modeling-omnistudio-epc-catalog
IncludedSalesforce Industries CME EPC product-modeling skill for Product2-based catalog creation. Use when creating EPC products, configuring product attributes, building offer bundles with Product Child Items, or reviewing EPC DataPack JSON metadata for product catalog changes. TRIGGER when: user creates or updates Product2 EPC records, AttributeAssignment payloads, AttributeMetadata/AttributeDefaultValues, Offer bundles, or ProductChildItem relationships. DO NOT TRIGGER when: designing OmniScripts/FlexCards/Integration Procedures (use building-omnistudio-omniscript, building-omnistudio-flexcard, or building-omnistudio-integration-procedure), implementing Apex business logic (use generating-apex), or troubleshooting deployment pipelines (use deploying-metadata).
relationship-science-coach
IncludedUse this skill for direct, practical adult relationship coaching: couples conflict, repair, trust, marriage, dating, flirting, attachment patterns, emotional connection, sex, desire differences, eroticism, kink negotiation, affection, love languages, breakups, and long-term passion. Draw on Gottman, EFT and Hold Me Tight, attachment science, modern sex research, Perel, Nagoski, Kerner, Schnarch, Love and Stosny, and flexible love-language tools. Be concrete and low-hedge. Redirect only for imminent danger, abuse, coercive control, minors, non-consent, self-harm, stalking, or medical/legal/psychiatric decisions.
building-sf-integrations
IncludedSalesforce integration architecture and runtime plumbing with 120-point scoring. Use this skill to set up Named Credentials, External Credentials, External Services, REST/SOAP callout patterns, Platform Events, and Change Data Capture. TRIGGER when: user sets up Named Credentials, External Services, REST/SOAP callouts, Platform Events, CDC, or touches .namedCredential-meta.xml files. DO NOT TRIGGER when: Connected App/OAuth config (use configuring-connected-apps), Apex-only logic (use generating-apex), or data import/export (use handling-sf-data).
venue-templates
IncludedAccess comprehensive LaTeX templates, formatting requirements, and submission guidelines for major scientific publication venues (Nature, Science, PLOS, IEEE, ACM), academic conferences (NeurIPS, ICML, CVPR, CHI), research posters, and grant proposals (NSF, NIH, DOE, DARPA). This skill should be used when preparing manuscripts for journal submission, conference papers, research posters, or grant proposals and need venue-specific formatting requirements and templates.
let-fate-decide
IncludedDraws the 12 Houses of the Zodiac Tarot spread to inject entropy into planning when prompts are vague, ambiguous, or casually delegated. Interprets the spread to guide next steps. Use when the user says 'let fate decide', 'YOLO', 'whatever', 'idk', or other nonchalant phrases, makes Yu-Gi-Oh references, or when you are about to arbitrarily pick between multiple reasonable approaches. Prefer over ask-questions-if-underspecified when the user's tone is casual or playful rather than precision-seeking.
net-ops
IncludedCross-platform network troubleshooting (Windows, macOS, Linux) via local or remote shell. Use for: DNS broken, can't resolve hostnames, nslookup/dig works but apps fail, NRPT, WFP, scutil, /etc/resolver, systemd-resolved, /etc/resolv.conf, NetworkManager, VPN DNS leak residue (ProtonVPN/Mullvad/WireGuard/AnyConnect), AV/firewall blocking DNS or DoH, Tailscale DNS interaction, intermittent connectivity, remote diagnostics over SSH.