investigating-repository-history

Featured

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.

Code & Development 109 stars 8 forks Updated today MIT

Install

View on GitHub

Quality Score: 93/100

Stars 20%

Recency 20%

100

Frontmatter 20%

Documentation 15%

100

Issue Health 10%

License 10%

100

Description 5%

100

Skill Content

# 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](#trigger-conditions) - [Core rule](#core-rule) - [Fast path](#fast-path) - [Progressive disclosure](#progressive-disclosure) - [Investigation workflow](#investigation-workflow) - [Evidence confidence rules](#evidence-confidence-rules) - [Output template](#output-template) - [Gotchas](#gotchas) - [Available scripts](#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: 1. What code scope was inspected? 2. Which commits and PRs are relevant? 3. Which review comments or PR discussions explain i...

Details

Author: CodeAlive-AI
Repository: CodeAlive-AI/ai-driven-development
Created: 6 months ago
Last Updated: today
Language: Python
License: MIT

Integrates with

GitHub · DevTools

Bundled in these plugins

ai-driven-development

Similar Skills

Semantically similar based on skill content — not just same category

Code & Development Listed

git-blame-investigator

Reconstruct why a line of code exists from Git history — find the originating commit, read its message and full diff for intent, and see through reformatting/rename commits with ignore-revs and the pickaxe — before you change or delete it. Use when a line looks wrong or pointless and you want to remove it, when tracing a regression to its commit, or when onboarding to unfamiliar code.

1 Updated 1 weeks ago

imtiazrayhan

AI & Automation Listed

archaeologist

Use when changing unusual or defensive code, mature APIs, dependencies, or architecture, or estimating a migration where Git history may reveal hidden constraints.

2 Updated 4 days ago

Lum1104

Code & Development Listed

git-where

git-blame for WHY, not who — reconstructs the intent behind a line of code from commit/PR/issue/doc history and rules on whether the reason still exists. Use when asking 'why does this exist', 'why is this value 7', 'is this safe to delete/remove', 'can I remove this guard/flag/lock/retry', 'is this still needed', 'who added this and why', 'is this dead code', or before deleting any code you didn't write and don't understand. Also use when a review comment asks to justify an odd-looking line, and during refactors that would remove guards, timeouts, retries, or special cases. Not for 'who last touched this' (plain git blame) or 'what does this code do' (read it). Not for repo-level orientation. Core rule: a WHY is quoted from history or it is 'not recoverable' — never authored from plausibility.

0 Updated 1 weeks ago

MeeshaBear1