Workflow Automation with Claude Code: Real-World Examples

Every developer has repetitive tasks they wish would just... disappear. The morning routine of checking PRs, updating dependencies, reviewing issues. The end-of-day ritual of committing, pushing, updating tickets.

Claude Code can automate these workflows. Not by replacing your judgment, but by handling the mechanical parts so you can focus on what matters.

This tutorial covers real-world workflow automation. Not toy examples—actual workflows used by development teams to save hours every week.

Understanding Workflow Automation

What Can Be Automated?

Good automation targets tasks that are:

• Repetitive: You do them multiple times per day/week
• Mechanical: They follow predictable patterns
• Low-risk: Mistakes are easily caught and fixed
• Time-consuming: They take meaningful time in aggregate

Bad automation targets:

• Creative decisions
• Security-sensitive operations
• One-time tasks
• Judgment calls

The Automation Spectrum

Manual ─────────────────────────────────────► Autonomous
   │                   │                  │
   │                   │                  │
Triggered          Assisted           Automatic
(you start it)   (AI helps)        (AI does it)

Most workflows fall in the middle—Claude helps but you stay in control.

Workflow 1: Morning Standup Prep

The Problem

Every morning, you need to:

1. Check what PRs need review
2. See what issues are assigned to you
3. Review CI/CD status
4. Catch up on Slack/team discussions
5. Plan your day

This takes 15-30 minutes of context-switching.

The Solution

Create a morning briefing skill that gathers everything in one place.

.claude/commands/morning.md:

---
description: Generate morning standup briefing
---

# Morning Standup Prep

When the user runs /morning, generate a comprehensive briefing for starting the day.

## Gather Information

### Git Status
1. Run `git status` to see local changes
2. Run `git log --oneline -5` to see recent commits
3. Check for unpushed commits

### GitHub PRs
1. List open PRs you authored: `gh pr list --author @me`
2. List PRs requesting your review: `gh pr list --search "review-requested:@me"`
3. For each, note: title, age, CI status, comments

### GitHub Issues
1. List assigned issues: `gh issue list --assignee @me`
2. List issues you're mentioned in: `gh issue list --search "mentions:@me"`

### CI/CD Status
1. Check recent workflow runs: `gh run list --limit 5`
2. Note any failures

## Generate Briefing

Format the output as:

Good morning! Here's your briefing for [DATE]:

Your PRs (need action)

• PR #123: "Add feature X" - 2 days old, CI passing, 1 comment awaiting response
• PR #456: "Fix bug Y" - Ready to merge

Reviews Requested

• PR #789: "New API endpoint" by @colleague - Requested yesterday

Your Issues

• #101: "Implement dashboard" - In Progress
• #102: "Update docs" - Todo

CI/CD Health

• All workflows passing ✓

Suggested Priority

1. Respond to comment on PR #123
2. Review PR #789
3. Continue work on #101

## Additional Context

If there's a `.claude/project-context.md` file, incorporate any project-specific context (sprint goals, upcoming deadlines, etc.).

Usage

/morning

Time saved: 15-20 minutes every morning.

Workflow 2: End-of-Day Wrap-up

The Problem

At day's end, you should:

1. Commit work in progress
2. Update issue status
3. Leave notes for tomorrow
4. Push changes

But it's easy to forget steps when you're tired.

The Solution

.claude/commands/eod.md:

---
description: End-of-day wrap-up routine
---

# End of Day Wrap-up

When the user runs /eod, help them wrap up their work day properly.

## Check Current State

1. Run `git status` to see uncommitted changes
2. Run `git stash list` to see any stashed work
3. Check what branch we're on

## Handle Uncommitted Work

If there are uncommitted changes:

### Option A: Changes are complete
- Help create a proper commit
- Push to remote

### Option B: Work in progress
- Create a WIP commit with clear message
- Example: "WIP: Dashboard component - filtering works, need to add sorting"
- Push to branch

### Option C: Changes should be stashed
- Stash with descriptive message
- Example: "WIP dashboard before switching to bugfix"

## Update Issues (if configured)

If the user has been working on a specific issue:
- Ask if they want to update the issue status
- Add a progress comment summarizing what was done

## Tomorrow's Context

Create/update `.claude/tomorrow.md` with:
- What was accomplished today
- Current blockers
- What to pick up tomorrow
- Any notes for context

## Checklist

Before finishing, verify:
- [ ] All meaningful changes committed
- [ ] Remote is up to date
- [ ] WIP is documented
- [ ] Tomorrow file updated

Output: "Day wrapped! See you tomorrow."

Usage

/eod

Time saved: Prevents forgotten commits, lost context, and morning confusion.

Workflow 3: Dependency Update Routine

The Problem

Dependencies need regular updates, but the process is tedious:

1. Check for outdated packages
2. Review changelogs for breaking changes
3. Update incrementally
4. Test after each update
5. Commit the changes

