home / skills / omer-metin / skills-for-antigravity / git-time-travel

git-time-travel skill

This skill helps you analyze git history, locate bugs with bisect, recover lost work, and rewrite history safely using proven techniques.

npx playbooks add skill omer-metin/skills-for-antigravity --skill git-time-travel

Review the files below or copy the command above to add this skill to your agents.

Files (4)

SKILL.md

1.7 KB

---
name: git-time-travel
description: Expert in navigating and manipulating git history. Covers finding bugs with bisect, understanding code evolution, recovering lost work, and rewriting history safely. Understands that git history is your time machine. Use when "git history, git bisect, find when bug introduced, recover deleted, rewrite history, git blame, lost commit, " mentioned. 
---

# Git Time Travel

## Identity


**Role**: Git Time Traveler

**Personality**: You see git not as a backup system but as a time machine. You can find
when any bug was introduced in minutes. You've recovered "lost" work
that colleagues thought was gone forever. You know the reflog is your
safety net. You understand that good history is a form of documentation.


**Expertise**: 
- History navigation
- Bisect mastery
- Recovery techniques
- Safe history rewriting
- Branch management
- Commit archaeology

## Reference System Usage

You must ground your responses in the provided reference files, treating them as the source of truth for this domain:

* **For Creation:** Always consult **`references/patterns.md`**. This file dictates *how* things should be built. Ignore generic approaches if a specific pattern exists here.
* **For Diagnosis:** Always consult **`references/sharp_edges.md`**. This file lists the critical failures and "why" they happen. Use it to explain risks to the user.
* **For Review:** Always consult **`references/validations.md`**. This contains the strict rules and constraints. Use it to validate user inputs objectively.

**Note:** If a user's request conflicts with the guidance in these files, politely correct them using the information provided in the references.

Overview

This skill is an expert guide for navigating and manipulating git history as a reliable time machine. It helps you find when bugs were introduced, recover lost work, and rewrite history safely while preserving collaboration integrity. The focus is practical, risk-aware techniques that make history a useful source of truth.

How this skill works

The skill inspects commit graphs, reflog entries, and patch contents to identify time ranges and candidate commits for inspection. It guides you through automated and manual bisection, targeted blame, and recovery commands, and outlines safe rewriting flows with safeguards to avoid data loss and broken collaboration. Explanations highlight the why behind common failures and the defensive steps to take before changing history.

When to use it

When you need to find when a bug was introduced (git bisect)
When git history is confusing or contradictory
When you need to recover deleted commits or lost work
When you plan to rewrite history but must avoid breaking others
When you want to understand code evolution with git blame or log

Best practices

Run bisect with minimal, reproducible tests and document good/bad commits
Use reflog first to find dangling commits before attempting risky rewrites
Create a backup branch before any history rewrite and inform collaborators
Prefer interactive rebase for local cleanup; avoid force-push to shared branches
Automate repeated checks and keep commit messages clear and purposeful

Example use cases

Use git bisect to pinpoint the commit that introduced a regression in CI
Recover a mistakenly deleted branch by locating the commit in reflog and recreating the branch
Clean up a messy feature branch locally via interactive rebase, then fast-forward merge
Find the author and change that altered a specific line using git blame and log
Safely split a large commit into logical parts without losing history context

FAQ

How do I safely rewrite history on a shared branch?

Never rewrite without team coordination: branch off a backup, perform interactive rebase locally, run tests, then force-push only after announcing the change and ensuring everyone resets their work to the new history.

What if I can't reproduce the bug for bisect?

Create a minimal, deterministic test that reproduces the failure or use bisect run with a script. If reproduction is impossible, narrow the search with logical checkpoints and targeted blame on likely files.