6

Other

Explore and compare multiple parallel solution designs ("universes") before coding, then converge on a single, well-justified approach. Use when problems are ambiguous, have many trade-offs, or the user is unsure which direction to take.

Install

openclaw skills install @openlang-cn/6

Multiverse Architect

Design software as if exploring parallel universes: generate several distinct solution paths, explore each briefly, then choose and refine the best one with clear reasoning and trade-offs.

This skill is intentionally imaginative yet practical. It turns vague or high-stakes problems into a structured exploration of alternatives before writing or modifying code.

When to Use This Skill

Use Multiverse Architect when:

The task is ambiguous or has many possible approaches.
There are important trade-offs (performance vs simplicity, DX vs UX, short-term vs long-term).
The user says things like:
- "不确定应该怎么实现" / "I'm not sure which way is better."
- "有没有别的方案？" / "Are there other options?"
- "我们要不要用某某框架？" / "Should we use framework X?"
The change impacts architecture, data models, or cross-cutting behavior.

Do not use this skill for:

Trivial bug fixes with an obvious solution.
Purely mechanical changes (renaming, formatting, small copy edits).

Core Principles

Parallel universes, not random variants
- Each "universe" is a coherent, internally consistent design, not a tiny tweak.
- Differences must be meaningful (architecture style, data shape, ownership boundaries, flow of control).
Shallow first, deep later
- Start with coarse-grained sketches of each universe.
- Only go deep on the one that is ultimately chosen.
Explicit trade-offs
- For each universe, list pros, cons, and risks.
- Always tie trade-offs back to the user’s actual constraints (team skills, deadlines, performance, etc.), inferred from context when not stated.
Reversible decisions
- Prefer designs that keep options open and make it easier to pivot later.
- Call out which choices are hard to change vs easy to change.

Workflow Overview

Follow this 4-phase workflow:

Clarify the problem (what must be true, what is flexible)
Generate 3–4 universes (distinct solution designs)
Evaluate and converge (pick one, maybe merge good ideas)
Produce a concrete implementation plan

Use this process before writing or modifying code for large or ambiguous tasks.

Phase 1: Clarify the Problem

When this skill is activated, start by constructing a concise problem summary and constraints list in your own words.

1.1 Problem Snapshot

Produce a short snapshot with this structure:

## Problem snapshot
- Goal: [...]
- Existing context: [...]
- Hard requirements: [...]
- Soft preferences: [...]
- Unknowns / assumptions: [...]

Guidelines:

Goal: Describe the user-visible outcome, not the implementation.
Existing context: Mention relevant tech stack, files, or patterns already in use.
Hard requirements: Things that must not break or be violated.
Soft preferences: Things that are "nice to have" (DX, style, etc.).
Unknowns / assumptions: State assumptions you will proceed with; adjust later if proven wrong.

1.2 Sanity Check

Silently check:

Is the problem actually simple with a single obvious path?
- If yes, reduce this skill to a quick single-universe justification and proceed with normal implementation.
Otherwise, continue to Phase 2.

Phase 2: Generate Universes

Create 3 to 4 distinct universes (solutions). Fewer than 3 is allowed only when the space is clearly narrow.

2.1 Universe Template

For each universe, use:

### Universe X – [Short name]

**Core idea**: One-sentence summary of the approach.

**Architecture sketch**:
- Key components / modules
- How data flows
- How responsibility is divided

**How it would look in this project**:
- Key files to touch or create
- Rough APIs / interfaces
- How it fits existing conventions (or why it intentionally diverges)

**Pros**:
- [...]

**Cons / risks**:
- [...]

**Most suitable when**:
- [...]

2.2 Encourage Genuine Diversity

When generating universes:

Intentionally vary:
- Where complexity lives (frontend vs backend, infra vs app logic).
- Data contracts (rich objects vs thin DTOs, normalized vs denormalized).
- Control flow (event-driven vs request/response, imperative vs declarative).
Avoid fake variation like:
- "With comments" vs "without comments".
- Only changing naming or minor patterns.

