Erk Diff Analysis

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

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