Running Claude in a pipeline

Claude is normally interactive: it asks, you answer. A build pipeline has nobody at the keyboard, so a step that pauses for input just hangs until it times out. Running it unattended is a different shape of job, and three things have to change.

Common questions

1. What does running it one-shot actually mean?
   Prompt in, result out, no conversation in the middle. It does the work once, prints the result and exits, with nobody needing to be there. The guarantee is non-interactive rather than background: it might run in the background, and that is incidental.
2. Why can a pipeline not just use the normal interactive mode?
   Because there is no human to answer. Interactive is fine with a person at the keyboard, but a pipeline that pauses for input would hang the whole build until it timed out, waiting on a question nobody is there to answer.
3. How do I get output a script can actually use?
   Ask for data rather than prose. That is the make-it-machine-readable switch, and it lets a downstream step work with the result directly, piping it into a request body instead of parsing sentences.
4. Data is not enough on its own. What else?
   Pin it to a shape. Without that you can get valid data shaped differently each run. With it, the keys the next step expects are guaranteed to be there every time, which is what makes the pipeline safe rather than lucky.
5. If nobody is there, where does the project knowledge come from?
   The project memory file, auto-loaded from the repo exactly as it is interactively. The prompt on the command line is still the task, like review this diff. The memory file is the standing knowledge that short prompt is leaning on without spelling out.
6. Why not just put the standards in the prompt?
   Three reasons. It keeps the prompt tiny instead of cramming every standard onto one command line, it is versioned with the code so every run picks up the same standards, and it is the only channel for that knowledge when there is no human to add it.
7. CI re-ran and posted all the same comments again. Why?
   A fresh session has no memory of the last run, so it re-posts everything and buries whatever is genuinely new. Nothing is broken, it simply does not know what has already been said.
8. So how do I stop the duplicates?
   Two parts, and the context alone is not enough. Hand it what has already been flagged, from the previous run, a document or an issue tracker. Then explicitly tell it to report only what is new or still unaddressed.
9. Does the same trick work for generated tests?
   Yes, with a different source of already-covered. Give it the existing test files, so it writes only the tests that fill the gaps rather than duplicating scenarios the suite already has.
10. How does a finding end up on the right line of a pull request?
    By coming back as fields rather than sentences: which file, which line, what the issue is, and how severe. Prose cannot be placed reliably, because the script would have to guess where each note belongs.

Back to Ways to run it for real. The craft around it is Working with AI.