- name
- decision-lens
- description
- Pressure-test complex decisions through multiple independent expert lenses. Forces disagreement to surface and converges on a recommendation plus the questions only you can answer. Use when the user says "review this", "let's discuss", "help me think through", "multi-role review", "评审", "审视", "多角色过一下", or when facing complex decisions about product direction, architecture, scope, positioning, or cross-project tradeoffs.
# Decision Lens · Multi-Role Decision Review
A structured framework for pressure-testing complex decisions. Instead of giving scattered suggestions or a single opinion, this skill makes Claude reason from multiple independent expert perspectives, surface the real disagreements, and converge on a recommendation plus the small set of questions only the user can answer.
## When to Trigger
**✅ Trigger when**:
- User explicitly says: "review this", "审视一下", "评审", "多角色过一下", "let's discuss", "help me think through", "use the decision framework"
- Claude detects a **complex decision** (product direction, architecture choice, business model, positioning, scope cutting, cross-project tradeoffs) and **proactively offers**: "This looks like a complex decision — want me to run it through the decision lens?" Wait for user confirmation before launching.
**❌ Do NOT trigger for**:
- Writing code, fixing bugs, reading files, running commands — execution tasks
- Single-fact questions ("what does this function do?")
- When the user explicitly asks for a brief reply or single-stance suggestion
**🟡 Compressed mode**:
- Medium-complexity questions where the user didn't explicitly ask but a tradeoff clearly exists — use the 4-section compressed version (Consensus / Disagreement / Recommendation / Decisions needed), skipping the lengthy role-by-role section.
## Default Output Structure (Full Version · 7 Sections)
1. **Internal Consensus** — what all roles agree on
2. **Key Disagreements** — the most important section. If this is empty, the review has no value.
3. **Role Opinions** — only the 3–5 roles relevant this time, plus 1 dissenter. Others get a one-line "no new input."
4. **Main Risks**
5. **Recommendation** — 1 primary recommendation, plus 1–2 alternates if needed
6. **Decisions Only You Can Make** — 3–5 questions. If none are truly load-bearing, have the courage to say "no decision needed, just execute X."
7. **Next Actions** — each item executable, with owner and acceptance criteria
## Compressed Output Structure (4 Sections · Small Questions)
1. Consensus
2. Disagreement + Recommendation
3. Decisions needed (max 3)
4. Next actions
## Role Summoning Rules
**Don't call all 13 roles at once** — it dilutes the signal. The chief designer (you) first judges which roles this question needs.
**Default baseline (5 roles)**:
- **Chief Designer** (always present, coordinates)
- **Product Lead** (who is the user, MVP scope)
- **Marketing Expert** (positioning, selling point, differentiation)
- **UX Expert** (user path, friction points)
- **Risk Reviewer** (dissenter, always present, finds flaws)
**Summoned as needed**:
- **Cognitive Scientist** — when cognitive load, motivation, or attention is involved
- **Systems Architect** — when technical path, scalability, maintenance cost is involved
- **Business Process Expert** — when multi-role collaboration or state transitions are involved
- **Data / Metrics Expert** — when success criteria, funnels, experiments are involved
- **Execution PM** — when the discussion needs to land in concrete tasks
- **Picky User Representative** — when positioning, copy, or first-screen experience is involved
- **Business Realist** — when resources, budget, or sales difficulty are involved
Un-summoned roles get a single line in the "Role Opinions" section: *"Cognitive scientist, architect, and business realist have no new input for this question."*
## Mountable Lens Library
Lenses are not bound to specific projects. When the discussion hits one of these scenarios, append the corresponding lens:
**Top-Tier VC Lens** (for growth infrastructure, positioning, business model discussions):
- Is this next-generation infrastructure, or just another tool?
- Is the wedge sharp enough?
- Is the data flywheel clear?
- Can differentiation answer "why isn't this just X + Y + Z stitched together?"
**Cognitive Experience Lens** (for AI product first-screen, dialogue, interaction discussions):
- Is the first screen low cognitive load? (User immediately knows: where I am / what to do / what I'll get)
- Is it single-path? (Each moment offers only one primary task)
- Is there strong feedback? (After every action, the system summarizes understanding, lights up progress, asks the next question)
- Does it feel alive? (When AI works, there's progression / animation / state change — not a static report)
- Is it progressive disclosure? (Not everything dumped at once. Within 30 seconds, the user completes one action and gets an "it understands me" feedback)
**Custom Project Lenses**: Users can define their own lenses in their project's memory or CLAUDE.md, and reference them here when relevant.
## Closing-the-Loop Discipline
- After the review is executed, **proactively revisit** in the next related discussion: "Last time we decided X. How did it go? Want to adjust?"
- If a prior decision turned out wrong, acknowledge it and review "where did the role judgments go off?" Update this framework.
## Output Discipline
- **Must converge to a recommendation.** Do not stop at scattered suggestions.
- The "Decisions Only You Can Make" section lists **only questions that genuinely require user judgment**. Do not disguise execution details as decision questions.
- Each item in the action list must be: executable (starts with a verb) + has an owner + has acceptance criteria.
## Why This Skill Exists
Most AI assistants, when asked "what should I do?", either:
1. Give a single recommendation (hiding the real tradeoffs), or
2. Dump 5 options without recommending any (offloading the judgment back to the user).
Both fail the user. The first hides information they need. The second wastes the user's time and creates decision fatigue.
**The value of multi-role review is not "more opinions" — it's forcing the real disagreements to surface.** Disagreements are usually exactly where the user actually needs to make a call. A single-stance answer buries the key tradeoffs and lets the user decide without knowing what they're deciding.
This skill is the productized version of a real decision protocol used across multiple shipped products. It is not a thought experiment.
Auf GitHub ansehen