Phase 3: Evaluate and Converge

Once universes are defined, compare and pick.

3.1 Comparison Matrix

Construct a compact comparison:

## Universe comparison

| Universe | Complexity | Performance | DX / Maintainability | Risk | Notes |
|---------|------------|-------------|----------------------|------|-------|
| U1      | low/med/high | ...       | ...                  | ...  | ...   |
| U2      | ...        | ...         | ...                  | ...  | ...   |
| U3      | ...        | ...         | ...                  | ...  | ...   |

Adjust columns as needed (e.g., "Scalability", "Time-to-implement").

3.2 Choose (or Hybridize) a Universe

Then produce:

## Decision

- Chosen universe: [Ux or Hybrid of Ux + Uy]
- Main reasons:
  - [...]
  - [...]
- Borrowed ideas from other universes:
  - From [Uy]: [...]
  - From [Uz]: [...]

Guidelines:

If combining, name the hybrid and clearly state which pieces come from which universe.
Explicitly justify why the rejected universes were rejected (too complex, too brittle, misaligned with constraints, etc.).

Phase 4: Implementation Plan

Turn the chosen universe into a concrete plan that you will then execute using normal tools and workflows.

4.1 Plan Template

Use this:

## Implementation plan (Multiverse Architect)

### Scope
- Files to modify:
  - [...]
- New files / modules:
  - [...]
- Out-of-scope:
  - [...]

### Steps
1. [...]
2. [...]
3. [...]

### Safety checks
- [ ] Existing behavior covered by tests or manual checks
- [ ] Data migrations (if any) are planned
- [ ] Rollback strategy is identified (what to revert if needed)

4.2 Execution Mode

After the plan is created:

Proceed with actual implementation outside this skill, using standard coding behavior.
If the user changes constraints mid-way, revisit:
- Either adjust the current universe.
- Or briefly spin up one new alternative universe to re-evaluate.

Mini-Mode: Lightweight Multiverse

For medium-sized decisions (too big to be trivial, too small for full multiverse), use this compressed flow:

Write a 1-paragraph problem snapshot.
Sketch 2 universes with only:
- Core idea
- 2–3 pros
- 2–3 cons
Choose one in 3–4 bullet points.
Write a short 3–5 step implementation outline.

Then continue as usual with coding.

Examples

Example A – Choosing a State Management Strategy

User: "我们要不要把这个 React 项目的状态全部换成 Zustand，还是继续用 Redux？"

Apply this skill:

Snapshot problem (current Redux usage, pain points, team familiarity).
Generate universes like:
- U1: "Stay on Redux but modernize (Toolkit, RTK Query)."
- U2: "Hybrid: key global state in Redux, local / view state in Zustand."
- U3: "Full migration to Zustand with new patterns."
Compare along learning curve, migration risk, DX, library ecosystem.
Choose and produce a concrete migration (or non-migration) plan.

Example B – Designing a Feature Flag System

User: "需要一个开关系统来灰度发布新功能，但不确定要做多复杂。"

Universes might be:

U1: Config-file-based flags with a simple in-process helper.
U2: Centralized flag service + SDK-like helper.
U3: Database-backed flags with admin UI.

Then:

Evaluate based on team size, deployment frequency, and risk tolerance.
Choose U1 + tiny piece of U2 (clear abstraction boundary).
Output a focused plan touching specific modules/files.

Summary Checklist for Using This Skill

Before leaving Multiverse Architect mode, verify:

A clear problem snapshot has been written.
At least 2–3 genuinely distinct universes have been explored.
A comparison table or bullet list exists.
A single approach (or hybrid) has been explicitly chosen.
There is a concrete, step-based implementation plan connected to the codebase.

Once all are satisfied, proceed to implement using the chosen design.