Help me investigate the history of this codebase so I understand the decision path, not just the current implementation. Use only the Git output, code excerpts, issue notes, and documentation I provide. Do not invent commit intent, ticket context, author motives, or commands that I have not shown. Question I need answered: [INVESTIGATION QUESTION] Repository and component: [REPOSITORY AND COMPONENT] Current code or behavior: [CURRENT CODE OR BEHAVIOR] Git history and diffs: [GIT EVIDENCE] Related issues, PR notes, or docs: [RELATED CONTEXT]
My current skill level: [SKILL LEVEL]
Build an explanation in this order:
1. Current-state map: explain the relevant files, entry points, data flow, and dependencies in plain language appropriate to my skill level.
2. Timeline: list the key commits or releases chronologically, with hash, date if supplied, observable change, evidence, and confidence level. Separate direct evidence from a reasonable inference.
3. Change rationale: connect each important diff to the problem it appears to solve, including trade-offs, compatibility constraints, tests added or missing, and any regression risk.
4. Learning path: give me 3 to 5 small investigation steps or Git commands to run next, explain what each result would prove or disprove, and include one exercise where I predict a result before seeing it.
5. Summary: answer my original question in 150 words or fewer and list unresolved questions.
Before answering, check that every claim about the past is tied to supplied evidence and flag gaps rather than guessing. Also check that you explain the “why” behind each change, not merely a diff summary. Ask up to 3 clarifying questions only if a required input is missing.Fill in
| Placeholder | What to enter | Example |
|---|---|---|
| [INVESTIGATION QUESTION] | State the historical question, such as why a retry mechanism was introduced. | Why was the payment webhook retry limit changed from 3 to 8 attempts? |
| [REPOSITORY AND COMPONENT] | Name the repository, branch, and files or service you are investigating. | acme-billing, main branch, src/webhooks/retry.ts and tests/retry.test.ts. |
| [CURRENT CODE OR BEHAVIOR] | Paste the relevant current code, error behavior, or a concise description of the component. | retryWebhook retries 8 times with exponential backoff and moves failures to a dead-letter queue. |
| [GIT EVIDENCE] | Paste relevant git log, blame, show, diff, bisect, or release-note output. | git log --oneline -- src/webhooks/retry.ts; commit 4af92c1 changes maxAttempts: 3 to 8 and adds a timeout test. |
| [RELATED CONTEXT] | Paste linked issue, pull-request, incident, or documentation notes that you can verify. | PR note: several partner endpoints recover after 10–15 minutes; issue BILL-184 reports lost callbacks. |
| [SKILL LEVEL] | Describe your familiarity with Git and the programming language so the explanation fits you. | Comfortable reading TypeScript; beginner with git blame and git bisect. |
How to use
- Start with one behavior or line of code rather than asking for the history of an entire repository.
- Paste focused git log, show, and blame output with the related code and any real issue or PR context.
- Check that the answer labels evidence separately from inference and that commit hashes match your repository.
- Follow up with: “Give me the exact Git commands to test the top unresolved question, and explain what each possible result means.”
Variations
Regression investigation
Use this when behavior changed between two known releases or commits.
Help me trace a regression in [COMPONENT] between [KNOWN GOOD VERSION] and [KNOWN BAD VERSION]. Use [TEST RESULTS], [GIT LOG OR BISECT OUTPUT], and [RELEVANT DIFFS]. Produce a narrow suspect list with evidence for and against each commit, then propose the next smallest reproduction or bisect step. Explain why each changed line could affect [FAILED BEHAVIOR]. Do not claim root cause without a reproducible link; label hypotheses and missing evidence.
Blame walkthrough
Use this when a line looks surprising and you want to learn how it arrived there.
Teach me how to investigate [CODE EXCERPT] using [GIT BLAME OUTPUT], [INTRODUCING COMMIT], and [FOLLOW-UP COMMITS]. Explain the line’s current role, what each historical change visibly did, and what context is absent. Then provide four Git commands I can run, each with a plain-language explanation and expected evidence. End with two questions I should ask the original PR or issue history. Do not infer author motivation beyond supplied notes.
Architecture evolution
Use this when onboarding to a system that changed shape over several releases.
Explain the evolution of [SYSTEM OR MODULE] using [RELEASE NOTES], [KEY COMMITS], and [CURRENT ARCHITECTURE]. Create a timeline of turning points, then compare the old and current data flow, boundaries, dependencies, and operational trade-offs. Identify decisions supported by evidence versus unresolved inference. Teach it at [SKILL LEVEL] with one diagram described in text and three code-reading exercises. Do not invent design rationale or historical incidents.
Tips
- Use path-limited history such as `git log -- path/to/file` before broad repository history; it keeps the evidence relevant.
- Read the parent commit and test changes around a suspicious diff, because a single changed line rarely captures the original constraint.
- Treat commit messages as evidence of stated intent, not proof that the change fixed the problem it claimed to fix.
- When you can identify a good and bad revision, reproduce the behavior before using `git bisect`; an unreliable test produces misleading history.
FAQ
Can AI tell me why an author made a commit?
Only when the commit, PR, issue, or documentation explicitly says so. Otherwise it should offer a clearly labeled inference based on the diff.
What Git output should I provide first?
Provide the current code, `git log` for its path, the relevant `git show` output, and linked PR or issue notes if available.
Is this useful for learning Git?
Yes. Ask the model to explain each proposed command and what its possible outputs would establish before you run it.