git-investigate
Git Investigate Skill
Trigger
- Keywords: code history, git blame, track changes, who wrote this, when was it changed, root cause, code archaeology
When NOT to Use
- Code review (use codex-review)
- Feature development (use feature-dev)
- Just want to read code (use Read directly)
Command
/git-investigate src/service/xxx.ts:123 # Specific line
/git-investigate processToken # Function name
/git-investigate "error message" # Keyword
Workflow
Locate code -> git blame -> find commit -> trace history -> analyze changes -> report
Investigation Framework
| Question | Method |
|---|---|
| Who wrote it? | git blame |
| When was it changed? | git log --follow |
| Why was it changed? | commit message + PR |
| What was missed? | git diff compare original vs problematic version |
Common Patterns
| Pattern | Symptom | Root Cause |
|---|---|---|
| Type removed | Enum value deleted | Assumed no longer needed |
| Condition simplified | If conditions reduced | Missed during refactoring |
| Rename | Partially unchanged | Incomplete search-and-replace |
| Boundary ignored | Only handles main flow | Edge cases not considered |
Output
## Git Investigation Report
- **Target**: <file/feature>
- **Timeline**: <commit range>
- **Root cause**: <analysis>
- **Introduced by**: <commit hash + author>
Verification
- Report includes: investigation target, author info, timeline, original vs problematic code
- Root cause has clear analysis
- Fix recommendation is specific and actionable
References
references/commands.md- Git command reference + report template
Examples
Input: Who changed this line of code?
Action: git blame -> find commit -> trace PR -> output report
Input: When was this bug introduced?
Action: git log -p -S -> locate introduction point -> analyze cause -> output report
More from sd0xdev/sd0x-dev-flow
statusline-config
Customize Claude Code statusline. Use when: user says 'statusline', 'status line', 'customize statusline', 'modify statusline', 'statusline settings', 'statusline theme', 'change theme', 'color scheme', wants to add/remove/change segments (cost, git, model, context), switch color themes (catppuccin, dracula, nord), or asks what can be shown in the statusline.
52tech-spec
Tech spec generation and review. Use when: designing features, writing specs, spec review. Not for: requirements analysis (use req-analyze), implementation (use feature-dev), architecture advice (use codex-architect). Output: numbered tech spec document.
45codex-brainstorm
Adversarial brainstorming via Claude+Codex debate. Use when: exploring solutions, feasibility analysis, exhaustive enumeration. Not for: implementation (use feature-dev), architecture only (use codex-architect). Output: Nash equilibrium consensus + action items.
7security-review
Security review via Codex MCP. Use when: OWASP Top 10 audit, dependency vulnerability check, security-sensitive changes. Not for: code review (use codex-code-review), test review (use test-review). Output: security findings + audit report.
7test-review
Test coverage review via Codex MCP. Use when: reviewing test sufficiency, identifying coverage gaps, test quality audit. Not for: generating tests (use codex-test-gen), code review (use codex-code-review). Output: coverage analysis + gap report.
7post-dev-test
Post-development test completion. Use when: checking test coverage after feature-dev, writing missing integration/e2e tests. Not for: unit test generation (use codex-test-gen), test review (use test-review). Output: test files + coverage report.
6