How to Use Claude Code's /goal Command with Routines for Fully Autonomous Scheduled Workflows

Stop Babysitting Your Terminal

Most developers who discover Claude Code quickly hit the same wall: the tool is powerful, but it still requires you to be there. You type a prompt, watch it work, approve the next step, and repeat. That’s useful, but it’s not autonomous.

The /goal command combined with Claude Code routines changes that equation. Set a finish condition, wire up a routine, hand it to a cron schedule, and the whole thing runs without you — whether it’s a nightly report, a daily dependency audit, or a recurring code review pass. This guide walks through exactly how to build that setup from scratch, covering autonomous scheduled workflows in Claude Code with repeatable routines and goal-based completion logic.

What the /goal Command Actually Does

Claude Code supports custom slash commands — reusable instruction sets you define yourself and invoke with a / prefix during a session or in a non-interactive run. The /goal command isn’t a built-in; it’s something you create. That distinction matters, because it means you control exactly what it does.

When you define a /goal command, you’re giving Claude a structured way to:

1. Receive a specific, bounded objective at the start of a run
2. Understand what “done” looks like — so it stops when the work is finished rather than waiting for your input
3. Log or report its completion state in a machine-readable way

Other agents start typing. Remy starts asking.

YOU SAID "Build me a sales CRM."

REMY ASKS

01 DESIGN Should it feel like Linear, or Salesforce?

02 UX How do reps move deals — drag, or dropdown?

03 ARCH Single team, or multi-org with permissions?

Scoping, trade-offs, edge cases — the real work. Before a line of code.

The world's most powerful product manager agentTry Remy today

Without a defined finish condition, Claude Code in autonomous mode can loop indefinitely, ask questions you’re not around to answer, or stop too early because it ran out of obvious next steps. A /goal command solves the “what counts as done?” problem by encoding the answer upfront.

Custom Slash Commands in Claude Code

Claude Code reads custom slash commands from Markdown files stored in .claude/commands/ inside your project. Each file becomes a slash command with the same name as the file.

For example, a file at .claude/commands/goal.md becomes /goal inside any Claude Code session run from that project directory.

The file contains the instruction template. You can use $ARGUMENTS as a placeholder for anything you pass when invoking the command.

A minimal goal command file looks like this:

You are completing a bounded, autonomous task.

Your goal: $ARGUMENTS

Rules:
- Do not ask clarifying questions. Use your best judgment.
- When the goal is complete, output a single line: GOAL_COMPLETE: [brief summary]
- If you cannot complete the goal, output: GOAL_FAILED: [reason]
- Do not produce any output after the completion or failure line.

That’s the foundation. When you run /goal audit all TODO comments and open a GitHub issue for each one, Claude gets a clear objective and a defined exit signal.

Building Routines for Repeatable Work

A routine in Claude Code is a structured prompt — or sequence of prompts — that you want to run the same way every time. Routines live in one of two places:

• CLAUDE.md — the persistent instruction file Claude reads at the start of every session in your project
• .claude/commands/ — individual command files you invoke explicitly

The right choice depends on what you’re automating.

Using CLAUDE.md for Always-On Context

CLAUDE.md is read automatically at session start. Anything you put there applies to every run. This is the right place for standing instructions:

• What the project is and what it does
• Which files should never be modified
• What tools are available and preferred
• Output format preferences
• Safety constraints (e.g., “never commit directly to main”)

Think of CLAUDE.md as the briefing your autonomous agent gets before every shift. It doesn’t change per-run; it’s the stable context layer.

Using Command Files for Routine Tasks

For tasks you want to invoke explicitly — either manually or via a script — define them as command files. A routine for a nightly dependency check might look like this, saved at .claude/commands/dep-check.md:

Run a full dependency audit for this project.

Steps:
1. Run the appropriate package manager audit command (npm audit, pip-audit, etc.)
2. Parse the output and identify any HIGH or CRITICAL severity issues
3. For each issue found, create a summary entry in `reports/dep-audit-$(date +%Y-%m-%d).md`
4. If no issues found, write "No issues found" to the report file
5. Output: ROUTINE_COMPLETE: [N] issues found

Do not install any packages or make any changes. Audit only.

