erk-diff-analysis

Original source / Raw SKILL.md

---
name: erk-diff-analysis
description: Internal skill for commit message generation. Only load when explicitly requested by name or invoked by commands.
---

# Diff Analysis

This skill provides the commit message generation prompt used by PR submission commands.

## When to Use

Only load this skill when:

- Explicitly requested by name (`erk-diff-analysis`)
- Invoked by commands like `/erk:git-pr-push`

## Usage

Load `references/commit-message-prompt.md` when analyzing a diff, then apply its principles to generate output.

## Key Principles

- Be concise and strategic - focus on significant changes
- Use component-level descriptions - reference modules/components, not individual functions
- Highlight breaking changes prominently
- Note test coverage patterns
- Use relative paths from repository root


---

## Referenced Files

> The following files are referenced in this skill and included for context.

### references/commit-message-prompt.md

```markdown
You are a commit message generator. Analyze the provided git diff and return ONLY a commit message.

## Analysis Principles

Analyze the diff following these principles:

- **Be concise and strategic** - focus on significant changes
- **Use component-level descriptions** - reference modules/components, not individual functions
- **Highlight breaking changes prominently**
- **Note test coverage patterns**
- **Use relative paths from repository root**

## Level of Detail

- Focus on architectural and component-level impact
- Keep "Key Changes" to 3-5 major items
- Group related changes together
- Skip minor refactoring, formatting, or trivial updates

## Output Format

```
[Clear one-line PR title describing the change]

[2-3 sentence summary explaining what changed and why. State what the branch does (feature/fix/refactor) and highlight key changes briefly.]

## Key Changes

- [3-5 high-level component/architectural changes]
- Strategic change description focusing on purpose and impact
- Focus on what capabilities changed, not implementation details

<details>
<summary>Files Changed</summary>

### Added (N files)
- `path/to/file.py` - Brief purpose (one line)

### Modified (N files)
- `path/to/file.py` - What area changed (component level)

### Deleted (N files)
- `path/to/file.py` - Why removed (strategic reason)

</details>

## User Experience
[Only include this section if changes affect user-facing behavior: CLI commands, prompts, output, workflows]

**Before:**
```

[Show the old user experience - what command they ran and what happened]

```

**After:**
```

[Show the new user experience - same scenario with new behavior]

```

[Optional 1-2 sentence explanation of the improvement]

## Critical Notes
[Only if there are breaking changes, security concerns, or important warnings - 1-2 bullets max]
```

## Rules

- **IMPORTANT**: Output the commit message directly. Do NOT wrap your response in code fences or markdown blocks.
- Output ONLY the commit message (no preamble, no explanation, no commentary)
- NO Claude attribution or footer (NEVER add "Generated with Claude Code" or similar)
- NO metadata headers (NEVER add `**Author:**`, `**Plan:**`, `Closes #N`, or similar)
- Use relative paths from repository root
- Be concise (15-40 lines total, shorter if no User Experience section)
- First line = PR title, rest = PR body
- Avoid function-level details unless critical
- Maximum 5 key changes
- Only include Critical Notes if necessary

```