Captures and retrieves PR-review findings in memory palaces. Use after PR review to store architectural decisions, patterns, and standards for future reference.
npx skills add https://github.com/athola/claude-night-market --skill review-chamber
Capture, organize, and retrieve knowledge from PR reviews within project memory palaces.
The Review Chamber is a dedicated room within each project palace that stores valuable knowledge extracted from PR reviews. It transforms ephemeral PR discussions into persistent, searchable institutional memory.
review-chamber/
├── decisions/ # Architectural choices from PR discussions
├── patterns/ # Recurring issues and their solutions
├── standards/ # Quality bar examples and coding conventions
└── lessons/ # Post-mortems and learnings
Verification: Run the command with --help flag to verify availability.
After a PR review completes, evaluate findings for knowledge capture:
## Knowledge Detection Checklist
For each finding from sanctum:pr-review, evaluate:
- [ ] **Novelty**: Is this a new pattern or first occurrence?
- [ ] **Applicability**: Will this affect future PRs in this area?
- [ ] **Durability**: Is this architectural (capture) or tactical (skip)?
- [ ] **Connectivity**: Does it link to existing palace rooms?
Verification: Run the command with --help flag to verify availability.
Route findings to appropriate subrooms:
| Finding Type | Target Room | Criteria |
|-------------|-------------|----------|
| Architectural choice | decisions/ | BLOCKING and architectural context |
| Recurring issue | patterns/ | Seen before or likely to recur |
| Quality example | standards/ | Exemplifies coding standards |
| Learning/insight | lessons/ | Retrospective or post-mortem |
Create structured entry with:
---
source_pr: "#42 - Add authentication"
date: 2025-01-15
participants: [author, reviewer1, reviewer2]
palace_location: review-chamber/decisions
related_rooms: [workshop/auth-patterns, library/security-adr]
tags: [authentication, jwt, security]
---
## Decision Title
### Decision
Chose JWT tokens over server-side sessions.
### Context (from PR discussion)
- Reviewer asked: "Why not use sessions?"
- Author explained: stateless scaling requirements
- Discussion refined: added refresh token rotation
### Captured Knowledge
- **Pattern**: JWT + refresh tokens for stateless auth
- **Tradeoff**: Complexity vs. horizontal scaling
- **Application**: Use for all API authentication
### Connected Concepts
- [[auth-patterns]] - Updated with JWT best practices
- [[security-adr-003]] - Referenced this decision
Verification: Run the command with --help flag to verify availability.
After capture, update related palace rooms:
# Automatic: sanctum:pr-review triggers capture
/pr-review 42
# → Review posted to GitHub
# → Knowledge capture evaluates findings
# → Significant decisions stored in review-chamber
# Manual: Explicitly capture from PR
/review-room capture 42 --room decisions
Verification: Run the command with --help flag to verify availability.
# Find authentication decisions
/review-room search "authentication" --room decisions
# Find patterns in a specific area
/review-room search "error handling" --room patterns --tags api
# List recent entries
/review-room list --limit 10 --room standards
Verification: Run the command with --help flag to verify availability.
When starting work in a code area:
## Relevant Review Knowledge
Starting work in `auth/` directory...
**Past Decisions:**
- [#42] JWT token decision → decisions/jwt-over-sessions
- [#67] Rate limiting pattern → patterns/api-throttling
**Quality Standards:**
- [#55] Error response format → standards/api-errors
**Known Patterns:**
- [#38] Token refresh edge case → patterns/token-refresh-race
Verification: Run the command with --help flag to verify availability.
The review-chamber integrates after Phase 6 (Generate Report):
**Verification:** Run the command with `--help` flag to verify availability.
Phase 6: Generate Report
↓
[HOOK] Evaluate findings for knowledge capture
↓
For each significant finding:
├── Classify into room type
├── Create ReviewEntry
├── Add to project palace
└── Update connections
↓
Phase 7: Post to GitHub
Verification: Run the command with --help flag to verify availability.
Uses the same evaluation framework:
| Criterion | Weight | PR Review Application |
|-----------|--------|----------------------|
| Novelty | 25% | New pattern or first occurrence |
| Applicability | 30% | Affects future PRs in this area |
| Durability | 20% | Architectural vs tactical |
| Connectivity | 15% | Links to existing rooms |
| Authority | 10% | Senior reviewer or domain expert |
Extends search to include review-chamber:
python scripts/palace_manager.py search "authentication" \
--palace project-name \
--room review-chamber \
--type semantic
Verification: Run python --version to verify Python environment.
# Capture knowledge from PR
/review-room capture <pr_number> [--room <room_type>] [--tags <tags>]
# Search review chamber
/review-room search "<query>" [--room <room_type>] [--tags <tags>]
# List entries
/review-room list [--room <room_type>] [--limit N]
# View entry details
/review-room view <entry_id>
# Export for documentation
/review-room export [--format markdown|json] [--room <room_type>]
# Statistics
/review-room stats [--palace <palace_id>]
Verification: Run the command with --help flag to verify availability.
modules/capture-workflow.md for detailed capture processmodules/evaluation-criteria.md for knowledge worth assessmentmodules/search-patterns.md for query optimizationfinding; findings scoring ≥ 60 are captured, < 60 are skipped
decisions/, patterns/, standards/, or lessons/
source_pr, date,palace_location, and at least one tag
existing palace rooms after capture
palace_manager.py search "<topic>" returns the captured entrywhen queried by its tags or content after storage
Control Cursor AI code editor via CLI. Open files, folders, diffs, and manage extensions.
Comprehensive checklist for conducting thorough code reviews covering functionality, security, performance, and maintainability
Systematically evaluate architecture decisions, document trade-offs, and select appropriate patterns. This skill should be used when the user asks about 'architecture decision', 'ADR', 'design pattern selection', 'technology choice', or needs to evaluate architectural trade-offs. Keywords: architecture, ADR, patterns, trade-offs, technical debt, quality attributes, decision record.
Facilitates deliberate skill development during AI-assisted coding. Offers interactive learning exercises after architectural work (new files, schema changes, refactors). Use when completing features, making design decisions, or when user asks to understand code better. Triggers on "learning exercise", "help me understand", "teach me", "why does this work", or after creating new files/modules. Do NOT use for urgent debugging, quick fixes, or when user says "just ship it".
Organize project files and folders for maintainability and scalability. Use when structuring new projects, refactoring folder structure, or establishing conventions. Handles project structure, naming conventions, and file organization best practices.
Automatically trigger review agents after task completion. Use when strategic-planner finishes planning tasks (calls plan-consultant) or when main agent completes coding tasks in /implement workflow (calls code-reviewer). Triggers on phrases like "plan complete", "implementation done", "coding finished", "ready for review".
Provides a structured workflow for planning and executing code reviews like a senior engineer. Use when asked to review code, PRs, or plan a code review task.
Recall project-first and global-supplement ChatCrystal memories before substantive implementation, refactoring, migration, configuration, investigation, or optimization work. Use when the task is non-trivial, has repository or project context, and prior fixes, decisions, pitfalls, or reusable patterns may change the approach.
Take athola/review-chamber from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.