/commit-and-push
Create a well-formatted git commit and push to remote repository
$ npx -y skills add jmagly/aiwg --skill commit-and-push --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/commit-and-push
Context preview
The summary Claude sees to decide when to auto-load this skill.
Create a well-formatted git commit and push to remote repository
SKILL.md
commit-and-push.SKILL.mdnamespace: aiwg
name: commit-and-push
platforms: [all]
description: Create a well-formatted git commit and push to remote repository
commandHint:
argumentHint: [commit-message-summary --interactive --guidance "text"]
allowedTools: Bash, Read, Grep
model: haiku
category: version-control
modelRole: efficiency
modelTier: economy
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)
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:
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.
git add path/to/file1 path/to/file2
If files are unrelated (e.g., bug fix + docs), make separate commits.
Step 3: Commit
**Standard**:
git commit -m "type(scope): subject"
**HEREDOC** (for messages with body/footer):
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, resolve the target workspace member and check `commit` (and later `push`) with `aiwg repo-access check`. Consult the **target member's** `.aiwg/aiwg.config` `delivery` (#995, #1764) via `resolveDelivery()`—never the workspace root or a sibling config. 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 target member declares a `remotes` block in `.aiwg/aiwg.config` (#994), push to that member's resolved primary remote—not a workspace-root remote and not whatever was hard-coded as `origin`. Workspace `push` authorization is an additional required gate.
**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.
# 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 `secon
Read more
namespace: aiwg name: commit-and-push platforms: [all] description: Create a well-formatted git commit and push to remote repository commandHint: argumentHint: [commit-message-summary --interactive --guidance "text"] allowedTools: Bash, Read, Grep model: haiku category: version-control modelRole: efficiency modelTier: economy
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)
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:
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.
git add path/to/file1 path/to/file2
If files are unrelated (e.g., bug fix + docs), make separate commits.
Step 3: Commit
**Standard**:
git commit -m "type(scope): subject"
**HEREDOC** (for messages with body/footer):
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, resolve the target workspace member and check `commit` (and later `push`) with `aiwg repo-access check`. Consult the **target member's** `.aiwg/aiwg.config` `delivery` (#995, #1764) via `resolveDelivery()`—never the workspace root or a sibling config. 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 target member declares a `remotes` block in `.aiwg/aiwg.config` (#994), push to that member's resolved primary remote—not a workspace-root remote and not whatever was hard-coded as `origin`. Workspace `push` authorization is an additional required gate.
**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.
# 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 `secon
Multi-agent AI framework for Claude Code, Copilot, Cursor, Warp, and 6 more platforms 200+ agents, 109+ CLI commands, 400+ deployable agent/skill/command/rule artifacts, 8 core frameworks, 32 addons, and a 40-plugin Claude Code marketplace.
Repo: jmagly/aiwg
Other skills on aiwg.
- /agent-loop-ext
Crash-resilient external agent loop with state persistence and CI/CD integration
Open skill - /agent-loop
Detect requests for iterative autonomous agent loops and route to the appropriate loop executor
Open skill - /auto-test-execution
Automatically execute tests when code-generating agents modify source files, enforcing the execute-before-return pattern
Open skill - /cross-task-learner
Enable agent loops to learn from similar past tasks and share patterns across loops
Open skill - /debug-memory
Query and manage the executable feedback debug memory
Open skill - /execute-feedback
Execute tests on generated code and iterate until passing
Open skill