This gives Claude a repeatable, safe, scoped task with a clear output format. You can invoke it manually with /dep-check or call it programmatically in a script.

Running Claude Code Without You

For scheduled workflows, you need Claude Code to run without interactive input. There are two main approaches.

The —print Flag

Remy is new. The platform isn't.

Remy

Product Manager Agent

THE PLATFORM

200+ models 1,000+ integrations Managed DB Auth Payments Deploy

▮

BUILT BY MINDSTUDIO

Shipping agent infrastructure since 2021

Remy is the latest expression of years of platform work. Not a hastily wrapped LLM.

The world's most powerful product manager agentTry Remy today

The --print flag (or -p shorthand) puts Claude Code into non-interactive mode. It executes the prompt and exits. No follow-up questions, no waiting for input.

claude --print "Run /dep-check"

Or more explicitly:

claude -p "/goal audit all TODO comments and open a GitHub issue for each one"

When you use --print, Claude writes its output to stdout and exits with a zero status code on success. You can capture that output, pipe it to a log, or check it in a script.

Passing Commands as Arguments

You can also pass the full instruction directly:

claude --print --allowedTools "Bash,Read,Write,GitHub" \
  "Check all open pull requests for missing test coverage. Comment on any PR where test files were not updated alongside source changes."

The --allowedTools flag matters for autonomous runs. You’re telling Claude exactly which tools it’s allowed to use. Without this, it may prompt for permission at runtime — which breaks unattended execution.

Common tool names to whitelist depending on your task:

• Bash — run shell commands
• Read — read files
• Write — write files
• Edit — make targeted file edits
• GitHub — interact with GitHub APIs

Handling Permissions Without Prompts

Claude Code will sometimes pause to confirm before taking an action it considers risky. In a scheduled context, that pause means the run hangs.

To prevent this, use --dangerously-skip-permissions only in sandboxed or containerized environments where you’re confident about scope. For production use, prefer --allowedTools to limit what Claude can do, which reduces the number of confirmation prompts to near zero.

A safer pattern is to run scheduled Claude Code tasks inside a Docker container with read-only mounts except for specific output directories. That way, even if Claude does something unexpected, the blast radius is contained.

Setting Up the Cron Schedule

Once you have a working non-interactive command, wiring it to cron is straightforward.

Basic Cron Setup

Open your crontab with crontab -e and add a line like:

0 2 * * * cd /path/to/project && claude --print "/dep-check" >> /var/log/claude-dep-check.log 2>&1

This runs at 2:00 AM every day, in the project directory, and appends output to a log file.

Breaking it down:

• 0 2 * * * — run at 02:00 every day
• cd /path/to/project — change to the right directory so Claude finds .claude/ and CLAUDE.md
• claude --print "/dep-check" — invoke the routine
• >> /var/log/... — append stdout to a log
• 2>&1 — also capture stderr

Multi-Step Scheduled Workflow Example

Say you want a Monday morning workflow that:

1. Audits dependencies
2. Reviews open PRs for test coverage
3. Sends a Slack summary

You’d create a shell script:

#!/bin/bash
set -e

PROJECT_DIR="/path/to/project"
LOG_DIR="/var/log/claude-weekly"
DATE=$(date +%Y-%m-%d)

mkdir -p "$LOG_DIR"

cd "$PROJECT_DIR"

# Step 1: Dependency audit
echo "--- DEP AUDIT ---" >> "$LOG_DIR/$DATE.log"
claude --print "/dep-check" >> "$LOG_DIR/$DATE.log" 2>&1

# Step 2: PR review
echo "--- PR REVIEW ---" >> "$LOG_DIR/$DATE.log"
claude --print --allowedTools "Bash,GitHub,Read" \
  "/goal review all open PRs for test coverage gaps and comment on each with findings" \
  >> "$LOG_DIR/$DATE.log" 2>&1

# Step 3: Slack summary (using a separate tool or webhook)
echo "--- DONE ---" >> "$LOG_DIR/$DATE.log"

Then schedule it:

0 8 * * 1 /path/to/weekly-claude-run.sh

Runs at 8:00 AM every Monday.

Checking for Failures

Cron won’t alert you if something goes wrong by default. Add error notification by checking exit codes or parsing the log for your GOAL_FAILED: marker:

