How engineering teams use Claude Cowork for architecture reviews — AI that reads your existing ADRs, identifies design gaps, and produces structured RFC feedback in minutes.
Architecture reviews are high-stakes, time-consuming, and often skipped or rushed. Most engineering teams have good intentions around Architecture Decision Records (ADRs) and Request for Comments (RFC) processes, but the documentation burden and coordination overhead mean they don't happen consistently. Teams end up making significant design decisions in Slack threads or without proper peer review. Cowork changes the economics of architecture review.
In our full guide to Claude Cowork for software developers, we cover how Cowork fits into your development workflow. This article focuses specifically on architecture reviews — how to load your existing ADRs and system topology into Cowork, run a structured design review with Claude, and ship a formal ADR from the session without ever leaving the canvas.
Cowork isn't a chat tool for architecture — it's a workspace that holds your design context. That distinction matters.
Multi-file context. Cowork loads your existing ADRs, architecture diagrams (as descriptions), system topology documentation, and the new proposal simultaneously. You're not copy-pasting snippets into a chat. The entire architectural history is live in the canvas, available for Claude to reason about.
Consistency checking. Cowork identifies when a new design conflicts with previous architectural decisions. If a proposal violates a pattern established in ADR-005, Cowork flags it — with a reference back to the original decision. This catches design drift before it ships.
Structured output. Cowork generates RFC feedback in your team's format — not a chat response, but a numbered findings document with severity levels, references to existing decisions, and suggested alternatives. You can export this directly to your design doc or RFC process.
Knowledge retention. Your architecture docs stay loaded in the canvas workspace. Cowork builds on them every session. Run a review Monday, then Tuesday load the same canvas and ask Cowork to draft the ADR from the approved design. The context persists.
Export your existing ADRs, system topology diagram (as markdown or plaintext), architecture decision registry, and system boundaries document. Paste them all into a new Cowork canvas. This is your source of truth for the session.
Paste the RFC draft, design doc, whiteboard notes, or API specification you're reviewing. Cowork now has both the existing architecture and the new design in the same workspace.
Use a structured prompt to ask Cowork to identify conflicts with existing patterns, missing security considerations, performance implications, and deviations from team norms. Cowork produces a findings list with severity and references.
Cowork produces numbered findings (Critical, Major, Minor) with references to existing decisions and suggested alternatives. This document becomes your review feedback — for the RFC, design doc, or team discussion.
If the proposal is approved, ask Cowork to draft the formal ADR from the review discussion. Include decision rationale, alternatives considered, and consequences. Export and add to your ADR registry.
Copy these prompts into Cowork to structure your reviews:
Review this new [design/RFC/API spec] against our existing ADRs and architecture.
For each significant design decision in the proposal:
1. Check if it aligns with existing architectural patterns (ref: ADR numbers)
2. Flag conflicts with previous decisions
3. Identify missing security considerations given our system topology
4. Note performance implications relative to our scale
5. List deviations from team conventions
Output:
- CONFLICTS: [ADR ref + conflict description]
- GAPS: [missing consideration + why it matters]
- NORMS: [deviation from existing pattern + severity]
- Questions for the proposerGenerate structured RFC review feedback for this proposal.
Format:
**CRITICAL (blocks approval):**
- [finding] (reference: ADR-XXX)
- [suggested alternative]
**MAJOR (should address before approval):**
- [finding]
- [suggested alternative]
**MINOR (good to consider):**
- [finding]
- [suggested alternative]
Include: rationale for each severity level, reference to existing decisions, impact on dependent systems.Write an ADR for this approved design. Follow our ADR template:
Title: [brief decision title]
Status: Accepted
Context: [why we're making this decision]
Decision: [what we decided]
Rationale: [why this is the best approach given our constraints]
Alternatives Considered: [what else we looked at and why we rejected it]
Consequences: [short-term and long-term impacts]
Related ADRs: [links to related decisions]The review breaks down into three phases:
Pre-review: 30 min (schedule, prep docs, send context)
Review meeting: 2–3 hours (often meandering)
Post-review: Days (someone writes up findings; ADR never happens)
Total: 2.5–4 hours + async follow-up
Output: Meeting notes, maybe a Slack summary
Pre-review prep: 5 min (paste docs into Cowork)
Review session with Cowork: 30 min (load context, ask questions, iterate)
ADR drafting: 15 min (Cowork writes it, you refine)
Total: 50 minutes
Output: Structured RFC feedback + formal ADR ready to merge
The Cowork workflow doesn't replace peer review by engineers — it accelerates the review process and ensures you ship the ADR. Engineers still make the final decision; Cowork provides the structured analysis and documentation.
For distributed teams, Cowork handles async architecture review cleanly. One engineer (the RFC proposer or a designated reviewer) runs the Cowork review session. The output is deterministic and shareable.
Workflow:
Total wall-clock time: 2–3 days for a thorough async review, vs. 1–2 weeks to schedule a synchronous meeting and then write it up afterward. And you actually get the ADR.
Architecture review with Cowork works because:
Let's deploy Cowork in your architecture review process. Our Claude Certified Architects can help you set up the workflow, templates, and team integration.
Cowork can process image files (PNG, JPEG, SVG), so yes — you can paste a system topology diagram into the canvas. However, Cowork's analysis is strongest when paired with plaintext descriptions of the diagram (what each component does, how they communicate). For best results: paste the diagram image + a markdown description of the topology. Claude will reason about both.
Load all team ADRs into the canvas at once. Cowork will identify where decisions conflict and flag them as "Conflicts" in the output. You then decide whether: (1) one team should adopt the other's pattern for consistency, (2) both patterns are valid in different domains, or (3) you need a new ADR to reconcile them. Cowork surfaces the conflict; the team resolves it.
Both patterns work. Pre-meeting: run the Cowork analysis, share findings with the team before the sync meeting — meeting is now discussion + approval vs. discovery. In-meeting: do the Cowork analysis live with stakeholders in the room, use the findings to drive discussion. Most teams do hybrid: engineer runs Cowork solo first, then uses it as the backbone of the team discussion.
Cowork is for design discussion and decision documentation — you load multiple documents, ask exploratory questions, and export findings. Claude Code is for implementation — writing code, running tests, debugging. Use Cowork for architecture reviews. Use Claude Code when you're building the system that implements the architecture. They complement each other.