The crux of this post is not just "How do you pass Context between chats?", but also how do you ensure relevant context is provided and nothing more. There is no need to waste tokens.
For carrying out a technical review for every work package, i would like to open a new chat instead of keeping one huge thread open for days, my typical development cycle can last 6-7 days and runs across 25+ work packaged. What all should I add to the beginning of the chat for continuity. Is the 1st prompt enough or should I add the SRS and PRD and the original implementation plan or something else, or none of these
My Main Question --> When using Claude as a Reviewer, how do you review each Plan and execution on a separate chat?
Here is what Claude guides us to do
Short answer: the full SRS and PRD — no, not needed. The specific WP's approved implementation plan — yes, that's the one document that actually matters every time. Here's the breakdown of what's load-bearing versus what's just bulk.
Include every time
- The final approved implementation plan for that specific WP. This is the actual contract the code is being checked against — everything else is secondary to this. Attach it as a file.
- Repo access + exact branch/commit. State the branch name and current HEAD SHA up front, and confirm the repo is public (or however you're granting access). This alone would have saved several rounds of back-and-forth in this conversation.
- The
git add -N .step, stated as a given, not discovered. Just open with "diff generated viagit add -N . && git diff --binary --no-ext-diff" from message one. We only found this was necessary after two rounds of incomplete diffs — no reason to relearn that per WP. - A one-line list of what's already merged and proven, e.g. "WP-01A (outbox fencing, rate limiter, scheduler lock), WP-01B-1 (RBAC, session ambient-transaction guard), WP-01B-2a (sealed delivery, confirmation contexts) are merged and their patterns are the baseline to match." This is a cheap sentence that saves me from re-deriving "is this consistent with prior work" from scratch.
- The specific review ask, with this structure: numbered focus areas, the mandatory invariants unique to this WP, the Blocker/Important/Follow-up classification, and the exact verdict options. This has been doing real work — it's what keeps my reviews from wandering.
Don't bother re-attaching
- The full SRS or PRD. They're large, mostly stable between WPs, and pasting them wholesale risks me reasoning against a possibly-stale copy instead of the authoritative repo version. If a specific WP genuinely turns on an SRS clause, quote or link that one section instead.
- AGENTS.md / DECISION_LOG.md / the Technical Architecture doc, in full. These live in the repo and are the actual source of truth — if you give me a repo link (or raw file links, same pattern as the code), I can fetch the specific section I need rather than working from a copy you pasted that might already be one commit behind reality.
- Prior WPs' full review transcripts. The outcome of those reviews is now just... the merged code. I don't need the argument that got us there; I need the result, which is sitting in the repo.
One structural suggestion
Since AGENTS.md is apparently the living home for cross-WP invariants (transaction rules, fencing patterns, logging rules), it might be worth treating it as the one document that's always worth a fresh read at the start of each new WP chat — not because I need to be told about it, but because if it's been updated between WPs (which it should be, given how many corrections we've folded back into "the pattern" over this project), I want the current version, not my memory of an earlier one.
So, in practice: a short kickoff message (branch, HEAD, what's merged, the plan attached, the review ask) rather than a document dump. That's roughly the size of your very first message in this chat, just repeated per WP instead of accumulated.
No comments:
Post a Comment