The Solution

.claude/commands/deps.md:

---
description: Safely update project dependencies
---

# Dependency Update Workflow

When the user runs /deps, systematically update dependencies.

## Phase 1: Discovery

1. Check package manager:
   - If `package.json`: use npm/yarn
   - If `requirements.txt`: use pip
   - If `Cargo.toml`: use cargo

2. List outdated packages:
   - npm: `npm outdated`
   - pip: `pip list --outdated`
   - cargo: `cargo outdated`

3. Categorize updates:
   - **Patch** (1.2.3 → 1.2.4): Usually safe
   - **Minor** (1.2.3 → 1.3.0): Generally safe, check changelog
   - **Major** (1.2.3 → 2.0.0): Breaking changes likely

## Phase 2: Safe Updates

Start with low-risk updates:

1. Update all patch versions
2. Run tests: `npm test` / `pytest` / `cargo test`
3. If tests pass, commit: "chore(deps): patch updates"
4. If tests fail, revert and note the problematic package

## Phase 3: Minor Updates

For each minor update:

1. Check the changelog/release notes
2. Look for deprecation warnings
3. Update the single package
4. Run tests
5. If pass, commit individually: "chore(deps): update [package] to [version]"
6. If fail, revert and document

## Phase 4: Major Updates

For each major update:

1. STOP and inform the user
2. Show the changelog highlights
3. List potential breaking changes
4. Ask for explicit approval before updating
5. If approved, update and test thoroughly
6. Document any migration steps taken

## Output Format

Dependency Update Report

Updated (safe):

• lodash: 4.17.20 → 4.17.21 (patch)
• axios: 0.21.0 → 0.21.4 (patch)

Updated (reviewed):

• react: 17.0.1 → 17.0.2 (minor) - no breaking changes

Needs Manual Review:

• webpack: 4.46.0 → 5.75.0 (major) Breaking changes: https://webpack.js.org/migrate/5/

Skipped (test failures):

• typescript: 4.5.4 → 4.9.4 - type errors in src/utils.ts

All tests passing: Yes/No Commits created: 3

Usage

/deps

Time saved: 30-60 minutes per update cycle, with fewer broken builds.

Workflow 4: PR Review Checklist

The Problem

PR reviews should be thorough, but it's easy to miss things:

• Security implications
• Test coverage
• Documentation updates
• Breaking changes

The Solution

.claude/commands/review-pr.md:

---
description: Comprehensive PR review checklist
arguments:
  - name: pr
    description: PR number to review
    required: true
---

# PR Review Workflow

When the user runs /review-pr [number], perform a comprehensive review.

## Fetch PR Information

1. Get PR details: `gh pr view [number]`
2. Get diff: `gh pr diff [number]`
3. Get PR comments: `gh pr view [number] --comments`
4. Check CI status: `gh pr checks [number]`

## Review Categories

### 1. Code Quality
- [ ] Code follows project style guide
- [ ] No obvious bugs or logic errors
- [ ] Error handling is appropriate
- [ ] No unnecessary complexity
- [ ] Comments explain "why", not "what"

### 2. Security
- [ ] No hardcoded secrets or credentials
- [ ] User input is validated/sanitized
- [ ] No SQL injection vulnerabilities
- [ ] Auth checks are in place where needed
- [ ] Sensitive data is not logged

### 3. Testing
- [ ] New code has tests
- [ ] Tests cover edge cases
- [ ] Tests are meaningful (not just for coverage)
- [ ] No flaky tests introduced

### 4. Documentation
- [ ] README updated if needed
- [ ] API changes documented
- [ ] Code comments for complex logic
- [ ] Migration steps if breaking changes

### 5. Performance
- [ ] No obvious performance issues
- [ ] Database queries are efficient
- [ ] No N+1 query patterns
- [ ] Large data sets handled properly

### 6. Compatibility
- [ ] Backward compatible (or breaking changes documented)
- [ ] Works across supported platforms
- [ ] No deprecated APIs used

## Generate Review

Format output as:

```markdown
## PR Review: #[number] - [title]

### Summary
[1-2 sentence summary of what this PR does]

### Recommendation: APPROVE / REQUEST_CHANGES / COMMENT

### Findings

#### Must Fix
- [Critical issues that must be addressed]

#### Should Fix
- [Important improvements recommended]

#### Consider
- [Nice-to-have suggestions]

#### Positive Notes
- [What's done well]

### Checklist Results
Security: ✓ Pass
Testing: ⚠ Needs attention - missing edge case tests
Documentation: ✓ Pass
Performance: ✓ Pass

Post Review

Ask if the user wants to:

1. Submit the review on GitHub
2. Add specific comments to lines
3. Approve/Request changes

### Usage

/review-pr 123

**Time saved:** Ensures consistent, thorough reviews. Catches issues before merge.

## Workflow 5: Release Preparation

### The Problem

Releases involve many steps:
1. Update version numbers
2. Generate changelog
3. Run full test suite
4. Build artifacts
5. Create release notes
6. Tag and push

Missing a step can cause production issues.

### The Solution

**.claude/commands/release.md:**

```markdown
---
description: Prepare a new release
arguments:
  - name: version
    description: Version number (e.g., 1.2.0)
    required: true
  - name: type
    description: Release type (major, minor, patch)
    required: false
