investigating-repository-history
Skill169 starsChanged 57 days agoMITView on GitHub
Investigate GitHub repository history before risky code changes using git blame/log, GitHub PRs, review comments, squash/rebase/cherry-pick/rename heuristics, and cited evidence. Use when asking why code exists, whether a change is safe, what PR introduced behavior, or before editing API, compatibility, security, concurrency, persistence, migration, or performance-sensitive code.
In this repository23 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- agentic-readinessSkill
- bug-fix-protocolSkill
- clipboardSkill
- code-that-fits-in-your-headSkill
- fetch-url-as-markdownSkill
- fpf-problem-solvingSkill
- hooks-managementSkill
- installing-cli-toolsSkill
- maintaining-macos-healthSkill
- maintaining-windows-healthSkill
- mcp-managementSkill
- plan-modeSkill
- plugins-managementSkill
- prompt-engineeringSkill
- refactoring-csharpSkill
- repo-activity-summarySkill
- semantic-scholar-deepSkill
- settings-managementSkill
- skills-managementSkill
- ubiquitous-languageSkill
- windows-qa-engineerSkill
The file
We split this skill into the rules it gives an agent
12 rules. About 0 are common, 11 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈11
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 14
Use this skill to reconstruct the historical intent behind code before changing it.
- Distinctive: line 30
Use this skill when the user asks any of these:
- Distinctive: line 36
Before editing code that touches API compatibility, security, concurrency, persistence, migrations, performance, generated interfaces, …
- Distinctive: line 38
Do not use this skill for trivial new code with no dependency on existing behavior.
- Distinctive: line 42
Before making a risky edit, produce a history note answering:
- Very specific: line 51
If the evidence is weak, say UNKNOWN and lower confidence.
- Distinctive: line 105
Collect local history: Use the script or manual git blame -w -M -C -C -C, git log --follow, git log -S, and git log -G.
- Distinctive: line 106
Map commits to PRs: Prefer exact GitHub commit→PR association.
- Distinctive: line 108
Resolve anomalies: If mapping is weak, apply the Provenance Mesh: commit association + patch equivalence + content/symbol lineage.
- Distinctive: line 111
Produce a history note: before editing code.
- Distinctive: line 126
Never claim “this was decided” unless a commit, PR body, review, review comment, issue comment, or linked issue supports it.
- Distinctive: line 130
Use this concise template in the final answer or implementation plan:
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Repository History Investigator
Use this skill to reconstruct the historical intent behind code before changing it. The goal is not merely “find the blame commit”; the goal is to return a compact, cited history note explaining relevant PRs, review comments, constraints, rejected approaches, and anomalies.
Contents
- Trigger conditions
- Core rule
- Fast path
- Progressive disclosure
- Investigation workflow
- Evidence confidence rules
- Output template
- Gotchas
- Available scripts
Trigger conditions
Use this skill when the user asks any of these:
- “Why is this code written this way?”
- “Can I remove/simplify/change this check, constraint, branch, migration, public API, or feature flag?”
- “Which PR introduced this behavior or regression?”
- “Find the relevant PR/review discussion/history for this code.”
- Before editing code that touches API compatibility, security, concurrency, persistence, migrations, performance, generated interfaces, feature flags, or unclear legacy/workaround logic.
Do not use this skill for trivial new code with no dependency on existing behavior.
Core rule
Before making a risky edit, produce a history note answering:
- What code scope was inspected?
- Which commits and PRs are relevant?
- Which review comments or PR discussions explain intent?
- What constraints, risks, rejected approaches, or tests were found?
- Is the evidence strong, weak, contradictory, stale, truncated, or unknown?
- How should the implementation plan change?
If the evidence is weak, say UNKNOWN and lower confidence. Never invent intent from a semantic match alone.
Fast path
From the repository working tree, run the collector first. If the skill directory is not the current directory, prefix the script path with the installed skill path and pass --repo-dir /path/to/repo.
python3 scripts/history_context.py inspect \
--repo-dir /path/to/repo \
--path path/to/file.ext \
--start 120 --end 160 \
--question "Can I remove this constraint?" \
--format markdownFor symbol-level questions without exact lines:
python3 scripts/history_context.py inspect \
--repo-dir /path/to/repo \
--path path/to/file.ext \
--symbol SymbolOrFunctionName \
--question "Why does this behavior exist?" \
--format markdownFor JSON suitable for deeper agent reasoning:
python3 scripts/history_context.py inspect \
--repo-dir /path/to/repo \
--path path/to/file.ext \
--start 120 --end 160 \
--symbol SymbolOrFunctionName \
--question "What PR introduced this behavior?" \
--format json \
--output history-context.jsonThen read only the relevant sections of the output. Do not paste huge raw PR/comment dumps into the final answer.
Progressive disclosure
Load these files only when needed:
references/ANOMALIES.md— use when exact commit→PR mapping fails, or when squash, rebase, cherry-pick, backport, revert, rename, split, generated files, or mass refactors are possible.references/GH_CLI.md— use when the script fails or manualgh apicalls are needed.references/DECISION_ATOMS.md— use when converting PR/comment evidence into constraints, risks, rejected approaches, or test requirements.references/OUTPUT_SCHEMA.md— use when producing a formal machine-readable report.references/EVALUATION.md— use when testing or improving the skill.
Investigation workflow
- Define scope. Identify paths, line ranges, symbols, tests, error strings, feature flags, and any proposed diff.
- Collect local history. Use the script or manual
git blame -w -M -C -C -C,git log --follow,git log -S, andgit log -G. - Map commits to PRs. Prefer exact GitHub commit→PR association. Treat it as one signal, not the entire answer.
- Fetch PR evidence. For candidate PRs, inspect PR body, files, commits, reviews, inline review comments, and issue comments.
- Resolve anomalies. If mapping is weak, apply the Provenance Mesh: commit association + patch equivalence + content/symbol lineage.
- Extract decision atoms. Convert evidence into explicit claims: constraints, compatibility requirements, security invariants, performance constraints, rejected approaches, test requirements.
- Assess risk. Downgrade confidence for semantic-only matches, path-only matches, reverted PRs, API truncation, large PRs, generated files, or missing PRs.
- Produce a history note before editing code.
Evidence confidence rules
High confidence:
- exact GitHub commit→PR association; or
- patch/hunk equivalence plus path/symbol agreement; or
- review comment remaps to the current hunk/symbol and matches the proposed change.
Medium confidence:
- same symbol/path plus relevant PR discussion, but no patch-level match.
Low confidence:
- semantic search only, title/body match only, path-only match, or stale/reverted evidence.
Never claim “this was decided” unless a commit, PR body, review, review comment, issue comment, or linked issue supports it.
Output template
Use this concise template in the final answer or implementation plan:
## History note
Scope inspected: [paths, lines, symbols]
Relevant evidence:
- PR #[n] — [relation: exact/squash-like/rename-lineage/search], [why relevant], [confidence]
- Commit [sha] — [what it changed], [relation]
- Review/comment — [constraint or concern]
Decision atoms:
- [constraint/risk/rejected approach/test requirement] — [claim] — evidence: [PR/comment/commit]
Risk: [low|medium|high|unknown]
Confidence: [0.00-1.00]
Unknowns/truncation: [none or list]
Plan impact: [proceed|modify plan|ask human|do not change]Gotchas
git blameis a seed generator, not truth. Formatting commits, moves, squashes, and refactors can hide origin.- A PR can be relevant even if it did not introduce the current line; review comments may explain why an alternative was rejected.
- Squash merges often require patch/hunk matching because the final commit SHA differs from PR commits.
- File paths are not identity. Track file lineage, directory moves, symbol fingerprints, and hunk context.
- Reverted PRs are stale evidence unless a later PR reintroduced the same decision.
- Large
gh apiresponses may be truncated by the underlying GitHub endpoints. If truncation is possible, mark evidence incomplete. - General PR conversation comments come from issue comments; inline review comments come from PR review comments.
Available scripts
scripts/history_context.py— main collector for local Git + GitHub PR evidence. Runpython3 scripts/history_context.py --help.scripts/compact_pr.py— fetch one or more PRs and print compact evidence. Runpython3 scripts/compact_pr.py --help.scripts/validate_skill.py— validate this skill’s frontmatter and basic structure.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

