Use --print Mode to Integrate Claude Code into Shell Scripts and Pipelines
Most people use Claude Code interactively, but the --print (or -p) flag turns it into a non-interactive, one-shot tool that plays nicely with the rest of your terminal.
# Ask a question and get the answer straight to stdout
claude -p "What does the --frozen flag do in composer install?"
Because it writes to stdout and exits, you can pipe it into other commands or capture the output in a variable — just like any other CLI tool.
# Pipe a file in and get a summary back
cat src/OrderService.php | claude -p "Summarise this class in one paragraph"
# Generate a commit message from your staged diff
git diff --cached | claude -p "Write a concise commit message for this diff"
# Save the output to a file
claude -p "Write a .gitignore for a Laravel project" > .gitignore
You can combine it with --output-format json when you need structured data for downstream scripts, and --model to pick a specific model for cost control.
# Get structured JSON output for scripting
claude -p "List the public methods in this file as JSON" \
--output-format json < src/OrderService.php
# Use a cheaper model for simple tasks
claude -p "Explain this error" --model haiku < error.log
This pattern is especially powerful inside git hooks, Makefiles, and CI scripts where you need Claude's intelligence without an interactive session. Pair it with --allowedTools to let Claude read files or run commands in non-interactive mode.
Think of -p as the curl of AI — one line, one answer, done.
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.