commit-and-push

Create a well-formatted git commit and push to remote repository

설치로 이동

저장소: jmagly/aiwg
최근 소스 활동: 2026년 7월 20일 16:54
감지된 SKILL.md 언어: 영어
스타: 178
포크: 26

설치 방법

기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

직접 명령은 검토 Prompt를 거치지 않습니다. 실행하기 전에 소스를 확인하세요.

npx skills add https://github.com/jmagly/aiwg --skill commit-and-push

명령은 한 줄로 유지됩니다. 복사하기 전에 가로로 스크롤해 전체 내용을 확인하세요.

로컬 사본을 원하시나요? SkillsMP에서 현재 제공할 수 있는 파일을 다운로드하세요.

소스 파일 검토

설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.

SKILL.md

소스 지침 · 읽기 전용 미리보기

검색으로 돌아가기 설치로 돌아가기

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]:

Review changes using git status and git diff --stat
Stage appropriate files (exclude generated files, secrets)
Craft commit message following conventions below
Commit with proper formatting (HEREDOC for multi-line)
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):

If remotes.primary is set → push to that remote name.
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 secondary[] entry whose push_on_release flag is true. Example for this repo's topology (origin = Gitea primary, github = public mirror):

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

commit-and-push

소스 정보

설치 방법

소스 파일 검토

이 저장소의 다른 Skills

이 저장소의 다른 Skills

Commit and Push

Task

Commit Message Format

Type (Required)

Scope (Optional)

Subject (Required)

Body (Optional but Recommended for Multi-Area Changes)

Footer (Optional)

CRITICAL: No AI Attribution

Workflow

Step 1: Review Changes (stat-first approach)

Step 2: Stage Files

Step 3: Commit

Delivery policy resolution (before staging)

Step 4: Push

Release-time mirroring

References

Commit and Push

Task

Commit Message Format

Type (Required)

Scope (Optional)

Subject (Required)

Body (Optional but Recommended for Multi-Area Changes)

Footer (Optional)

CRITICAL: No AI Attribution

Workflow

Step 1: Review Changes (stat-first approach)

Step 2: Stage Files

Step 3: Commit

Delivery policy resolution (before staging)

Step 4: Push

Release-time mirroring

References