Menü
Analyze git changes between branches and generate a changelog entry. Use when catching up on repo changes, after merges, or when asking "what's new in the codebase?"
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
| name | whats-new |
| description | Analyze git changes between branches and generate a changelog entry. Use when catching up on repo changes, after merges, or when asking "what's new in the codebase?" |
| context | main |
Analyze git changes and generate a changelog entry to help track what's new in the codebase.
/whats-new - Compare current branch to origin/master (default)/whats-new <branch> - Compare to a specific branch/whats-new --since "2 weeks ago" - Time-based comparisonParse the user's input to determine what to compare against:
HEAD to origin/masterHEAD to that branch--since provided: use time-based git logRun these commands to understand the changes:
# Fetch latest from remote
git fetch origin
# Get commit summary
git log --oneline HEAD..<target> 2>/dev/null || git log --oneline <target>..HEAD
# Get file change statistics
git diff --stat HEAD..<target> 2>/dev/null || git diff --stat <target>..HEAD
# Get list of new files
git diff --name-status HEAD..<target> 2>/dev/null | grep "^A" || git diff --name-status <target>..HEAD | grep "^A"
# Get list of modified files
git diff --name-only HEAD..<target> 2>/dev/null || git diff --name-only <target>..HEAD
For each significant area of change, provide architectural context:
Areas to analyze:
src/model/ - New data models, schema changessrc/service/ - New business logic, servicessrc/tasks/ - Celery tasks, background jobssrc/api/ - New endpoints, API changessrc/cli/ - New commands, CLI enhancementssrc/repository/ - Data access patternssrc/schema/ - Pydantic validation schemasetc/settings.toml - Configuration changesmigrations/ - Database migrationsFor each new file or significant change:
Create a markdown file at .notes/changelog/YYYY-MM-DD-<branch-name>.md with this structure:
---
date: YYYY-MM-DD
branch: <branch-name>
compared_to: <target-branch>
author: <from git log if available>
---
# <Branch Name> Changes
## Summary
<1-2 sentence overview of what this branch adds>
## New Capabilities
- <Capability 1>: Brief description
- <Capability 2>: Brief description
## New Files
### Models
| File | Purpose |
|------|---------|
| `src/model/example.py` | Description |
### Services
| File | Purpose |
|------|---------|
| `src/service/example.py` | Description |
### Tasks
| File | Purpose |
|------|---------|
| `src/tasks/example.py` | Description |
<... other sections as needed ...>
## Modified Files
- `path/to/file.py` - What changed and why
## New Patterns to Know
- **Pattern name**: Explanation of new pattern or convention introduced
- **Configuration**: Any new settings in `etc/settings.toml`
## New CLI Commands
```bash
# command - description
python -m src.cli <command>
| Method | Endpoint | Description |
|---|---|---|
| GET | /api/v1/... | Description |
migrations/versions/xxx_description.pypyproject.toml
### Step 5: Report Summary
After creating the changelog entry:
1. Display a brief summary to the user
2. Show the path to the created file
3. Highlight the most important things to know
## Output Location
All changelog entries go to: `.notes/changelog/`
Naming convention: `YYYY-MM-DD-<branch-name-slug>.md`
Examples:
- `2025-01-13-dmng-3-monitoring.md`
- `2025-01-10-dmng-2-data-model.md`
## Notes
- Always fetch from origin before comparing to ensure you have latest changes
- Focus on architectural significance, not just file listings
- Identify patterns that the user should adopt in future work
- If comparing to a branch that has YOUR changes (you're ahead), flip the comparison direction
- Keep the changelog entry focused and scannable
Route delegated work through the current host's supported sub-agent mechanism. In Pi, use the installed pi-subagents package. Use whenever the user asks for a subagent, Pi agent, Claude or Codex agent, or independent multi-agent work.
Launch both thermo-nuclear review subagents in parallel. Use for thermos, double thermo review, or combined bug/security and code-quality branch audits.
Run the CodeRabbit CLI for AI-powered review. Use only when the user explicitly asks for CodeRabbit or invokes coderabbit-review. Never trigger for a generic code review, PR review, quality check, security audit, or autonomously.
Use when reviewing implementation plans, migration plans, refactoring proposals, feature plans, generated implementation trackers, or committable phase plans before execution; especially when asked whether a plan is ready, concrete enough, testable, safe, or dependency-aware.
Use when creating, refining, or reviewing implementation plans, migration plans, refactoring proposals, feature plans, implementation trackers, or committable phase plans; especially when turning a rough plan into executable phases or checking whether a plan is concrete, testable, safe, dependency-aware, and suitable for parallel work.
Use this skill whenever the user gives a YouTube URL and asks to summarize, digest, analyze, extract transcript/context, decide whether a video is worth watching, or understand what a video is about. Prefer the summarize CLI for YouTube/video context instead of web search. Use Codex as the default summarize backend when possible, and use the local Whisper large-v3 model for transcription fallback. Do not use this for ordinary web pages; the user prefers Exa for webpage research.