Git Maker

Git Maker Skill

Fast, safe commit-and-push orchestration.

Default all user-facing deliverables, saved artifacts, reports, plans, generated docs, summaries, handoff notes, commit/message drafts, and validation notes to Korean, even when this canonical skill file is written in English.

Preserve source code identifiers, CLI commands, file paths, schema keys, JSON/YAML field names, API names, package names, proper nouns, and quoted source excerpts in their required or original language.

Use a different language only when the user explicitly requests it, an existing target artifact must stay in another language for consistency, or a machine-readable contract requires exact English tokens. If a localized template or reference exists (for example *.ko.md or *.ko.json), prefer it for user-facing artifacts.

• Create one or more Conventional Commits from current repository changes.
• Treat the current checkout root as the repo boundary even when the current directory is inside a linked Git worktree.
• Push successfully created commits automatically, with no confirmation step between commit and push.
• Use the fast helper first to reduce repeated repository discovery and parallelize read-only inspection.

Use git-maker when the user wants commit + push in one operation.

Use a neighboring skill instead when:

• the user asks only to commit → use git-commit
• the user asks only to push/sync commits → use git-push
• the user asks to rebase/reset/amend/rewrite history → do not use git-maker unless commit+push is also explicitly requested and the history operation is separately authorized

Positive triggers:

• "commit and push"
• "commit and push these changes"
• "/git-maker"
• "make a commit and push it"
• "save and push my changes"
• Korean request meaning "commit and push"
• Korean request meaning "save the changes and upload them"
• git-maker, git-maker current, or git-maker ALL, optionally followed by && <branch> targets

Negative triggers:

• "commit these changes" → git-commit
• "push my commits" → git-push
• "rebase this branch" → not this skill

Boundary trigger:

• "commit this, then maybe push" → use git-commit because push is conditional, not automatic

Linked Git worktrees are valid execution contexts.

• Resolve each checkout with git rev-parse --show-toplevel; never assume .git is a directory or collapse linked worktrees to git-common-dir.
• Preserve each checkout root as its own index, branch, staging, commit, and push boundary.
• Continue from worktree|linked unless detached HEAD or another explicit safety rule blocks the run.

Read only what is needed:

1. rules/speed-and-automation.md when the user asks for speed, the repo set may be large, or multiple repositories may be present.
2. rules/agent-parallelism.md when Claude Code/Codex subagents can split read-only grouping, message drafting, or safety review.
3. rules/commit-and-push-policy.md before staging/committing or when argument mode, grouping, safety, or push behavior is unclear.
4. rules/validation.md before reporting the run or skill refactor complete.

Parse the invocation as [scope] [--force] [&& target-branch ...]. Scope tokens and target branches are control syntax, not commit filters.

Stop if an explicit filter does not match actual git state.

Treat shell-style separators as invocation syntax even when the request is plain language rather than a literal shell command. Accept any scope-token casing (all, ALL, current, CURRENT). Reject empty target segments, duplicate targets, the source branch itself, detached HEAD, and branch names that fail git check-ref-format --branch.

Phase 1. Fast preflight

Run scripts/git-maker-fast.mjs inspect . --jobs 4 first. Use its repo, worktree, staged/unstaged/untracked, and file inventory output to determine scope and logical groups. If it fails or lacks detail, use scripts/repo-discover.mjs and scripts/repo-status.mjs.

Phase 2. Group and commit

Partition selected changes into one logical change per commit, use targeted staging, and commit sequentially per repository:

scripts/git-commit.mjs "<type>[scope]: <Korean subject>" path/to/file1 path/to/file2
scripts/git-commit.mjs --repo path/to/repo "<type>[scope]: <Korean subject>" path/to/file1

Use Korean neutral result-summary subjects after the Conventional Commit type/scope. Never include secrets or unrelated changes, bypass hooks, or push after a failed commit. Follow rules/commit-and-push-policy.md.

Phase 3. Push automatically

After every intended commit succeeds, push without confirmation. Prefer the preflight repo list:

scripts/git-maker-fast.mjs push /absolute/repo/path
scripts/git-maker-fast.mjs push --force /absolute/repo/path

Use scripts/git-push.mjs [--force] only as fallback.

Phase 4. Propagate to requested branches

For each && <branch> target, apply only the ordered commits created by this run in a clean linked worktree, resolve intent-preserving conflicts autonomously, validate, and push before continuing left-to-right. Ask one focused question only when resolution requires a material behavior, architecture, security, migration, or deployment-policy decision; preserve a recoverable state and do not start later targets. Follow rules/commit-and-push-policy.md for exact selection, propagation, and escalation rules.

Phase 5. Report

Report:

• commits created and messages
• repositories pushed
• target branches updated and pushed
• conflicts resolved automatically, checks run, or the exact decision required from the user
• skipped or failed push targets
• any remaining local changes or blockers

• Parallelize read-only inspection with inspect --jobs N; read rules/agent-parallelism.md before delegating complex grouping or review.
• Never parallelize mutations against one index. Subagents stay read-only; the main integrator owns staging, commit, propagation, and push.
• Push only after every intended commit succeeds.

• /git-maker → current-session changes only, grouped, committed, and auto-pushed.
• /git-maker ALL → every uncommitted change grouped, committed, and pushed.
• /git-maker current && dev && deploy/staging → current-session commits propagated and pushed left-to-right with autonomous reasonable conflict resolution.
• /git-maker && dev → default current scope, then verified propagation to dev.
• /git-maker --force → normal commit, then --force-with-lease; blocked on main/master.
• Linked-worktree invocation → operate at that checkout root and push its named branch.
• commit these changes → do not activate; route to git-commit.

Run the target quick validator, focused corpus validator, assets/evals/git-maker-cases.jsonl binary scenario check, helper syntax/runtime checks, and the repository skill verification gate described by rules/validation.md. This deterministic workflow uses no improvement loop; finish only when critical cases pass and residual warnings are stated.