Skip to content
Datfx Labs Claude Guide

Automation Workflows

The default mental model for Claude Code is on-demand: you summon it, it works, you review the result. This is useful but limited. It still requires you to initiate every task.

The automation model is different. Claude runs on a schedule, watches for conditions, and acts without being asked. You set it up once and it runs in the background — checking PRs, monitoring tests, generating reports, updating dependencies — while you work on something else.

/loop handles local recurring tasks. /schedule handles cloud-based scheduled tasks. Together they turn Claude from an assistant into a persistent background worker.

The Automation Mental Model

Think of /loop and /schedule the same way you think of a cron job or a GitHub Actions workflow — except the “script” is written in natural language and Claude handles the implementation details.

Traditional automation:
  Write bash script → test it → schedule with cron → maintain it


Claude automation:
  Write task description → Claude executes it on schedule → review outputs

The tradeoff: Claude automation is more flexible and requires less scripting, but costs tokens per run. For tasks that run frequently (every few minutes), traditional scripts are more economical. For tasks that require judgment or produce varied outputs, Claude automation is often better.

/loop — Local Recurring Tasks

/loop runs a Claude task repeatedly at a fixed interval on your local machine. Claude executes the task, waits the interval, executes again, indefinitely.

Terminal window
# Basic syntax
/loop [interval] [task description]


# Examples
/loop 30m "check for new PR comments on my open PRs"
/loop 1h "run the test suite and report any new failures"
/loop 6h "check the status API and update the local cache file"

See /advanced/loop for the full reference including pause, resume, and output configuration.

Loop Template 1: PR Review Comment Monitor

Keep up with review feedback without checking GitHub manually.

/loop 30m "Check for new PR review comments on my open PRs.
For each new comment since the last check:
1. Read the comment and the code it references
2. Determine if it requires a code change, a response, or just acknowledgment
3. If it requires a code change: open the relevant file and make the change,
   then run the tests for that file
4. If it requires a response: draft a reply and show it to me for approval
5. Log all processed comments to .claude/pr-monitor.log with timestamp"

This loop does triage for you. By the time you check the log, straightforward review fixes are already made.

Loop Template 2: Continuous Test Watch

More targeted than a file watcher — Claude interprets failures and attempts fixes.

/loop 1h "Run the full test suite with: npm test -- --reporter=json > .claude/test-results.json 2>&1


After running:
1. Compare results to .claude/test-results-previous.json (if it exists)
2. Identify any tests that newly failed (were passing before, failing now)
3. For each newly failing test:
   - Read the test file and the source file it tests
   - Determine likely root cause
   - If the fix is obvious and low-risk (< 10 lines changed): make the change
   - If the fix is uncertain: log the failure with analysis to .claude/test-failures.md
4. Move current results to .claude/test-results-previous.json"

Loop Template 3: External API Status Cache

Keep a local cache of an external service’s status without polling it from application code.

/loop 6h "Fetch the status from https://api.example.com/health and
https://api.example.com/v2/limits


Write the results to public/api-status.json in this format:
{
  'lastChecked': ISO timestamp,
  'health': the health response body,
  'limits': the limits response body,
  'degraded': true if health.status is not 'ok'
}


If the fetch fails, do not overwrite the existing file — instead append
an error entry to .claude/api-status-errors.log"

Loop Template 4: Morning Commit Summary

Start each day knowing what changed across all your repos.

/loop 24h at 08:00 "For each repository listed in .claude/repos.txt:
1. Run: git log --oneline --since='24 hours ago' --all
2. Summarize the commits in plain English — what features landed, what was fixed
3. Flag any commits with 'hotfix', 'revert', or 'breaking' in the message


Write the summary to .claude/daily-summary-{YYYY-MM-DD}.md
Print a one-paragraph version to stdout so it appears in the terminal"

Stopping Loops Safely

Terminal window
# List running loops
/loop list


# Stop a specific loop by ID
/loop stop [loop-id]


# Stop all loops
/loop stop --all


# Pause temporarily (resumes automatically after duration)
/loop pause [loop-id] 2h

Cost Estimation

Before running a loop continuously, estimate the token cost:

Tokens per iteration × iterations per day × cost per 1K tokens = daily cost


Example:
  PR monitor loop: ~2,000 tokens/run × 48 runs/day × $0.003/1K = $0.29/day
  Test watch loop: ~5,000 tokens/run × 24 runs/day × $0.003/1K = $0.36/day

Loops that run every 5 minutes at 3,000 tokens each cost ~$25/day. Set intervals that match the actual latency requirements of the task.

/schedule — Cloud Tasks

/schedule runs tasks in Vercel’s cloud infrastructure on a cron-style schedule. Unlike /loop, scheduled tasks run even when your laptop is closed or offline.

Terminal window
# Basic syntax
/schedule "[cron expression]" "[task description]"


# Examples
/schedule "0 9 * * 1" "analyze merged PRs from last week"
/schedule "0 8 * * *" "check for outdated npm dependencies"

See /advanced/schedule for full configuration, output routing, and error handling.

Schedule Template 1: Weekly PR Analysis

