git-maker（git 制作者）

Git Maker Skill

Available scripts

• Create one or more Conventional Commits from the current repository state, then automatically push all committed changes to the remote.
• This is a sequential composition: git-commit workflow first, git-push workflow second.
• No confirmation step between commit and push. The push happens automatically after all commits succeed.

<trigger_conditions>

</trigger_conditions>

<argument_validation>

Arguments are passed through to the commit phase. Push phase has no arguments unless --force is specified.

If ARGUMENT is missing:

• Default to the files, repositories, and logical change units touched in the current session.
• Verify the session-derived candidate set against actual git status and git diff output before staging or committing.
• If the candidate set contains multiple logical change groups, identify each group and commit them separately in sequence. Do not stop or ask for clarification — iterate through all groups.
• If the current session's work is already fully committed, allow the remaining uncommitted changes to become the next candidate set and apply the same grouping logic.

If ARGUMENT is "ALL" or "all":

• Take ALL uncommitted changes in the repository, regardless of whether they were touched in the current session.
• Group all changes into logical change sets based on related functionality, feature area, or purpose.
• Commit each group separately in sequence. Do not stop, do not ask for confirmation, do not skip any files.
• Every uncommitted file must be included in exactly one commit group. No file may be left behind.

If ARGUMENT contains --force:

• Extract --force and pass it to the push phase (uses --force-with-lease).
• The remaining argument (if any) is passed to the commit phase.

If ARGUMENT is present (other than ALL and --force):

• Treat ARGUMENT as the primary commit target or filter.
• Use it to narrow repository discovery, file selection, staging, and commit message generation.
• If the filtered set contains multiple logical groups, commit each group separately.
• Stop if ARGUMENT does not match the actual repository state.

</argument_validation>

<scope_assumptions>

• Start from the current working directory. If it is not a git repository, inspect descendant directories for git repositories before proceeding.
• Commit AND push. No confirmation between the two phases.
• Use Bash commands only.

</scope_assumptions>

Phase 1. Commit — follow git-commit workflow

Execute the full git-commit workflow with these phases:

1a. Inspect repository state

Decide argument mode, then discover repositories.

scripts/repo-discover.sh

Then for each discovered repository:

scripts/repo-status.sh
scripts/repo-status.sh path/to/repo

1b. Identify logical change groups

Analyze the full candidate set and partition into logical change groups.

Grouping heuristics (apply in order):

1. Files that implement the same feature or fix belong together.
2. Test files belong with their corresponding implementation files.
3. Config/build changes related to the same feature belong with that feature.
4. Unrelated standalone changes each form their own group.

In ALL mode: every uncommitted file must appear in exactly one group. No file may be left behind.

1c. Stage and commit each group (loop)

For each logical group, repeat:

Stage — only the files in the current group:

git add path/to/file1 path/to/file2

Generate commit message — Conventional Commits format:

<type>[optional scope]: <subject>

[optional body]

[optional footer]

Execute commit:

scripts/git-commit.sh "<type>[scope]: <subject>"
scripts/git-commit.sh --repo path/to/repo "<type>[scope]: <subject>"

With body or footer:

scripts/git-commit.sh "$(cat <<'EOF'
<type>[scope]: <subject>

<optional body>

<optional footer>
EOF
)"

Continue to next group until all groups are committed.

Commit rules (same as git-commit skill)

Phase 2. Push — automatic after successful commits

Do NOT ask for push confirmation. Push automatically after all commits succeed.

If any commit failed, stop and report the failure. Do not push.

scripts/git-push.sh

Or with force (when --force was in the argument):

scripts/git-push.sh --force

The push script handles:

1. Discovers repositories (current directory or descendants).
2. For each repository, checks the branch and upstream status.
3. Skips repositories with no unpushed commits, detached HEAD, or protected branch conflicts.
4. Pushes repositories that have commits ahead of upstream.
5. Reports a summary of pushed, skipped, and failed repositories.

Push failure handling

Phase 3. Report results

Report a combined summary:

• How many commits were created (and their messages)
• How many repositories were pushed
• Any skipped or failed push targets

<decision_tables>

Repository discovery

Argument mode

Type selection

</decision_tables>

Simple commit and push

/git-maker

Result:

• inspects current session changes
• groups, stages, and commits each logical group
• automatically pushes — no confirmation asked

Commit all and push

/git-maker ALL

Result:

• takes ALL uncommitted changes
• groups into logical change sets
• commits each group separately
• automatically pushes all

Commit and force push

/git-maker --force

Result:

• commits session changes as normal
• pushes with --force-with-lease (blocked on main/master)

Commit specific target and push

/git-maker packages/api session validation fix

Result:

• filters commit candidates to match ARGUMENT
• commits matching changes
• automatically pushes

Multiple logical groups

/git-maker

Result:

• session touched auth module + unrelated docs
• group 1: feat(auth): add passkey login flow → commit
• group 2: docs(cli): document release prerequisites → commit
• auto-push both commits

Multi-repo commit and push

/git-maker

Result (current directory is not a repo, but has descendant repos):

• discovers packages/web and packages/api as separate repositories
• commits in each repo independently: scripts/git-commit.sh --repo packages/web "fix(web): handle empty sessions" src/auth.ts scripts/git-commit.sh --repo packages/api "fix(api): validate session payload" src/routes/session.ts
• pushes each repo: scripts/git-push.sh
• reports: 2 commits created, 2 repositories pushed

Commit fails — no push

Result:

• hook failure during commit
• reports the blocker
• does NOT attempt push

• Confirm all git-commit validation checks passed for the commit phase.
• Confirm push was NOT preceded by a confirmation prompt.
• Confirm push was NOT attempted when any commit failed.
• Confirm force push was not used on main/master.
• Confirm the combined summary (commits + push) was reported.