if grep -q "GOAL_FAILED" "$LOG_DIR/$DATE.log"; then
  mail -s "Claude routine failed" you@yourcompany.com < "$LOG_DIR/$DATE.log"
fi

Or pipe to a Slack webhook. The point is: define what failure looks like in your /goal command output, then check for it in your script.

A Complete Working Example

Here’s a full end-to-end setup for an autonomous nightly code quality check.

File Structure

myproject/
├── CLAUDE.md
├── .claude/
│   └── commands/
│       ├── goal.md
│       └── nightly-quality.md
└── scripts/
    └── nightly-claude.sh

CLAUDE.md

# Project Context

This is a Node.js API service. Main source files are in `src/`. Tests are in `test/`.

## Rules
- Never modify files in `node_modules/`
- Never commit directly. Use `git diff` to summarize changes only.
- Always prefer reading files before writing them.
- Output format for reports: Markdown, stored in `reports/`

.claude/commands/goal.md

You are completing a bounded autonomous task.

Goal: $ARGUMENTS

Instructions:
- Do not ask questions. Make reasonable assumptions.
- When complete, output exactly: GOAL_COMPLETE: [one-line summary]
- If you cannot complete it, output exactly: GOAL_FAILED: [reason]
- Nothing after the completion line.

.claude/commands/nightly-quality.md

Run a nightly code quality check on the `src/` directory.

