What you’ll be able to do

• Run Claude Code non-interactively in CI with -p (—print) so jobs don’t hang waiting for input
• Produce machine-parseable findings with —output-format json and —json-schema for posting as inline PR comments
• Provide project context to CI runs through CLAUDE.md: testing standards, fixtures, review criteria
• Avoid duplicate review comments and duplicate tests by putting prior findings and existing tests in context
• Explain why an independent review instance beats having the generating session review its own changes

What you need to know

Non-interactive mode: -p

By default Claude Code is interactive: it waits for a person to type, answer questions, and continue. A CI runner has no person. A job that starts Claude Code the interactive way can sit waiting for input until the pipeline times out. The -p flag (long form --print) runs Claude Code non-interactively. It takes the prompt, does the work, prints the result, and exits. Every automated invocation should use it.

Structured output CI can consume

A review that comes back as free-form prose is readable but awkward for a pipeline to use. To post findings as inline PR comments, the pipeline needs each finding's file, line, severity, and message as separate fields. Two CLI flags provide that:

• --output-format json returns the result as JSON instead of plain text.
• --json-schema supplies a JSON schema the structured output must conform to, so the shape of each finding is defined in advance.

Scraping free text with regular expressions breaks as soon as the wording changes. A schema gives the next pipeline step a predictable contract.

CLAUDE.md is how CI runs get project context

A CI-invoked run starts without anyone available to explain the project. The repository's CLAUDE.md is the mechanism for providing that context, and it loads automatically. Put in it what the CI tasks need:

• Review criteria — what counts as a reportable issue in this codebase and what doesn't, so reviews focus on real problems.
• Testing standards — what makes a test valuable here (behavior over implementation details, one behavior per test) and what isn't worth generating.
• Available fixtures — the factories and fixtures that exist, so generated tests use them instead of building their own setup.

When generated tests are low-value, such as trivial getter tests or hand-built setup that duplicates an existing fixture, the first fix is usually to document these standards and fixtures in CLAUDE.md.

Put what already exists in context

Two kinds of duplication show up quickly in CI, and both have the same cause: Claude doesn't know what already exists.

• Duplicate review comments. A review re-runs after every new commit. If each run starts from scratch, it reposts every finding from the previous run, including ones the author already fixed or replied to. The fix is to include the prior review findings in context and instruct Claude to report only issues that are new or still unaddressed.
• Duplicate test scenarios. Asked to generate tests for a module, Claude may suggest cases that the existing suite already covers. The fix is to provide the existing test files in context so it can see what's covered and add only what's missing.

Use an independent instance to review

It might seem efficient to have the session that wrote a change review it too. It isn't effective. The generating session carries its own reasoning: the assumptions it made, the approach it settled on, its belief that the code handles the edge case. Reviewing in that same context, it tends to confirm those decisions rather than question them. This is session context isolation: a separate, independent Claude Code instance that sees the diff and the review criteria, without the generator's reasoning, is much more likely to catch what the generator missed.

Key concept

In CI, -p prevents interactive hangs, and —output-format json with —json-schema produces findings a pipeline can post. CLAUDE.md supplies standards and fixtures, prior findings and existing tests prevent duplicates, and an independent instance does the reviewing.

When a scenario describes a CI job that hangs, look for -p. When it describes output that can't be posted as inline comments, look for --output-format json with --json-schema. When the same comments keep reappearing, look for missing prior findings.

Practice scenario

Build exercise — Build a schema-driven PR review step

Intermediate · 40 min

What you’ll learn

• Running Claude Code non-interactively with structured, schema-conformant output
• Feeding prior findings back in so re-runs report only new or unaddressed issues
• Separating generation from review with an independent instance

1. Write a JSON schema for review findings (file, line, severity, category, message) and run claude -p with --output-format json and --json-schema on a sample diff.

   • Why: -p keeps the run from waiting for input, and the schema gives the pipeline a stable contract to parse.
   • You should see: The command exit by itself and return JSON whose findings match your schema.

2. Make a follow-up commit that fixes one finding, then run the review again with the previous findings in the prompt and an instruction to report only new or still-unaddressed issues.

   • Why: Without the prior findings, every re-run starts fresh and reposts comments the author has already handled.
   • You should see: The fixed finding gone, the unaddressed ones kept, and no duplicates.

3. Have one session implement a small change and review it, then review the same diff with a fresh claude -p invocation.

   • Why: This shows the difference session context isolation makes.
   • You should see: The independent review flag at least as much as the self-review, and usually something the self-review accepted.

Exam traps

Invoking Claude Code in CI without -p, so the job hangs waiting for interactive input

-p (or --print) runs Claude Code non-interactively: it processes the prompt, prints the result, and exits.

Parsing free-form review text with regexes instead of requesting —output-format json with a —json-schema

The JSON output format with a schema produces machine-parseable findings that can be posted as inline PR comments reliably.

Re-running the full review after each push without prior findings, so the same comments are posted again

Include the prior findings and instruct Claude to report only issues that are new or still unaddressed.

Having the same session that generated the code review its own changes

The generating session’s reasoning biases its review toward confirming its own decisions. An independent review instance is more effective.

Generating tests without showing the existing test files, so it re-suggests scenarios already covered

Provide the existing test files in context so generation adds only what the suite is missing.

Leaving testing standards and available fixtures undocumented, then blaming the model for low-value tests

CLAUDE.md is how CI-invoked runs get project context. Documenting standards, valuable test criteria, and fixtures there improves the tests generated.

Sources

• Claude Code Docs
• Anthropic, Claude Certified Architect – Foundations Exam Guide v1.0 (July 2026)