Skill
agent-loop-ext
Crash-resilient external agent loop with state persistence and CI/CD integration
Development
Skill
/commit-and-push
Create a well-formatted git commit and push to remote repository
Install
$ 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
Ships withaiwg
Reusable project context and specialist workflows for the AI tools you already use. Plan software, coordinate specialist reviews, prepare campaigns, investigate incidents, organize research, curate media, and maintain operational knowledge.
Get the whole plugin
Stats
213
Stars
31
Forks
Active
Maintenance
TypeScript
Language
MIT
License
6h ago
Last commit
1y ago
Created
Repo: jmagly/aiwg
Other skills on aiwg.
Skill
agent-loop
Detect requests for iterative autonomous agent loops and route to the appropriate loop executor
Skill
auto-test-execution
Automatically execute tests when code-generating agents modify source files, enforcing the execute-before-return pattern
Skill
cross-task-learner
Enable agent loops to learn from similar past tasks and share patterns across loops
Skill
debug-memory
Query and manage the executable feedback debug memory
Skill
execute-feedback
Execute tests on generated code and iterate until passing