Context for CI Reviews and Test Generation: CLAUDE.md, Independent Reviewers, Re-runs

1.CLAUDE.md: the standing brief for every CI run

A CI run starts with no conversation history. The repository is the only place project knowledge can come from, and the project-level CLAUDE.md is how you provide it. It is checked in at ./CLAUDE.md or ./.claude/CLAUDE.md, and the docs say it is loaded into every session. The GitLab integration likewise says Claude follows your CLAUDE.md guidelines and existing code patterns. CLAUDE.md is not just for reviews: it is the project's shared instructions for every task, and a review also reads it as project context.

What should go in it? The best-practices guide's Include column lists testing instructions and preferred test runners. It also lists Bash commands Claude can't guess and common gotchas. Its Exclude column lists anything Claude can figure out by reading code. For test generation, this means writing down the knowledge Claude cannot infer:

- Testing standards: which runner to use and how to run a single test. - What makes a test worth writing: for example, "cover error paths, not trivial getters". - Available fixtures: which ones exist and where they live.

The docs do not name fixtures specifically. They fall under the same rule of including what Claude can't guess. The docs' own example is written as short, specific bullets:

# Workflow
- Be sure to typecheck when you're done making a series of code changes
- Prefer running single tests, and not the whole test suite, for performance

Keep it short. CI reads the file on every run, so every line costs tokens on every job, and the memory docs warn that long files reduce adherence. They suggest aiming for under 200 lines per file. Move conventions that apply only to part of the codebase, such as test-file rules, into path-scoped files under .claude/rules/. Those load only when Claude works with matching files.

Sources12345

2.Why the author session should not grade its own work

The session that wrote the code has its own reasoning, failed attempts and assumptions in context. The best-practices guide notes that long sessions with irrelevant context can reduce performance. It recommends a second opinion: a fresh model that tries to refute the result. Its Writer/Reviewer pattern makes this concrete:

In CI this separation is easy to get. A new claude -p invocation without --continue or --resume does not carry over an earlier conversation. Give it the diff and a reviewer role, and it judges the change on its merits:

gh pr diff "$1" | claude -p \
  --append-system-prompt "You are a security engineer. Review for vulnerabilities." \
  --output-format json

Sources4

3.Re-running a review after new commits

A review that runs again on every push has a duplication problem. A reviewer that starts fresh each time knows nothing about what it already posted, so it reports the same open issues again as new comments. The fix is to give the re-run the earlier findings and tell it to report only issues that are new, or that are still present and unaddressed.

The headless docs do not show this exact dedupe prompt, but they do provide two ways to bring earlier review state into a run. One is to resume the reviewer's own session by ID. --output-format json returns the session ID, and --resume continues that conversation:

session_id=$(claude -p "Start a review" --output-format json | jq -r '.session_id')
claude -p "Continue that review" --resume "$session_id"

The other is to pass the earlier findings in as input. If you saved the .structured_output from the last run, pipe it in alongside the new diff or load it with --append-system-prompt-file. Then give an explicit instruction, for example: "these were reported previously; report only new issues or ones still unaddressed." Resuming the *reviewer's* session is consistent with the previous section, because the reviewer stays independent of the author.

Sources67

4.Feeding existing tests into test generation

Test generation has its own version of the duplication problem. If Claude cannot see the current test suite, it will suggest scenarios the suite already covers. The best-practices guide gives you two ways to supply that context. You can pipe file contents in directly, as with cat file | claude -p "query". Or you can tell Claude to pull context itself using Bash commands, MCP tools, or by reading files. For example: "read tests/auth/ first, then add tests only for scenarios not already covered." The docs give no worked example of this deduplication, but both mechanisms are documented.

This works well alongside the guide's advice to provide verification criteria. Its example prompt lists concrete cases (user@example.com is true, invalid is false, user@.com is false) and asks Claude to run the tests after implementing. In CI, the existing test files show what is already covered, CLAUDE.md says what a valuable test looks like, and running the tests confirms the new ones pass.

Sources4

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.A longer, more exhaustive CLAUDE.md always improves CI output.Why is that wrong?

   Longer files consume more context on every run and reduce adherence. Keep CLAUDE.md concise and put area-specific rules in path-scoped files.

   Covered in CLAUDE.md: the standing brief for every CI run

2. 2.The session that wrote the code is the best reviewer because it already understands the change.Why is that wrong?

   The docs recommend a fresh model as a second opinion, so the agent that did the work is not the one grading it.

   Covered in Why the author session should not grade its own work

Practise it for real

Build a headless review step that an independent instance runs on a PR diff, with output a script can read

1. 1.Run: gh pr diff <number> | claude -p --append-system-prompt "You are a security engineer. Review for vulnerabilities." --output-format json

   Why: Piping only the diff into a fresh -p run gives you a reviewer that has no history with the author session

   You should see: A single JSON object is printed and the process exits without waiting for input

2. 2.Pipe the same command into jq -r '.session_id' and save the value

   Why: The session ID lets a later run carry this review's findings forward

   You should see: A session ID string

3. 3.After a new commit, run claude -p "Report only issues that are new or still unaddressed" --resume "$session_id" --output-format json

   Why: Giving the re-run its earlier findings prevents duplicate comments

   You should see: Findings limited to new or still-open issues

4. 4.Add --json-schema with a findings schema and extract the result with jq '.structured_output'

   Why: A schema gives a posting script a fixed shape to read

   You should see: A JSON value matching your schema, separate from the .result text