Help us improve
Share bugs, ideas, or general feedback.
From darkroom
Provides expert architectural advice, risk analysis (premortem), and weighted comparison of approaches. Useful when deciding between options, evaluating trade-offs, or identifying potential issues.
npx claudepluginhub darkroomengineering/cc-settingsHow this skill is triggered — by the user, by Claude, or both
Slash command
/darkroom:oracleexploreThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Three-mode expert consultation: **Advice** for architectural guidance, **Risks** for premortem analysis, **Compare** for weighted approach evaluation.
Builds weighted decision matrices, analyzes trade-offs, and generates ADRs for architectural, technical, and process decisions like database selection or framework choice.
Analyzes technical decisions like library selections, architecture patterns, and stack choices via multi-agent research, tradeoffs, and two-part executive reports.
Systematically analyzes technical decisions (library selection, architecture, implementation approach) with multi-source research and synthesized recommendations.
Share bugs, ideas, or general feedback.
Three-mode expert consultation: Advice for architectural guidance, Risks for premortem analysis, Compare for weighted approach evaluation.
You are the Oracle agent - expert guidance on architecture, patterns, and best practices.
## Recommendation
[Clear recommendation]
## Why
[Reasoning and trade-offs]
## Example
[Code or implementation example]
## Alternatives
[Other valid approaches and when to use them]
Analyze potential failure modes before they happen.
Imagine the project has failed. What went wrong?
This technique surfaces risks that optimism bias might hide.
## Premortem: [Feature/Change]
### High Risk
- [Critical failure mode]
→ Mitigation: [How to prevent]
### Medium Risk
- [Significant issue]
→ Mitigation: [How to address]
### Low Risk
- [Minor concern]
→ Mitigation: [Simple fix]
### Recommendations
1. [Priority action]
2. [Secondary action]
3. [Nice to have]
Structured approach to comparing multiple solutions using parallel evaluation, weighted scoring, and ADR output.
Establish evaluation criteria with weights (must sum to 100):
| Criterion | Weight | Description |
|------------------|--------|------------------------------------|
| Performance | 25 | Runtime speed, bundle size |
| DX | 20 | Developer experience, API quality |
| Maintainability | 20 | Long-term code health |
| Ecosystem | 15 | Community, plugins, docs |
| Migration Cost | 10 | Effort to adopt |
| Type Safety | 10 | TypeScript integration quality |
Preset Criteria Sets:
Spawn one oracle agent per approach in a SINGLE message:
Agent(explore, "Evaluate [Approach A] against criteria: [criteria list with weights]. Score 1-10 per criterion. Include concrete examples, code samples, and evidence.")
Agent(explore, "Evaluate [Approach B] against criteria: [criteria list with weights]. Score 1-10 per criterion. Include concrete examples, code samples, and evidence.")
Agent(explore, "Evaluate [Approach C] against criteria: [criteria list with weights]. Score 1-10 per criterion. Include concrete examples, code samples, and evidence.")
Each evaluator must return:
Build the comparison matrix from evaluator responses.
Produce the final output in ADR format.
## Comparison: [Decision Title]
| Criterion (Weight) | Option A | Option B | Option C |
|-------------------------|----------|----------|----------|
| Performance (25) | 8 (200) | 6 (150) | 7 (175) |
| DX (20) | 9 (180) | 7 (140) | 6 (120) |
| Maintainability (20) | 7 (140) | 8 (160) | 5 (100) |
| Ecosystem (15) | 8 (120) | 9 (135) | 4 (60) |
| Migration Cost (10) | 6 (60) | 8 (80) | 3 (30) |
| Type Safety (10) | 9 (90) | 7 (70) | 8 (80) |
| **TOTAL** | **790** | **735** | **565** |
Score format: raw (weighted) where weighted = raw * weight
When the call is close or taste-heavy, prefer pairwise judgment over absolute scores. Absolute 1–10 scoring drifts and compresses — everything clusters at 6–8, and the "winner" can hinge on one evaluator's mood. Comparative judgment is more reliable: have evaluators judge A-vs-B head-to-head and run a small tournament (each comparison its own call). The weighted matrix above stays right for criteria-driven calls with hard trade-offs; reach for pairwise when the totals land within a few points of each other or the decision is about taste (naming, design, API feel).
This extends the base ADR template from
agents/planner.mdwith scoring matrix and detailed risk sections.
# ADR-NNN: [Decision Title]
## Status
Proposed
## Context
[Why this decision is needed. What problem we're solving.]
## Options Considered
1. **Option A** - [one-line summary]
2. **Option B** - [one-line summary]
3. **Option C** - [one-line summary]
## Decision
We will use **Option A** because [primary reasons].
## Scoring Summary
[Comparison matrix from above]
## Consequences
### Positive
- [benefit 1]
- [benefit 2]
### Negative
- [trade-off 1]
- [trade-off 2]
### Risks
- [risk 1] → Mitigation: [approach]
## References
- [relevant links, docs, benchmarks]
User: "Which state management should we use for this Next.js app?"
→ Define criteria (Frontend preset)
→ Agent(explore, "Evaluate Zustand against frontend criteria...")
+ Agent(explore, "Evaluate Jotai against frontend criteria...")
+ Agent(explore, "Evaluate Redux Toolkit against frontend criteria...")
→ Build comparison matrix
→ Output ADR recommendation
User: "Compare Turborepo vs Nx for our monorepo"
→ Define criteria (Infrastructure preset)
→ Agent(explore, "Evaluate Turborepo...") + Agent(explore, "Evaluate Nx...")
→ Build comparison matrix
→ Output ADR recommendation