session-files
**This is the authoritative reference for session file naming.** All other documentation should reference this file for file names and structure.
$ npx -y skills add spencermarx/open-code-review --agent claude-codeHow it fires
How this agent gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
Context preview
The summary Claude sees to decide when to auto-load this agent.
**This is the authoritative reference for session file naming.** All other documentation should reference this file for file names and structure.
Agent definition
session-files.mdSession File Manifest
> **This is the authoritative reference for session file naming.** All other documentation should reference this file for file names and structure.
Session Directory Structure
Every OCR session creates files in `.ocr/sessions/{session-id}/`:
.ocr/sessions/{YYYY-MM-DD}-{branch}/
├── discovered-standards.md # Merged project context (shared across rounds)
├── requirements.md # User-provided requirements (if any, shared)
├── context.md # Phase 2+3: Change summary + Tech Lead guidance (shared)
├── map/ # Code Review Map artifacts (optional)
│ └── runs/
│ ├── run-1/ # First map generation
│ │ ├── topology.md # File categorization and sections
│ │ ├── flow-analysis.md # Dependency tracing results
│ │ ├── requirements-mapping.md # Coverage matrix (if requirements)
│ │ ├── map-meta.json # Structured map data (written by CLI via complete-map --stdin)
│ │ └── map.md # Final map output (presentation artifact)
│ └── run-2/ # Subsequent runs (created on re-map)
│ └── ... # Same structure as run-1
└── rounds/ # All round-specific artifacts
├── round-1/ # First review round
│ ├── reviews/ # Individual reviewer outputs
│ │ ├── principal-1.md
│ │ ├── principal-2.md
│ │ ├── quality-1.md
│ │ ├── quality-2.md
│ │ ├── security-1.md # (if security reviewer assigned)
│ │ ├── testing-1.md # (if testing reviewer assigned)
│ │ ├── ephemeral-1.md # (if --reviewer flag used)
│ │ └── {type}-{n}.md # (additional assigned custom reviewers)
│ ├── discourse.md # Cross-reviewer discussion for round 1
│ ├── round-meta.json # Structured review data (written by CLI via complete-round --stdin)
│ └── final.md # Synthesized final review for round 1
└── round-2/ # Subsequent rounds (created on re-review)
├── reviews/
│ └── ... # Same structure as round-1
├── discourse.md
├── round-meta.json
└── final.mdReview Rounds
OCR uses a **round-first architecture** where all round-specific artifacts live under `rounds/round-{n}/`. This makes multi-round reviews a first-class concept.
**Round behavior**:
- First `/ocr-review` creates `rounds/round-1/` with `reviews/`, `discourse.md`, `final.md`
- Subsequent `/ocr-review` on same day/branch creates `rounds/round-{n+1}/`
- Previous rounds are preserved (never overwritten)
- Each round has its own `discourse.md` and `final.md`
- SQLite tracks `current_round` via `ocr state show`; round metadata derived from filesystem
**Shared vs per-round/run artifacts**: | Shared (session root) | Per-round (`rounds/round-{n}/`) | Per-run (`map/runs/run-{n}/`) | |----------------------|--------------------------------|-------------------------------| | `discovered-standards.md` | `reviews/*.md` | `topology.md` | | `requirements.md` | `discourse.md` | `flow-analysis.md` | | `context.md` | `final.md` | `requirements-mapping.md` | | | | `map.md` |
**When to use multiple rounds**:
- Author addresses feedback and requests re-review
- Scope changes mid-review
- Different reviewer team composition needed
Map Runs
OCR uses a **run-based architecture** for maps, parallel to review rounds.
**Run behavior**:
- First `/ocr-map` creates `map/runs/run-1/` with map artifacts
- Subsequent `/ocr-map` on same day/branch creates `map/runs/run-{n+1}/`
- Previous runs are preserved (never overwritten)
- Each run produces a complete `map.md`
- SQLite tracks `current_map_run` via `ocr state show`; run metadata derived from filesystem
**Map artifacts per run**: | File | Phase | Description | |------|-------|-------------| | `topology.md` | 2 | File categorization and section groupings | | `flow-analysis.md` | 3 | Upstream/downstream dependency tracing | | `requirements-mapping.md` | 4 | Requirements coverage matrix (if requirements provided) | | `map-meta.json` | 5 | Structured map data (written by CLI via `complete-map --stdin`) | | `map.md` | 5 | Final synthesized Code Review Map (presentation artifact) |
**When to use multiple runs**:
- Changeset has evolved since last map
- Different requirements context needed
- Fresh analysis desired after code updates
File Specifications
Required Files
| File | Phase | Description | Used By | |------|-------|-------------|---------| | `discovered-standards.md` | 1 | Merged project context from config + references | All reviewers | | `context.md` | 2 | Change summary, diff analysis, Tech Lead guidance | All reviewers | | `rounds/round-{n}/reviews/{type}-{n}.md` | 4 | Individual reviewer outputs | Discourse, Synthesis | | `rounds/round-{n}/discourse.md` | 6 | Cross-reviewer discussion results | Synthesis | | `rounds/round-{n}/round-meta.json` | 7 | Structured review data (written by CLI via `complete-round --stdin`) | Dashboard | | `rounds/round-{n}/final.md` | 7 | Synthesized final review | Show, Post commands |
Optional Files
| File | When Created | Description | |------|--------------|-------------| | `requirements.md` | Phase 1 | User-provided requirements, specs, or acceptance criteria |
Reviewer File Naming
**Pattern**: `{type}-{n}.md`
- `{type}`: One of `principal`, `quality`, `security`, `testing`, `ephemeral`, or custom reviewer name
- `{n}`: Sequential number starting at 1
**Examples** (for round 1):
rounds/round-1/reviews/principal-1.md
rounds/round-1/reviews/principal-2.md
rounds/round-1/reviews/quality-1.md
rounds/round-1/reviews/quality-2.md
rounds/round-1/reviews/security-1.md
rounds/round-1/reviews/testing-1.md
rounds/round-1/reviews/performance-1.md # Custom reviewer
rounds/round-1/reviews/ephemeral-1.md # Ephemeral reviewer (from --reviewer)
rounds/round-1/reviews/ephemeral-2.md # Ephemeral reviewer (from --reviewer)
Read more
Session File Manifest
> **This is the authoritative reference for session file naming.** All other documentation should reference this file for file names and structure.
Session Directory Structure
Every OCR session creates files in `.ocr/sessions/{session-id}/`:
.ocr/sessions/{YYYY-MM-DD}-{branch}/
├── discovered-standards.md # Merged project context (shared across rounds)
├── requirements.md # User-provided requirements (if any, shared)
├── context.md # Phase 2+3: Change summary + Tech Lead guidance (shared)
├── map/ # Code Review Map artifacts (optional)
│ └── runs/
│ ├── run-1/ # First map generation
│ │ ├── topology.md # File categorization and sections
│ │ ├── flow-analysis.md # Dependency tracing results
│ │ ├── requirements-mapping.md # Coverage matrix (if requirements)
│ │ ├── map-meta.json # Structured map data (written by CLI via complete-map --stdin)
│ │ └── map.md # Final map output (presentation artifact)
│ └── run-2/ # Subsequent runs (created on re-map)
│ └── ... # Same structure as run-1
└── rounds/ # All round-specific artifacts
├── round-1/ # First review round
│ ├── reviews/ # Individual reviewer outputs
│ │ ├── principal-1.md
│ │ ├── principal-2.md
│ │ ├── quality-1.md
│ │ ├── quality-2.md
│ │ ├── security-1.md # (if security reviewer assigned)
│ │ ├── testing-1.md # (if testing reviewer assigned)
│ │ ├── ephemeral-1.md # (if --reviewer flag used)
│ │ └── {type}-{n}.md # (additional assigned custom reviewers)
│ ├── discourse.md # Cross-reviewer discussion for round 1
│ ├── round-meta.json # Structured review data (written by CLI via complete-round --stdin)
│ └── final.md # Synthesized final review for round 1
└── round-2/ # Subsequent rounds (created on re-review)
├── reviews/
│ └── ... # Same structure as round-1
├── discourse.md
├── round-meta.json
└── final.mdReview Rounds
OCR uses a **round-first architecture** where all round-specific artifacts live under `rounds/round-{n}/`. This makes multi-round reviews a first-class concept.
**Round behavior**:
- First `/ocr-review` creates `rounds/round-1/` with `reviews/`, `discourse.md`, `final.md`
- Subsequent `/ocr-review` on same day/branch creates `rounds/round-{n+1}/`
- Previous rounds are preserved (never overwritten)
- Each round has its own `discourse.md` and `final.md`
- SQLite tracks `current_round` via `ocr state show`; round metadata derived from filesystem
**Shared vs per-round/run artifacts**: | Shared (session root) | Per-round (`rounds/round-{n}/`) | Per-run (`map/runs/run-{n}/`) | |----------------------|--------------------------------|-------------------------------| | `discovered-standards.md` | `reviews/*.md` | `topology.md` | | `requirements.md` | `discourse.md` | `flow-analysis.md` | | `context.md` | `final.md` | `requirements-mapping.md` | | | | `map.md` |
**When to use multiple rounds**:
- Author addresses feedback and requests re-review
- Scope changes mid-review
- Different reviewer team composition needed
Map Runs
OCR uses a **run-based architecture** for maps, parallel to review rounds.
**Run behavior**:
- First `/ocr-map` creates `map/runs/run-1/` with map artifacts
- Subsequent `/ocr-map` on same day/branch creates `map/runs/run-{n+1}/`
- Previous runs are preserved (never overwritten)
- Each run produces a complete `map.md`
- SQLite tracks `current_map_run` via `ocr state show`; run metadata derived from filesystem
**Map artifacts per run**: | File | Phase | Description | |------|-------|-------------| | `topology.md` | 2 | File categorization and section groupings | | `flow-analysis.md` | 3 | Upstream/downstream dependency tracing | | `requirements-mapping.md` | 4 | Requirements coverage matrix (if requirements provided) | | `map-meta.json` | 5 | Structured map data (written by CLI via `complete-map --stdin`) | | `map.md` | 5 | Final synthesized Code Review Map (presentation artifact) |
**When to use multiple runs**:
- Changeset has evolved since last map
- Different requirements context needed
- Fresh analysis desired after code updates
File Specifications
Required Files
| File | Phase | Description | Used By | |------|-------|-------------|---------| | `discovered-standards.md` | 1 | Merged project context from config + references | All reviewers | | `context.md` | 2 | Change summary, diff analysis, Tech Lead guidance | All reviewers | | `rounds/round-{n}/reviews/{type}-{n}.md` | 4 | Individual reviewer outputs | Discourse, Synthesis | | `rounds/round-{n}/discourse.md` | 6 | Cross-reviewer discussion results | Synthesis | | `rounds/round-{n}/round-meta.json` | 7 | Structured review data (written by CLI via `complete-round --stdin`) | Dashboard | | `rounds/round-{n}/final.md` | 7 | Synthesized final review | Show, Post commands |
Optional Files
| File | When Created | Description | |------|--------------|-------------| | `requirements.md` | Phase 1 | User-provided requirements, specs, or acceptance criteria |
Reviewer File Naming
**Pattern**: `{type}-{n}.md`
- `{type}`: One of `principal`, `quality`, `security`, `testing`, `ephemeral`, or custom reviewer name
- `{n}`: Sequential number starting at 1
**Examples** (for round 1):
rounds/round-1/reviews/principal-1.md rounds/round-1/reviews/principal-2.md rounds/round-1/reviews/quality-1.md rounds/round-1/reviews/quality-2.md rounds/round-1/reviews/security-1.md rounds/round-1/reviews/testing-1.md rounds/round-1/reviews/performance-1.md # Custom reviewer rounds/round-1/reviews/ephemeral-1.md # Ephemeral reviewer (from --reviewer) rounds/round-1/reviews/ephemeral-2.md # Ephemeral reviewer (from --reviewer)
AI-powered multi-agent code review. Simulates a customizable team of Engineers performing code review with built-in discourse.
Repo: spencermarx/open-code-review
Other agents on open-code-review.
- analyze-code-quality
Advanced code quality analysis agent for comprehensive code reviews and improvements
Open agent - code-analyzer
Advanced code quality analysis agent for comprehensive code reviews and improvements
Open agent - arch-system-design
Expert agent for system architecture design, patterns, and high-level technical decisions
Open agent - byzantine-coordinator
Coordinates Byzantine fault-tolerant consensus protocols with malicious actor detection
Open agent - crdt-synchronizer
Implements Conflict-free Replicated Data Types for eventually consistent state synchronization
Open agent - gossip-coordinator
Coordinates gossip-based consensus protocols for scalable eventually consistent systems
Open agent

