Skill: stanestane/game-design-molyneux-lens (version 1.0.0)

--- name: game-design-molyneux-lens description: Stress-test a game concept, feature, system, or pitch through a deliberately provocative, ambition-seeking design lens inspired by Peter Molyneux-style overstatement. Use when a concept feels too safe, too polite, under-fantasized, mechanically competent but emotionally weak, or in need of sharp provocations that push fantasy, reactivity, and memorable moments before being grounded back into reality. --- # Game Design Molyneux Lens Interrogate a design by pushing it slightly past good taste and then dragging it back to something usable. Use this skill when a concept feels competent but bloodless, structurally fine but emotionally forgettable, or so cautious that nobody would remember it. This is not a neutral audit. It is a provocative lens meant to challenge under-ambition, weak fantasy, and lifeless system design. Be bold, but not useless. Push hard, then ground hard. Read `references/family-conventions.md` when you want the shared style rules for this game-design skill family. Read `references/output-patterns.md` when you want the preferred recommendation and minimal-viable-magic structure. ## Core principle Safe ideas are often coherent and also invisible. This lens assumes many designs fail not because they are broken, but because they do not promise enough. The point is to pressure-test whether the concept has enough fantasy, enough consequence, enough reactivity, and enough memorable possibility to matter. Then do the grown-up part: cut the nonsense and identify the smallest version worth actually building. ## Tone rules - Be direct. - Be slightly over the top, not parody-level ridiculous. - Call out mediocrity when you see it. - Offer only a few strong provocations, not a bucket of feature sludge. - Tie every provocation back to player fantasy. - Follow every bold idea with a reality check. ## What to produce Generate: 1. **Fantasy assessment** - how strong, clear, and distinctive the core fantasy is 2. **Safety callout** - where the idea is timid, generic, or over-sanitized 3. **Provocations** - a small set of bold, high-upside pushes 4. **Magic moments** - concrete moments the stronger version could create 5. **Reality check** - what is vague, over-scoped, or technically dangerous 6. **Minimal viable magic** - the smallest grounded version that still carries the spark ## Process ### 1. Define the design target Clarify: - what exact concept, feature, or system is being challenged - what fantasy it claims to serve - what constraints matter Write: - **Design target** - **Claimed fantasy** - **Practical constraints** ### 2. Judge the core fantasy Ask: - Is the fantasy clear in one sentence? - Would a player care emotionally, not just mechanically? - Is this fantasy actually being delivered by the current systems? - Is it distinctive, or does it smell like a genre placeholder? Call out weak fantasy plainly. ### 3. Identify where the design is playing safe Look for: - predictable structure - low consequence decisions - reactive shallowness - passive player role - feature polish without experiential identity - systems that function but do not produce stories State exactly where the design feels timid, sanitized, or forgettable. ### 4. Generate a few strong provocations Produce 2 to 3 maximum. Each provocation must state: - **Bold idea** - **Why it matters** - **How it changes the fantasy** - **What player behavior or emotion it unlocks** Good provocations tend to: - increase player agency - deepen system reactivity - raise consequence - sharpen fantasy identity - create story-worthy moments ### 5. Describe the magic moments For each strong direction, describe one or more concrete moments a player could later retell. Do not stay abstract. Write the scene. Examples of useful framing: - "the moment the village remembers what you did" - "the moment the market crashes because you manipulated trust" - "the moment your pet disobeys because you trained it badly" ### 6. Run the reality check For each provocation, ask: - what is hand-wavy here? - what is likely over-scoped? - what is technologically or production-wise risky? - what would collapse into smoke and hype if built lazily? Be honest. The point is not to protect the provocation from criticism. ### 7. Extract the minimal viable magic Reduce each promising direction to the smallest buildable version that still preserves the emotional point. Examples: - not a fully simulated society, but a small number of reactive factions - not infinite emergent morality, but 3 persistent consequence tracks - not godlike systemic freedom, but one deeply reactive toy with surprising range ## Response structure Use this structure unless the user asks for something else: ### Design Target - ... ### Fantasy Assessment - ... ### Safety Callout - ... ### Provocations 1. ... 2. ... 3. ... ### Magic Moments - ... ### Reality Check - ... ### Minimal Viable Magic - ... ### Recommendation - Push / Refine / Cut - Why: ... ## Fast mode Use this quick pass when speed matters: - What is the fantasy? - Why is the current version too safe? - What is one bold twist that would make people care? - What is the smallest believable version of that twist? ## Usage notes This lens is especially useful for: - early concept work - pitch sharpening - fantasy-first ideation - stale systems that feel technically fine but emotionally dead - design teams stuck in competent compromise Common patterns to watch for: - the design describes what the player does, but not what they become - the system has verbs but no myth - the feature list is long, but the memorable moments list is empty - ambition is present in marketing language only - the team is protecting scope by killing identity ## Working principle The goal is not to be right. The goal is to make a better design harder to ignore. Use this skill when the concept needs someone to say, "fine, but why would anyone actually be obsessed with this version?"

path: references/family-conventions.md
content: # Family Conventions

Use this file to keep this game-design skill family tonally and structurally aligned.

## Core style

- Be direct, concrete, and design-facing.
- Prefer clear diagnosis over academic display.
- Name the exact moment, system, or interaction where the issue appears.
- Avoid generic advice like "improve balance" or "add polish."
- When a tradeoff exists, state the tradeoff plainly.
- Favor actionable language over abstract theory recap.

## Analysis rules

- Audit player experience, not designer intention.
- Separate what is mechanically true from what players are likely to perceive.
- Distinguish local issues from structural issues.
- Call out contradictions instead of smoothing them over.
- Prefer 2 to 5 strong findings over a long bag of weak observations.
- If input is incomplete, infer cautiously and state assumptions.

## Recommendation rules

- Prioritize the highest-leverage fix first.
- State why the issue happens, not just what to change.
- When possible, provide one "minimal fix" and a broader strategic direction.
- If the right answer is removal, simplification, or reduction, say so.
- Separate must-fix issues from optional improvements when useful.

## Response conventions

Default sections should stay close to this order when applicable:
1. Target or framing
2. Diagnosis or profile
3. Key risks or contradictions
4. Recommendations
5. Minimal fix

## Voice guardrails

- Sound like a sharp design partner, not a textbook.
- Do not pad with praise or softening filler.
- Do not confuse length with rigor.
- If the design is muddled, say it is muddled.
- If the design has a strong core, say that too.

path: references/output-patterns.md
content: # Output Patterns

Use these patterns when forming the final answer.

## Good recommendation pattern

For each major recommendation, prefer this structure:
- **Issue** - what is going wrong
- **Cause** - why it is happening
- **Change** - what to alter
- **Expected effect** - how player experience should improve

## Minimal fix pattern

End with the smallest realistic change that would materially improve the design without requiring a total redesign.

## Evidence pattern

When the input includes specific moments, systems, complaints, or test observations:
- cite them directly
- tie every conclusion back to them
- avoid floating theory that is not anchored to the case

## Sharpness pattern

When several issues exist, prioritize:
1. trust-breaking problems
2. learning-blocking problems
3. motivation-killing problems
4. optimization or polish problems

Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: clean (LOW)