Tasks:
1. Count all TODO and FIXME comments across all .js and .ts files
2. Identify any functions longer than 50 lines
3. Check for any console.log statements that weren't removed
4. Write a Markdown report to reports/quality-YYYY-MM-DD.md (use today's date)

Report format:
- ## Summary
- ## TODOs & FIXMEs (list with file:line)
- ## Long Functions (list with file, function name, line count)
- ## Leftover console.log (list with file:line)

After writing the report, output: GOAL_COMPLETE: quality report written to reports/

scripts/nightly-claude.sh

#!/bin/bash
set -e

PROJECT_DIR="/home/user/myproject"
LOG_FILE="/var/log/claude-nightly/$(date +%Y-%m-%d).log"
mkdir -p "$(dirname "$LOG_FILE")"

cd "$PROJECT_DIR"

echo "[$(date)] Starting nightly quality check" >> "$LOG_FILE"

claude --print \
  --allowedTools "Bash,Read,Write" \
  "/nightly-quality" >> "$LOG_FILE" 2>&1

if grep -q "GOAL_FAILED" "$LOG_FILE"; then
  echo "[$(date)] FAILURE detected" >> "$LOG_FILE"
  # Add alerting here
fi

echo "[$(date)] Run complete" >> "$LOG_FILE"

Crontab Entry

30 1 * * * /home/user/myproject/scripts/nightly-claude.sh

That’s a complete autonomous workflow running at 1:30 AM every night, producing structured reports, with failure detection — and zero human involvement after setup.

Where MindStudio Fits In

Claude Code’s approach is powerful but code-first. You need to manage scripts, cron entries, file permissions, and log parsing yourself. For developers who are comfortable there, that’s fine.

But if you want to run autonomous scheduled agents without writing shell scripts or touching cron — or if you want to chain AI tasks across multiple models, tools, and integrations without infrastructure overhead — MindStudio is worth looking at.

Plans first. Then code.

PROJECTYOUR APP

SCREENS12

DB TABLES6

BUILT BYREMY

1280 px · TYP.

yourapp.msagent.ai

A · UI · FRONT END

Remy writes the spec, manages the build, and ships the app.

The world's most powerful product manager agentTry Remy today

MindStudio lets you build autonomous background agents that run on a schedule, with no cron setup required. You can define what the agent does, what tools it can access (Slack, GitHub, Google Workspace, Airtable, and 1,000+ others), and when it runs — all through a visual builder. The scheduling, retries, logging, and error handling are handled for you.

For teams that want the same “set a goal, let it run” behavior that the /goal-plus-cron pattern gives you in Claude Code, MindStudio provides that as a managed service. You’re not managing a script that calls an AI; you’re building an agent that runs as infrastructure.

If you’re already using Claude Code for development tasks and want to extend automation into business workflows — report generation, data syncing, content pipelines — MindStudio’s scheduled background agents are the natural companion layer. You can try it free at mindstudio.ai.

For teams exploring what broader AI workflow automation looks like beyond the terminal, MindStudio’s approach to building AI agents without code is a useful contrast to the Claude Code approach covered here.

Common Mistakes and How to Avoid Them

Claude Hangs Waiting for Input

This almost always means a permission prompt triggered at runtime. Fix it by narrowing --allowedTools so Claude doesn’t attempt actions outside your approved list. The more specific you are, the fewer prompts you’ll hit.

The Cron Job Doesn’t Find Claude

Cron runs with a minimal environment. The claude binary might not be in cron’s $PATH. Solve this by using the full path to the binary:

30 1 * * * /usr/local/bin/claude --print "/nightly-quality"

Find the full path with which claude in your terminal.

CLAUDE.md Isn’t Being Read

Claude Code looks for CLAUDE.md relative to the working directory. If your cron job doesn’t cd into the project directory first, Claude won’t find it. Always include cd /path/to/project && before the claude command.

The Routine Runs Too Long

Autonomous runs without time limits can cause problems — runaway API costs, processes that block the next scheduled run, or task drift. Set a timeout using the system timeout command:

timeout 300 claude --print "/nightly-quality"

That hard-kills the process after 5 minutes. Adjust based on your expected task duration.

Output Gets Too Long to Parse

If Claude’s output is verbose, log parsing gets messy. Enforce output discipline in your /goal and routine command files. The GOAL_COMPLETE: and GOAL_FAILED: markers work precisely because they’re grep-able. Keep that pattern consistent across all your command files.

Frequently Asked Questions

What is the /goal command in Claude Code?

The /goal command is a custom slash command you create in Claude Code by adding a Markdown file to .claude/commands/goal.md. It gives Claude a structured way to receive a bounded objective and know when it’s finished, which is essential for autonomous runs where no human is present to provide feedback.

Can Claude Code run unattended without any human input?

Yes. Using the --print flag (or -p), Claude Code runs in non-interactive mode, executes the prompt, and exits. Combined with --allowedTools to prevent permission prompts, it can run fully unattended in a cron job or CI pipeline.

What are routines in Claude Code?

The free Hermes Agent crash courseReserve your spot →

Routines are repeatable instruction sets defined as Markdown files in .claude/commands/. Each file becomes a slash command. Routines let you define the steps, constraints, and output format for recurring tasks once, then invoke them consistently every time — manually or via script.

How do I schedule Claude Code to run on a cron schedule?

Add a crontab entry that changes to your project directory and calls claude --print with your routine or goal. Use the full path to the claude binary since cron has a minimal $PATH. Redirect output to a log file for auditing and add grep-based failure detection to alert you when something goes wrong.

How do I prevent Claude Code from going over budget in scheduled runs?

The most reliable controls are: (1) use --allowedTools to limit what Claude can do, (2) wrap the call in timeout to cap run time, and (3) define narrow, specific goals so Claude doesn’t wander into adjacent tasks. For API cost tracking, check Anthropic’s usage dashboard and set usage limits there.

Can I chain multiple Claude Code routines in a single scheduled run?

Yes. Write a shell script that calls claude --print multiple times sequentially, each with a different routine or goal. Check the exit code or log output between calls to decide whether to proceed. This is the simplest way to build multi-step autonomous workflows with Claude Code.

Key Takeaways

• The /goal command is a custom slash command you define in .claude/commands/goal.md — it sets a bounded objective and a clear finish condition for autonomous runs.
• Routines live in .claude/commands/ as Markdown files and become invokable slash commands. CLAUDE.md handles the persistent context layer.
• The --print flag and --allowedTools are what make Claude Code safe to run unattended — the first enables non-interactive mode, the second prevents runtime permission prompts.
• Wrap scheduled runs in shell scripts that handle logging, timeouts, and failure detection. Don’t rely on cron alone.
• MindStudio offers an alternative path for teams that want scheduled autonomous agents without managing scripts, cron, or infrastructure — useful for extending AI automation beyond the development workflow.

If you’re building scheduled automation with Claude Code, the setup described here gives you a solid, production-ready foundation. And if you find yourself wanting to extend that automation into broader business workflows — or hand it off to non-developers — MindStudio is a practical next step.