Every Monday at 9am, get a structured view of last week’s work.

/schedule "0 9 * * 1" "Analyze all PRs merged to main in the past 7 days.


For each PR:
- Title and number
- Author
- Lines changed
- Which area of the codebase (infer from files changed)
- Any PRs that were reverted or followed up on


Produce two outputs:
1. A markdown report at reports/weekly-pr-analysis-{date}.md
2. A one-paragraph executive summary posted to the #engineering Slack channel
   via the webhook at env.SLACK_WEBHOOK_URL"

Schedule Template 2: Dependency Patch Automation

Run daily. When patch-level updates are available, create the PRs automatically.

/schedule "0 7 * * *" "Check for outdated npm dependencies using: npm outdated --json


For each package with a patch-level update available (e.g., 1.2.3 → 1.2.4):
1. Update the package: npm install {package}@{new-version}
2. Run: npm test
3. If tests pass: create a PR titled 'chore: update {package} to {new-version}'
4. If tests fail: log the failure to dependency-updates.log but do not create a PR


Do not update minor or major versions — patch only.
Do not update more than 5 packages per day."

Schedule Template 3: Weekly Codebase Health Report

Track technical debt trends over time.

/schedule "0 10 * * 1" "Generate a weekly codebase health report.


Metrics to collect:
- Total TypeScript errors: npx tsc --noEmit 2>&1 | grep 'error TS' | wc -l
- Total ESLint warnings: npm run lint -- --format json | jq '.[] | .warningCount' | awk '{s+=$1} END {print s}'
- Test coverage: npm test -- --coverage --json | jq '.coverageMap' (extract line coverage %)
- Largest files: find src -name '*.ts' -o -name '*.tsx' | xargs wc -l | sort -n | tail -10
- TODO count: grep -r 'TODO\|FIXME\|HACK' src --include='*.ts' --include='*.tsx' | wc -l


Compare to last week's report in reports/health/.
Highlight metrics that got worse by more than 5%.
Save to reports/health/health-{date}.md"

Schedule Template 4: Sprint Release Notes

At the end of each sprint, generate release notes from merged PRs.

/schedule "0 17 * * 5" "Generate release notes for this sprint.


Fetch all PRs merged to main since last Friday using the GitHub API.
Group them by label: feat, fix, chore, docs, breaking.


Format:
## Release Notes — Sprint ending {date}


### New Features
- [PR title] (#number)


### Bug Fixes
- [PR title] (#number)


### Breaking Changes
- [PR title] (#number) — describe the breaking change


### Other Changes
- [count] dependency updates, documentation improvements, refactors


Save to docs/release-notes/{date}.md and post to #releases Slack channel."

Combining Loops with Hooks

Loops become more powerful when connected to Claude’s hook system. A loop can detect a condition and trigger a hook action.

/loop 15m "Check if the main branch CI status is failing.


Run: gh run list --branch main --limit 5 --json status,conclusion,headSha


If any of the last 5 runs have conclusion='failure':
1. Get the failure details: gh run view {run-id} --log-failed
2. Identify which test or build step failed
3. Check if this is a known flaky test (compare against .claude/known-flaky-tests.txt)
4. If it's a new failure:
   - Open the relevant source file
   - Attempt a fix if the cause is clear
   - If not clear: post the failure summary to .claude/ci-alert.md and
     trigger: notify 'CI failing on main — needs attention'"

Safety: Scoping Automated Actions

When Claude runs unattended, limit what it can do without your approval.

# In your loop/schedule prompts, be explicit about permission levels:


High-confidence, auto-proceed:
- Reading files and generating reports
- Running tests (read-only operations)
- Creating new files in designated directories
- Opening PRs (does not merge automatically)


Requires your approval before proceeding:
- Merging PRs
- Deleting files
- Modifying files outside the designated scope
- Any git push to main
- Any external API calls that write data


When uncertain: log what you would do and wait for confirmation."

This is the principle behind Boris’s /careful hook — automated agents should operate in a bounded permission envelope, not with full authority.

Loop Lifecycle

graph LR A[/loop starts] --> B[Claude executes task] B --> C[Output logged] C --> D[Wait interval] D --> B B --> E{Error?} E -->|recoverable| F[Log error, continue] F --> D E -->|fatal| G[Loop paused, notify user] style A fill:#1e293b,color:#7dd3fc,stroke:#334155 style B fill:#1e293b,color:#7dd3fc,stroke:#334155 style C fill:#1e293b,color:#7dd3fc,stroke:#334155 style D fill:#1e293b,color:#7dd3fc,stroke:#334155 style E fill:#1e293b,color:#fcd34d,stroke:#334155 style F fill:#1e293b,color:#fcd34d,stroke:#334155 style G fill:#1e293b,color:#86efac,stroke:#334155
  • /advanced/loop — full loop reference: syntax, output routing, state persistence
  • /advanced/schedule — full schedule reference: cron syntax, cloud setup, error handling
  • Hooks — the automation primitives that /careful and condition-triggered actions use
  • Verification-First — why verification commands make automation safe