Let Claude Manage Your Git Stashes with Descriptive Context
Git stash is powerful but its default UX is terrible — cryptic names like stash@{2} that tell you nothing about what's inside. Claude Code turns stashing into a workflow you can actually navigate.
Stash my current changes with a description of what I was working on.
Read the diff and write a meaningful stash message.
Claude reads your uncommitted changes, understands what you were doing, and stashes with a descriptive message:
git stash push -m "WIP: payment webhook retry logic — added exponential backoff, tests not passing yet"
Later, when you need to find and restore work:
List all my stashes and summarise what each one contains.
Which one has the webhook changes?
Claude runs git stash list, reads the diffs for each stash, and gives you a clear summary:
stash@{0}: "WIP: payment webhook retry logic" — 3 files changed in src/billing/
stash@{1}: "Experiment: Redis session driver" — config and session middleware changes
stash@{2}: "Quick fix: header alignment" — single CSS change in navbar component
Then apply the right one:
Apply stash@{1} — the Redis session experiment. Check if it conflicts with current changes.
Other stash workflows Claude handles well:
# Selective stashing
Stash only the changes in src/api/ — keep the test changes unstashed so I can keep working on them.
# Stash and switch
Stash my current work, switch to the hotfix branch, and remind me to pop the stash when I come back.
# Clean up old stashes
List all stashes older than a week. Show me what's in each one
so I can decide which to drop and which to apply.
# Partial apply
Apply the stash but only the changes to UserController.
Leave the rest in the stash.
Git stash without context is a graveyard of forgotten work — let Claude label what goes in and find what you need when it comes out.
via Claude Code
Log in to leave a comment.
Set up Claude Code as an automated reviewer in your CI pipeline — on every pull request, it reads the diff, checks for bugs, security issues, missing tests, and convention violations, then posts its findings as a PR comment. Your human reviewers get a head start because the obvious issues are already flagged before they look.
Before deploying, tell Claude to read your project — migrations, environment variables, queue workers, scheduled tasks, caching, third-party integrations — and generate a deployment checklist that's specific to your app. Not a generic "did you run migrations?" list, but one that knows YOUR infrastructure and catches the things YOUR deploy can break.
Instead of writing a README from memory or copying a template, tell Claude to read your project and generate one that's actually accurate — real setup instructions from your config, real architecture from your directory structure, real API examples from your routes, and real prerequisites from your dependency files.