ARB Review — Architecture Review Board Presentation
Purpose
Generates an 11-slide architecture review presentation following Coco Inc's standard ARB format. Used when a product needs architecture sign-off for a new instance, major integration, platform migration, or periodic review.
Process
Step 1: Read Context
Required sources (read all that exist):
CLAUDE.local.md — project context, architecture decisions, stakeholders, ProdIDPRD/*.html or PRD/*.md — requirements, NFRs, technical considerations, integrations, data modelArchitecture/ or *Architecture*.html — existing diagrams, maps
Optional sources:
.sync-watch.json — project nameOperational/DR-Plan*.html — RTO/RPO targets (for slide 8)Data/Stakeholder-Directory.* — presenter and audience names
Step 2: Ask Discovery Questions
Only ask what cannot be inferred from context:
- Review type? New Product / Major Change / Periodic Review / Decommission
- Data classification? Purple / Red / Yellow / Green (if not in PRD)
- Audience? Firm-level ARB / Department-level / Technical review
- Known constraints or mandates? (e.g., "must use existing Snowflake instance")
- Decision you need? Approve / Approve-with-conditions / Defer — what specifically?
Step 3: Generate 11-Slide Deck
Output: Presentations/ARB-Review-{ProductName}-{Date}.html
Self-contained HTML file with:
- System fonts (no CDN dependencies)
- Click/keyboard navigation between slides
- Print CSS for PDF export
- Mermaid.js (CDN) for architecture diagrams
Slide structure — see references/arb-format.md for section details:
| # |
Slide |
Key Content |
| 1 |
Title & Context |
Product name, ProdID, review type, date, presenters |
| 2 |
Business Context |
Problem statement, strategic alignment, sponsor |
| 3 |
Current State |
AS-IS architecture (Mermaid diagram), pain points |
| 4 |
Proposed Architecture |
TO-BE architecture (Mermaid diagram), what changes |
| 5 |
Data Architecture |
Data classification, flows, retention, residency |
| 6 |
Security & Access |
AuthN/AuthZ, RBAC, encryption, CUECs |
| 7 |
Integration Points |
Upstream/downstream, protocols, error handling |
| 8 |
NFRs & SLAs |
Performance, availability, RTO/RPO, scalability |
| 9 |
Risk Assessment |
Architecture risks, mitigations, residual acceptance |
| 10 |
Implementation Plan |
Phases, timeline, rollback, blast radius |
| 11 |
Decision Request |
What you need from the board, options, recommendation |
Step 4: Populate Content
For each slide, pull from project sources:
- Slide 1: Product name and ProdID from CLAUDE.local.md. Review type from Step 2. Presenters from stakeholder directory.
- Slides 3-4: Generate Mermaid diagrams from PRD architecture section and Architecture maps. If current-state diagram exists, use it. If not, build from PRD integrations and technical considerations.
- Slide 5: Data classification from PRD or discovery. Data flows from integrations section. Retention from NFRs.
- Slide 6: RBAC from PRD. CUECs from operationalization section. SSO/AuthN from technical considerations.
- Slide 7: Extract all integration points from PRD. Add protocol, frequency, error handling.
- Slide 8: Pull NFRs directly from PRD table. RTO/RPO from DR plan if it exists.
- Slide 9: Pull risks from PRD risk section. Add architecture-specific risks.
- Slide 10: Pull timeline from PRD. Add rollback strategy.
- Slide 11: Decision request from Step 2. Frame options with recommendation.
Step 5: Present for Review
Show the deck outline with key content per slide. Ask:
- "Does this cover the right scope?"
- "Any slides that need different emphasis?"
- "Who are the presenters for slide 1?"
Apply feedback, then write the file.
Critical Rules
- Mermaid diagrams are mandatory for slides 3 and 4. Architecture reviews without diagrams fail.
- Data classification must be explicit. If unknown, mark as "TBD — requires classification" in red. Never assume.
- Slide 11 must have a clear ask. Not "please review" but "approve this architecture for production deployment" or "approve with condition: validate cascading before Phase 2."
- No implementation details on architecture slides. Show components, interfaces, and data flows — not code, configs, or step-by-step procedures.
- Keep it to 11 slides. If more content is needed, add appendix slides clearly labeled "APPENDIX" after slide 11.
1---2name: pmstudio-arb3description: Generate an Architecture Review Board (ARB) presentation in Coco Inc's standard 11-slide format. Use when someone asks to "create an ARB deck", "architecture review presentation", "prepare for architecture review board", "ARB slides", or needs to present a product/platform architecture for sign-off. Reads PRD, architecture maps, and project memory to pre-fill technical content. Produces a self-contained HTML slide deck.4---56# ARB Review — Architecture Review Board Presentation78## Purpose910Generates an 11-slide architecture review presentation following Coco Inc's standard ARB format. Used when a product needs architecture sign-off for a new instance, major integration, platform migration, or periodic review.1112## Process1314### Step 1: Read Context1516**Required sources (read all that exist):**17- `CLAUDE.local.md` — project context, architecture decisions, stakeholders, ProdID18- `PRD/*.html` or `PRD/*.md` — requirements, NFRs, technical considerations, integrations, data model19- `Architecture/` or `*Architecture*.html` — existing diagrams, maps2021**Optional sources:**22- `.sync-watch.json` — project name23- `Operational/DR-Plan*.html` — RTO/RPO targets (for slide 8)24- `Data/Stakeholder-Directory.*` — presenter and audience names2526### Step 2: Ask Discovery Questions2728Only ask what cannot be inferred from context:29301. **Review type?** New Product / Major Change / Periodic Review / Decommission312. **Data classification?** Purple / Red / Yellow / Green (if not in PRD)323. **Audience?** Firm-level ARB / Department-level / Technical review334. **Known constraints or mandates?** (e.g., "must use existing Snowflake instance")345. **Decision you need?** Approve / Approve-with-conditions / Defer — what specifically?3536### Step 3: Generate 11-Slide Deck3738**Output:** `Presentations/ARB-Review-{ProductName}-{Date}.html`3940Self-contained HTML file with:41- System fonts (no CDN dependencies)42- Click/keyboard navigation between slides43- Print CSS for PDF export44- Mermaid.js (CDN) for architecture diagrams4546**Slide structure — see `references/arb-format.md` for section details:**4748| # | Slide | Key Content |49|---|-------|-------------|50| 1 | Title & Context | Product name, ProdID, review type, date, presenters |51| 2 | Business Context | Problem statement, strategic alignment, sponsor |52| 3 | Current State | AS-IS architecture (Mermaid diagram), pain points |53| 4 | Proposed Architecture | TO-BE architecture (Mermaid diagram), what changes |54| 5 | Data Architecture | Data classification, flows, retention, residency |55| 6 | Security & Access | AuthN/AuthZ, RBAC, encryption, CUECs |56| 7 | Integration Points | Upstream/downstream, protocols, error handling |57| 8 | NFRs & SLAs | Performance, availability, RTO/RPO, scalability |58| 9 | Risk Assessment | Architecture risks, mitigations, residual acceptance |59| 10 | Implementation Plan | Phases, timeline, rollback, blast radius |60| 11 | Decision Request | What you need from the board, options, recommendation |6162### Step 4: Populate Content6364For each slide, pull from project sources:6566- **Slide 1**: Product name and ProdID from CLAUDE.local.md. Review type from Step 2. Presenters from stakeholder directory.67- **Slides 3-4**: Generate Mermaid diagrams from PRD architecture section and Architecture maps. If current-state diagram exists, use it. If not, build from PRD integrations and technical considerations.68- **Slide 5**: Data classification from PRD or discovery. Data flows from integrations section. Retention from NFRs.69- **Slide 6**: RBAC from PRD. CUECs from operationalization section. SSO/AuthN from technical considerations.70- **Slide 7**: Extract all integration points from PRD. Add protocol, frequency, error handling.71- **Slide 8**: Pull NFRs directly from PRD table. RTO/RPO from DR plan if it exists.72- **Slide 9**: Pull risks from PRD risk section. Add architecture-specific risks.73- **Slide 10**: Pull timeline from PRD. Add rollback strategy.74- **Slide 11**: Decision request from Step 2. Frame options with recommendation.7576### Step 5: Present for Review7778Show the deck outline with key content per slide. Ask:79- "Does this cover the right scope?"80- "Any slides that need different emphasis?"81- "Who are the presenters for slide 1?"8283Apply feedback, then write the file.8485## Critical Rules86871. **Mermaid diagrams are mandatory** for slides 3 and 4. Architecture reviews without diagrams fail.882. **Data classification must be explicit.** If unknown, mark as "TBD — requires classification" in red. Never assume.893. **Slide 11 must have a clear ask.** Not "please review" but "approve this architecture for production deployment" or "approve with condition: validate cascading before Phase 2."904. **No implementation details on architecture slides.** Show components, interfaces, and data flows — not code, configs, or step-by-step procedures.915. **Keep it to 11 slides.** If more content is needed, add appendix slides clearly labeled "APPENDIX" after slide 11.
coco-research