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 that 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 the project instructions, and preserve the user's changes.
- Existing conventions take precedence; no Git, no conventions, detached, shallow history, and unknown origin must be reported explicitly.
- Read-only observation and preview may be executed; Git initialization, branch creation/switching, committing, pushing, 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
Read-only diagnosis of HEAD, branch, status, interruption markers, and step-by-step logs; record timed-out states as unknown, and do not immediately retry write operations.
Step 2
Uncommitted changes can be carried by switch onto a compatible target; when Git refuses to overwrite, preserve the scene and do not automatically reset, checkout --, or stash drop.
Step 3
For a commit on the wrong branch, first determine the full OID and the correct task branch, preserve the original branch reference, then cherry-pick the single-parent commit; do not automatically delete the wrong branch's history.
Step 4
For a wrong baseline, first check the creation record, public refs, and team contract; if it is already public or the evidence is insufficient, propose a migration plan to a new correct branch, and do not force a rebase.
Step 5
The interrupted operation is uniquely identified as merge/rebase/cherry-pick/revert; abort/continue require explicit authorization, and before continue the conflicts are resolved and staged.
Step 6
resume reads the logs and the actual state, identifies completed steps, and does not blindly replay commits. Equivalent-patch verification prevents duplication; if the target is unclear, return unverified.
Step 7
After recovery, report preservation of the original references, the target OID, dirty state, and remaining backfill, and do not treat the absence of conflict markers as code correctness.
Standalone tool and plugin paths
First locate this skill's scripts/inspect_repository.py, and according to contract read the state with the commands in it. Python 3.11+ standard library, read-only and does not initialize. The actual command uses the directory where the current skill is located; the mount example is:
python3 /mnt/skills/user/git-recovery/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
The plugin resume is an observation and recovery suggestion, and does not automatically replay unknown commands. Conflict resolution must be verified against the current files and business behavior.
Output must distinguish: facts, rule sources, suggestions, user authorization, and unverified items. After write operations, verify the 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 example
The single-parent commit on feature/wrong is copied to feature/right, the original reference remains unchanged; it is made clear that subsequent handling of the wrong branch requires separate authorization.
Negative example
reset --hard wipes out the user's changes, force-pushing rewrites others' history, or repeatedly cherry-picking after a network timeout.
Gotchas (situations prone to misjudgment)
.gitWhen it is a file, it may still be a valid work tree; first query the Git/common-dir.- A matching branch pattern does not prove the source is correct; one manually created but lacking a record should be listed separately as unknown.
- Remote tracking and protection configuration text cannot prove that the real-time remote has implemented it.
- Empty history for a new project should not pre-create false long-term refs; the initial commit must have an explicit bootstrap plan.
- For definition changes, first re-review the active revision; passing a quality check cannot exempt branch rules.
- Do not blindly replay steps that have already been completed just because of a timeout with no response; first check Git status and the operation log.
Exception handling
Missing/drifting/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 done independently. Clear naming/flow violations: deny and give a preservation-oriented repair direction. Git unavailable or network failure: do not auto-install, and do not treat failure as success. Preserve the true state 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.