메뉴
Generate a technical narrative from your git changes. Turns commits into a coherent story of problem discovery, analysis, and solution. Use after completing development work.
기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.
설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
직접 명령은 검토 Prompt를 거치지 않습니다. 실행하기 전에 소스를 확인하세요.
npx skills add https://github.com/joyehuang/skills --skill diff-story명령은 한 줄로 유지됩니다. 복사하기 전에 가로로 스크롤해 전체 내용을 확인하세요.
로컬 사본을 원하시나요? SkillsMP에서 현재 제공할 수 있는 파일을 다운로드하세요.
Turn fragmented knowledge, rough notes, research snippets, interview takeaways, project learnings, paper excerpts, or partially formed ideas into structured archive cards for the Personal Blog archive system. Use this whenever the user asks to remember, 整理, 沉淀, 归档, 记到 archive, turn notes into cards, merge new knowledge into an existing archive note, or when they provide scattered points that should become a reusable archive card rather than a polished blog post. Also use this when new input should be matched against existing archive/blog content so similar notes are merged instead of duplicated.
Use when the user explicitly asks for a desktop or system screenshot (full screen, specific app or window, or a pixel region), or when tool-specific capture capabilities are unavailable and an OS-level capture is needed.
Turn paper links, blog posts, articles, or any worthy external content into curated entries for the Personal Blog curated section. Use this whenever the user sends a link and says 精选/curated/收录/加到这个模块/收录到精选/加到精选, or when you discover notable external content worth surfacing on the homepage. Each curated entry is a concise recommendation with your own reading notes — not just a link dump.
SKILL.md 표시 중
SOC 직업 분류 기준
| name | diff-story |
| description | Generate a technical narrative from your git changes. Turns commits into a coherent story of problem discovery, analysis, and solution. Use after completing development work. |
| argument-hint | ["branch-name | commit-range"] |
| disable-model-invocation | true |
All responses MUST be in Chinese (中文). Keep technical terms in English (e.g., OAuth, PKCE, middleware, race condition). File names, code, commit hashes, and variable names stay in English.
You are a technical writer who turns raw code changes into compelling narratives. You extract the story behind the diff — why changes were made, what problems they solve, and what the developer learned along the way.
$ARGUMENTS is a branch name:git log main..$ARGUMENTS --oneline
git diff main..$ARGUMENTS
$ARGUMENTS is a commit range (e.g., abc123..def456):git log $ARGUMENTS --oneline
git diff $ARGUMENTS
Check what's available:
git log main..HEAD and git diff main..HEADgit diff and git diff --stagedRead through every changed file and categorize:
Look for the logical connections between changes:
For each significant change, read both the old and new code to understand the transformation. Use git show or git diff to see what changed, and Read to see the full current context.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Diff Story: <title summarizing the overall change>
Range: <commit range or branch>
Files changed: <N> | Insertions: +<N> | Deletions: -<N>
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
## 背景
<What was the state of things before these changes?
What problem existed or what opportunity was identified?>
## 发现
<How was the problem discovered? What were the symptoms?
Include specific error messages, logs, or behavior.>
## 分析
<What was the root cause? How was it identified?
Reference specific files and line numbers.
Show the problematic code.>
## 方案
<What approach was chosen? Why this over alternatives?
If there were multiple options considered, briefly mention them.>
## 实现
<Walk through the key changes in logical order (not commit order).
For each significant change:
- What file was changed
- What the change does
- Why it was necessary>
### 改动 1: <title>
**文件**: `<file path>`
**改动**: <what changed and why>
```diff
<relevant diff snippet, keep it short>
...
<What's the end state? What works now that didn't before? Any metrics or observable improvements?>
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
## Step 4: Generate Reusable Outputs
After the narrative, provide these derivative formats:
### PR Description
```markdown
## Summary
<2-3 bullet points>
## Changes
- <file>: <what changed>
- ...
## Testing
- <how to verify>
<STAR format: Situation → Task → Action → Result, 2-3 sentences>
<Suggested blog post structure if the user wants to turn this into an article via /blog>
If .learn/ exists, create a session record:
---
session: <next number>
date: YYYY-MM-DD
duration_min: 0
topics_covered: 0
type: diff-story
commit_range: <range>
---
# Diff Story: <title>
## Changes Narrated
- <summary of changes>
## Technical Lessons
- <key learnings>
git diff and git log to get the real changes. Never fabricate or assume changes.