git-commit

Pre-commit branch and message gate

When to use and when not to use

This skill is not a substitute for CodeGuard quality, platform protection, or deployment acceptance. It can be installed on its own; without the GitFlow plugin, use read-only Git observation and rule-by-rule verification. It does not depend on adjacent skill files or assume the host automatically loads other skills.

Prerequisites and authorization

• Git is available and the project directory is clear. First confirm the real root of the parent repository and the project instructions, and preserve user modifications.
• Existing conventions take precedence; no Git, no conventions, detached, shallow history, and unknown origins must be reported explicitly.
• Read-only observation and previews may be executed; Git initialization, branch creation/switching, commits, pushes, integration, cleanup, hook installation, and rule activation are executed within the scope of the user's existing authorization.
• Project rules and evidence is a self-contained reference for this skill;authoritative directory is used for model and source verification.

Execution steps

Step 1

Before add/commit, discover the real branch, HEAD, and status; detached or interrupted operations enter recovery, and do not guess the current role.

Step 2

Verify that the current name matches a unique role and activated rules; candidate drift/corruption/missing rules return as unverified.

Step 3

Check allow_commit; protecting main/develop, etc., according to project conventions prohibits daily direct commits, and indicate the correct task branch.

Step 4

Check the complete commit message and project pattern; do not impose Conventional Commits when no message pattern is set.

Step 5

For the first empty-history commit, explain the bootstrap boundary separately: the default classic main prohibits daily direct commits, requires user confirmation of the initial commit plan, and does not secretly set exceptions.

Step 6

Complete the code quality checks requested by the user separately; git gate's allow refers only to branch rules and does not replace CodeGuard/tests.

Step 7

Before an authorized commit, check the staged scope and prevent unrelated changes from being mixed in; after the commit, verify SHA, branch, and status, and do not push automatically.

Standalone tool and plugin paths

First locate this skill's scripts/inspect_repository.py, and follow the commands in the contract to read status. Python 3.11+ standard library, read-only and does not initialize. The actual command uses the directory where the current skill is located; the mounted example is:

python3 /mnt/skills/user/git-commit/scripts/inspect_repository.py /absolute/project

When the GitFlow plugin is available, call the command corresponding to its actual path; see operation examples. Do not treat an uninstalled CLI name as an existing command.

Verification and output

The plugin gate --action commit --message provides machine results; native commit-msg can be installed explicitly, and existing hooks are preserved.

Output must distinguish: facts, rule sources, recommendations, user authorization, and unverified items. After write operations, check the current refs/HEAD/status; plans and previews are not evidence of completion. Security boundaries: do not leak credentials, do not upload the working tree; do not expose credentials, entire working tree contents, or sensitive remote URLs in logs.

Positive example

feature/123-login commit message satisfies the project format, the branch gate passes, then commit according to the current task authorization and report the SHA.

Counterexample

Committing directly on main because all tests pass and skipping the role convention; or treating amend as an ordinary commit to rewrite public history.

Gotchas (situations prone to misjudgment)

• .git When it is a file it may still be a valid work tree; first query Git/common-dir.
• A branch pattern match does not prove the source is correct; manually created but missing records should be listed separately as unknown.
• Remote tracking and protection configuration text cannot prove that the live remote has implemented it.
• Do not pre-create false long-term refs for a new project with empty history; the initial commit must have an explicit bootstrap plan.
• For definition changes, re-check the active revision first; passing quality checks does not exempt branch rules.
• Do not blindly replay completed steps due to a timeout with no response; first check Git status and operation logs.

Exception Handling

Missing/drifted/corrupted rules, unclear identity, interrupted operations, or insufficient source evidence: stop the relevant write actions, report unverified and the specific information needed, and continue with read-only work that can be completed independently. Explicit naming/flow violations: deny and provide a preservation-style remediation direction. Git unavailable or network failure: do not auto-install, and do not treat failure as success. Preserve the real scene of conflicts and handle them according to the recovery steps.

Optional Handoff

When other responsibilities are needed, invoke them by name; do not assume that the skill is installed. For example, workflow selection can be handed off to git-workflow；Install: npx skills add full-stack-skills/git-skills --skill git-workflow. Any handoff must not expand the user's authorization.