---

# Release Preparation Workflow

When the user runs /release [version], prepare a release.

## Pre-flight Checks

1. Verify on main/master branch
2. Verify working directory is clean
3. Verify all tests pass
4. Check that CI is green

If any check fails, STOP and report the issue.

## Version Updates

1. Update version in:
   - package.json (Node.js)
   - setup.py / pyproject.toml (Python)
   - Cargo.toml (Rust)
   - Any other version files

2. Search for hardcoded versions that need updating

## Changelog Generation

1. Get commits since last release:
   `git log $(git describe --tags --abbrev=0)..HEAD --oneline`

2. Categorize commits:
   - **Features**: commits starting with `feat:`
   - **Bug Fixes**: commits starting with `fix:`
   - **Breaking Changes**: commits with `BREAKING:`
   - **Other**: remaining commits

3. Generate CHANGELOG.md entry:

```markdown
## [version] - YYYY-MM-DD

### Features
- Description of feature (#PR)

### Bug Fixes
- Description of fix (#PR)

### Breaking Changes
- Description of breaking change

### Other
- Other notable changes

Build & Test

1. Run full test suite
2. Build production artifacts
3. Run smoke tests on artifacts

If anything fails, STOP and report.

Create Release

1. Commit version changes: git commit -am "chore: release [version]"

2. Create annotated tag: git tag -a v[version] -m "Release [version]"

3. Show the user:

   • Changes that will be released
   • Tag that was created
   • Ask for confirmation before pushing

Post-Release (after confirmation)

1. Push commits: git push origin main
2. Push tag: git push origin v[version]
3. Create GitHub release: gh release create v[version] --notes-file RELEASE_NOTES.md

Output

Release Preparation Complete
============================

Version: 1.2.0
Commits included: 15
Features: 3
Bug fixes: 7
Breaking changes: 0

Files modified:
- package.json (version bump)
- CHANGELOG.md (new entry)

Tag created: v1.2.0

Ready to push? Awaiting confirmation...

### Usage

/release 1.2.0

**Time saved:** Prevents release mistakes. Ensures consistency.

## Building Your Own Workflows

### Step 1: Identify the Workflow

Document your current manual process:
1. What do you do step by step?
2. What decisions do you make?
3. What can go wrong?
4. What tools do you use?

### Step 2: Determine Automation Level

For each step, decide:
- **Automatic:** AI does it without asking
- **Assisted:** AI does it, shows results
- **Prompted:** AI asks before doing
- **Manual:** User does it themselves

### Step 3: Write the Skill

Use this template:

```markdown
---
description: [What this workflow does]
arguments: [Any parameters needed]
---

# [Workflow Name]

## Trigger
[When/how this runs]

## Steps
[Numbered list of what happens]

## Decision Points
[Where user input is needed]

## Error Handling
[What to do when things fail]

## Output
[What the user sees at the end]

Step 4: Test Incrementally

1. Test each step individually
2. Test the happy path
3. Test error cases
4. Test edge cases

Step 5: Refine Based on Usage

After using the workflow for a week:

• What steps are annoying?
• What's missing?
• What breaks?

Update the skill accordingly.

Combining Workflows

Workflows can build on each other:

## Daily Development Flow

/morning → Work → /commit → Work → /eod

## Weekly Maintenance Flow

/deps → /review-pr [all pending] → /release [if ready]

## Sprint Flow

Sprint Start: /sprint-setup
Daily: /morning, /standup, /eod
Sprint End: /release, /retro

Best Practices

1. Keep Workflows Focused

One workflow = one purpose. Don't combine "update deps" with "deploy to prod."

2. Make Workflows Idempotent

Running a workflow twice should be safe. Don't assume state.

3. Provide Escape Hatches

Always let users skip steps or abort the workflow.

4. Log Everything

Workflows should output what they're doing. Silent automation is scary automation.

5. Start Conservative

Begin with more prompts for confirmation. Remove them as trust builds.

Summary

Workflow automation with Claude Code transforms repetitive tasks into single commands. The key is identifying patterns in your work and encoding them as skills.

Start with one workflow. Refine it. Add another. Over time, you'll build a personalized automation suite that saves hours every week.

Quick Reference

---

Ready to automate testing specifically? Check out Test-Driven Development with Claude Code for TDD workflow automation.