git-awesome

Authoritative resource navigation and comparison

When to use and when not to apply

This skill is not intended to replace 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 parent repository's real root and project instructions, and preserve user changes.
• Existing conventions take precedence; no Git, no conventions, detached, shallow history, and unknown sources need to be clearly reported.
• Read-only observation and previews may be executed; Git initialization, branch creation/switching, committing, pushing, integration, cleanup, installing hooks, and rule activation are executed according to 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 source verification.

Execution steps

Step 1

Clarify the release cadence, maintained versions, team size, deployment method, and contributor permissions to be compared, without first assuming develop is needed.

Step 2

Read this skill's workflow directory, prioritizing original authors, Git official, platform official, and DORA; third-party awesome lists are only entry points.

Step 3

Open the primary sources relevant to the question, record the URL, publisher, date checked, and related claims; when links are broken, report the snapshot date.

Step 4

Separate official models, template choices, and project extensions. Make clear that main/master renaming and the feature/ prefix are project conventions.

Step 5

Compare branch roles, creation baselines, propagation direction, short-term/long-term lifecycles, version maintenance, and collaboration remotes, and output the basis for the choice.

Step 6

After proposing model recommendations, check them against the current project's existing conventions and hand off to workflow selection; this skill does not activate or write.

Standalone tools and plugin paths

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

python3 /mnt/skills/user/git-awesome/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 a CLI name that is not installed as an existing command.

Verification and output

Output a source table, comparison table, applicability conditions, and unverified questions. Do not use the statement that "the official Git standard requires GitFlow."

Output must distinguish: facts, rule sources, recommendations, user authorization, and unverified items. After write operations, verify 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

Compare a library released once a month while maintaining two versions with a service deployed daily; the former evaluates Classic Git Flow, the latter evaluates GitHub Flow/trunk-based development.

Counterexample

Summarizing sources as "all projects must have develop, release, hotfix"; or mixing the Microsoft and Git maintainer fix directions into the same rule.

Gotchas (situations prone to misjudgment)

• .git being a file can still be a valid working 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 actually implemented them.
• A new project with empty history should not pre-create false long-term refs; the initial commit must have an explicit bootstrap plan.
• Review the activated revision first when defining changes; passing quality checks does not exempt branch rules.
• Do not blindly replay steps that have already been completed just because of a timeout and no response; check Git status and operation logs first.

Exception Handling

Missing/drifted/corrupted rules, unknown identity, interrupted operations, or insufficient source evidence: stop the related write actions, report unverified and the specific information needed, and continue with 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 install automatically, 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 them by name and 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 user authorization.