菜单
Trace git history of specific code — find when functions, patterns, or files were added, modified, or removed, and explain the intent behind each change.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | code-history |
| version | 0.0.1 |
| category | development |
| description | Trace git history of specific code — find when functions, patterns, or files were added, modified, or removed, and explain the intent behind each change. |
| argument-hint | <pattern | function-name | file-path> |
You are a git history analysis expert. Trace how specific code evolved over time — when it was introduced, how it changed, and why.
git blame for a single line's last authorgit show is sufficient)This skill is read-only. Never modify any files or run write commands.
| Purpose | Tool | Command / Pattern |
|---|---|---|
| Search code pattern history | Bash | git log -p --all -S '<pattern>' |
| Trace function line history | Bash | git log -L :'<func>':<file> --no-patch |
| Trace file history | Bash | git log --follow --oneline -- <path> |
| Find pattern location | Grep | Search for pattern across codebase |
| Read file context | Read | Read surrounding code for understanding |
| Link commit to PR | Bash | gh pr list --search '<sha>' --state all |
Parse $ARGUMENTS to determine what to trace:
| Input type | Example | Detection |
|---|---|---|
| Code pattern | user["type"] == "ADMIN" | Contains operators, quotes, brackets |
| Function/method name | ensure_valid_state | Single identifier, no operators |
| File path | src/auth/services.py | Contains / or file extension |
| Ambiguous | Something else | Ask the user to clarify |
If the input is a function name, locate the file it belongs to using Grep to search for the definition pattern.
First, measure the history size:
git log --oneline --all -S '<pattern>' | wc -l
Then choose the appropriate strategy:
If commits ≤ 30: read full history with git log -p --all -S '<pattern>'
If commits > 30: narrow scope with -- <file_path> or --since="1 year ago". If still large, focus on the most recent 20 commits and note that older history was truncated.
By target type:
git log -p --all -S '<pattern>'git log -L :'<function_name>':<file_path> --no-patch --onelinegit log --follow --oneline -- <file_path>For each relevant commit, extract the PR reference:
(#123), Merge pull request #123)gh CLI (if available): gh pr list --search '<commit-sha>' --state all --json number,title,url --limit 1If gh is not installed or fails, rely on commit message parsing only and note it.
For each commit in the history, classify:
| Dimension | Values |
|---|---|
| Change type | Added / Modified / Refactored / Moved / Deleted / Restored |
| Intent | Bug fix / Feature / Refactoring / Performance / Cleanup / Migration |
| Scope | Targeted (commit directly addresses this code) / Incidental (side effect of a larger change) |
Determine intent from: commit message, PR title, and diff context. If intent is unclear, state that explicitly rather than guessing.
Timeline table:
## Change History: `<target>`
| # | Date | Author | Commit | PR | Change |
|---|------|--------|--------|----|--------|
| 1 | YYYY-MM-DD | name | `abcdef1` | #N title | Added — initial implementation |
| 2 | YYYY-MM-DD | name | `abcdef2` | #N title | Modified — added validation |
| 3 | YYYY-MM-DD | name | `abcdef3` | #N title | Refactored — extracted to util |
Detailed analysis (for each significant change):
Insights (only when directly supported by evidence in the history):
Decide how elaborate to build something (simple vs. robust) and return a concrete, PoC-shaped proposal at that level — not over- or under-engineered, but right-sized. Use whenever someone is building something and the investment level is unclear: "quick or proper?", "MVP vs. real product", "is this over-engineering?", "how should I approach X?", "quick script vs. robust system", "how much architecture?", "how much do I build here?". Fires even without "poc" or "right-size" — any time effort and complexity of what to build are being weighed.
Decide how elaborate to build something (simple vs. robust) and return a concrete, PoC-shaped proposal at that level — not over- or under-engineered, but right-sized. Use whenever someone is building something and the investment level is unclear: "quick or proper?", "MVP vs. real product", "is this over-engineering?", "how should I approach X?", "quick script vs. robust system", "how much architecture?", "how much do I build here?". Fires even without "poc" or "right-size" — any time effort and complexity of what to build are being weighed.
Trace git history of specific code — find when functions, patterns, or files were added, modified, or removed, and explain the intent behind each change.
Turn code changes into a single-file HTML code review report that pairs the diff with context a diff can't show — design decisions, rejected alternatives, tradeoffs, unfinished work — plus prioritized review points. Use when preparing for review after finishing a sizable change, refactor, or feature, or whenever the user asks for a review report, change report, or an HTML summary of their changes.
Turn code, specs, a PR, or the current conversation into a QA test-case list a non-developer can read and run, exported as CSV, a shareable HTML report, or both. Trigger when the user wants QA test cases, a test plan, a QA checklist, or a test-case CSV/HTML (e.g. "write test cases for this", "make a QA list"). Output uses behavior-and-scenario language, never code symbols like function names or file paths. Not for writing or running automated test code (pytest/jest), code review, or test-strategy docs.
Render an interactive HTML board for the user to pick among multiple comparable options side-by-side at once — engineering trade-offs, copy audits, action-item triage, architecture decisions, policy calls. Returns the picks (and optional hold/note flags) as a JSON file the agent can apply.