git-audit

Branch and Specification Audit

When to Use and When Not Applicable

This skill is not applicable as a substitute for CodeGuard quality, platform protection, or deployment acceptance. It can be installed standalone; 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 parent repository's real root and project instructions, and preserve user modifications.
• Existing specifications take precedence; no Git, no specification, detached, shallow history, and unknown provenance must be explicitly reported.
• 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 user's existing authorization scope.
• Project Rules and Evidence is a self-contained reference for this skill;authoritative directory is used for model and provenance verification.

Execution Steps

Step 1

Discover the real root and status, load the definition and activated revision; candidate drift is reported first and cannot take effect automatically.

Step 2

Check required long-lived fixed roles according to the model; temporary types are only checked against existing instances, and missing feature/release/hotfix instances are not reported as missing.

Step 3

Verify Git names and roles branch by branch, detecting multi-role matches, unrecognized naming, and fixed-name conflicts.

Step 4

Check provenance, record source OID and operation logs; if there is no provenance record, mark it as unknown, and note limitations for shallow history.

Step 5

Check for dirty, detached, merge/rebase/cherry-pick interruptions; do not use merge relationships as a substitute for naming and provenance checks.

Step 6

Keep local tracking and server-side facts separate; the existence of protection rules in JSON does not prove that GitHub/GitLab has blocked direct pushes.

Step 7

Output violations, unknowns, explicit passes, and minimal remediation suggestions. Modifying branches/activating specifications requires separate authorization and is not remediated during the audit.

Standalone Tool and Plugin Paths

First locate this skill's scripts/inspect_repository.py, and follow contract to read status using the commands in it. Python 3.11+ standard library, read-only and does not initialize. Actual commands use the current skill's directory; the mounted example is:

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

When the GitFlow plugin is available, invoke the commands corresponding to its actual path; see operation examples. Do not treat uninstalled CLI names as existing commands.

Verification and Output

Reports should carry repository identity, rule revision, and evidence level. CodeGraph or static relationships cannot replace Git status and real service protection.

Output must distinguish: facts, rule sources, suggestions, user authorization, and unverified items. After write operations, verify current refs/HEAD/status; plans and previews are not completion evidence. 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 Examples

An idle classic project with only main+develop passes coverage; a manual feature branch lacking a provenance record is listed separately as unknown.

Negative Examples

Treating the absence of temporary branches as a failure, or claiming branches are platform-protected without accessing the remote protection API.

Gotchas (Situations Prone to Misjudgment)

• .git When it is a file, it may still be a valid working tree; first query Git/common-dir.
• Branch pattern compliance 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 real-time remote has been implemented.
• Do not pre-create false long-term refs for a new project with empty history; the initial commit must clearly define the bootstrap plan.
• Review the active revision first for definition changes; passing quality checks does not exempt branch rules.
• Do not blindly replay completed steps due to timeout and no response; check Git status and operation logs first.

Exception handling

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

Optional handoff

When other responsibilities are needed, invoke by name; do not assume 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 user authorization.