Token导航 LogoToken导航TokenDH.com
研究检索需要联网clawhub未标认证来源可访问clear审计通过

game-design-thinking-fast-and-slow-audit游戏设计思维快慢审核

Agent Skill

用于辅助界面设计、视觉规范、排版、配色、布局和交互体验优化。它适合让 Agent 根据产品场景整理页面结构、生成 UI 方案、检查视觉一致性或改进组件层级。使用时需要结合现有品牌、设计系统和用户任务,不应只堆装饰元素;涉及真实页面改动时,应通过截图或浏览器预览检查文本溢出、对齐和响应式表现。

总安装

1,444

周安装

59

GitHub Stars

公开资料未说明

下载量

467
OpenClaw

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

2

许可证

MIT-0

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:game-design-thinking-fast-and-slow-audit(游戏设计思维快慢审核)
来源仓库:https://github.com/stanestane/game-design-thinking-fast-and-slow-audit
安装命令:
openclaw skills install game-design-thinking-fast-and-slow-audit
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 OpenClaw 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

ClawHubOpenClaw
openclaw skills install game-design-thinking-fast-and-slow-audit

简介

用快慢思维模型分析设计对玩家认知的影响。

  • 适用于UI、谜题、战斗系统或经济流程的评估。
  • 识别自动化与深思熟虑环节的分布合理性。
  • 输出为认知负荷分析,需配合可用性测试验证。
  • game-design-thinking-fast-and-slow-audit 属于研究检索类 Skill,可作为该场景下的辅助能力补充。

SKILL.md

name
game-design-thinking-fast-and-slow-audit
description
Audit a game, feature, combat system, economy loop, onboarding flow, puzzle, UI, or design proposal through the lens of fast versus slow thinking inspired by Thinking, Fast and Slow. Use when evaluating whether a design relies on rapid intuitive judgment or deliberate analytical reasoning, whether the intended mode matches the actual demand, where cognitive overload or under-stimulation appears, or how badly the design handles shifts between instinctive and reflective play.

Game Design Thinking Fast and Slow Audit

Audit a design by asking what kind of thinking it demands from the player, when, and whether that demand is appropriate.

Use this skill when a proposal sounds good in the abstract but may be mismatched to the kind of cognition it actually requires. The goal is to identify where the design leans on fast, intuitive, low-deliberation processing versus slow, analytical, effortful reasoning, and where the transition between those modes becomes awkward, exhausting, misleading, or strategically dead.

Read references/family-conventions.md when you want the shared style, prioritization, and diagnosis rules for this game-design skill family. Read references/output-patterns.md when you want the preferred recommendation and minimal-fix structure.

Core principle

Players do not think in one uniform way.

Some situations ask for:

  • rapid pattern recognition
  • instinctive response
  • snap prioritization
  • fluent repetition

Other situations ask for:

  • deliberate comparison
  • explicit planning
  • rule-based reasoning
  • careful tradeoff evaluation

Neither mode is automatically better. The important questions are:

  • which mode the design is asking for
  • whether that suits the fantasy and pacing
  • whether the player is being supported properly
  • whether the handoff between modes is clean

Fast and slow lenses

Fast-mode thinking

Typical qualities:

  • intuitive
  • automatic
  • rapid
  • pattern-based
  • low-deliberation
  • emotionally immediate

In game terms, this often appears in:

  • action combat
  • dodging, aiming, timing, rhythm
  • snap tactical prioritization
  • recognition of familiar board states
  • habitual session actions
  • high-tempo moment-to-moment play

Slow-mode thinking

Typical qualities:

  • reflective
  • effortful
  • explicit
  • comparative
  • planning-heavy
  • cognitively expensive

In game terms, this often appears in:

  • deckbuilding and loadout decisions
  • long-horizon economy planning
  • puzzle decomposition
  • route planning
  • team composition
  • optimization and meta decisions

What to produce

Generate:

  1. Thinking-mode profile - whether the design primarily demands fast thinking, slow thinking, or a layered mix
  2. Mode-fit diagnosis - whether the required thinking mode matches the fantasy, pacing, and audience
  3. Transition diagnosis - where the design shifts between fast and slow modes, and whether those handoffs work
  4. Cognitive risk map - where the design creates overload, confusion, autopilot deadness, or false depth
  5. Design actions - what to simplify, deepen, pace differently, surface more clearly, or separate

Process

1. Define the audit target

Clarify:

  • what exact game, feature, loop, or proposal is being audited
  • whether the audit is for minute-to-minute play, meta systems, onboarding, or the full experience
  • what player segment matters most

Write:

  • Audit target
  • Scope
  • Primary player segment

2. Identify the dominant thinking demand

Ask:

  • what does the player have to notice, decide, remember, and prioritize?
  • how much time do they have to do it?
  • are they reacting from fluency or stopping to reason explicitly?
  • what mistakes come from speed versus what mistakes come from misunderstanding?

Classify the dominant demand as:

  • mostly fast-mode
  • mostly slow-mode
  • mixed, with one dominant
  • deeply hybrid

3. Map where each mode appears

Break the experience into phases or layers such as:

  • onboarding
  • moment-to-moment play
  • build/loadout decisions
  • economy or progression planning
  • social/coordination layer
  • end-of-run reflection

For each phase, identify:

  • Thinking mode demanded
  • Why that mode is required
  • Whether the player has enough support

Use this format:

Phase or systemThinking modeDemand levelNotes
...Fast / Slow / MixedLow / Med / High...

4. Check fit between mode and fantasy

Ask:

  • does the cognitive demand support the intended fantasy?
  • is the game claiming flow, mastery, panic, elegance, command, coziness, or brilliance?
  • does the required thinking mode reinforce that promise or betray it?

Examples:

  • a fantasy of fluid sword mastery should not constantly hard-stop into spreadsheet reasoning
  • a fantasy of careful grand strategy should not bury important choices inside twitch pressure
  • a cozy planning game can tolerate slow thought, but not exhausting ambiguity

5. Diagnose fast-mode failure patterns

Look for:

  • reaction demands too fast for the available clarity
  • hidden information inside high-speed play
  • too many simultaneous priorities
  • snap judgments punished by information the player could not reasonably process
  • UI that slows recognition instead of supporting it
  • panic without readable action value

6. Diagnose slow-mode failure patterns

Look for:

  • analysis burden too high for the payoff
  • false complexity with obvious dominant answers
  • too many variables to compare meaningfully
  • long planning phases that are cognitively costly but emotionally flat
  • systems that imply deep strategy but resolve shallowly
  • excessive memory burden or bookkeeping

7. Diagnose transition failures between modes

This is often where designs get ugly.

Look for:

  • abrupt switches from high-speed execution to deep planning without recovery time
  • long slow-mode interruptions that kill fast-mode momentum
  • fast-mode punishment for choices made in poorly supported slow-mode spaces
  • slow-mode systems whose consequences only appear in frantic real-time moments
  • a requirement to do deep reasoning under time pressure when the interface does not support it

Ask:

  • where does the player shift modes?
  • is the shift clean, intentional, and well-signaled?
  • does the game give enough time, framing, and UI support for the new mode?

8. Identify audience mismatch and expertise effects

Ask:

  • does this design feel intuitive to experts but exhausting to new players?
  • does it ask casual players for tournament-level reasoning?
  • does it flatten expert depth into autopilot?
  • does the intended audience actually want this blend of cognition?

A system can be good for one audience and terrible for another because of thinking-mode mismatch alone.

9. Convert findings into design changes

For each major issue, specify:

  • Thinking-mode problem
  • Why it hurts the experience
  • Suggested change
  • Expected effect

Examples:

  • reduce simultaneous fast-mode demands -> improves readability and decision confidence
  • move some choices out of real-time pressure -> supports better slow-mode reasoning
  • compress false-complexity planning layers -> preserves depth while reducing fatigue
  • add clearer state framing before mode shifts -> reduces cognitive whiplash

Response structure

Use this structure unless the user asks for something else:

Audit Target

  • ...

Thinking-Mode Profile

  • ...

Fast-Mode Demands

  • ...

Slow-Mode Demands

  • ...

Transition and Handoff Issues

  • ...

Audience and Expertise Fit

  • ...

Recommendations

  1. ...
  2. ...
  3. ...

Minimal Fix

  • ...

Fast mode

Use this quick pass when speed matters:

  • Is this mainly asking for instinctive play or analytical play?
  • Does that fit the fantasy and pacing?
  • Where is the worst mismatch?
  • Where does the player switch modes?
  • What one change would most improve the cognitive fit?

Usage notes

This audit is especially useful for:

  • action/strategy hybrids
  • real-time systems with heavy pre-planning
  • economy layers attached to fast gameplay
  • onboarding for cognitively demanding games
  • puzzles embedded inside otherwise reactive experiences
  • proposal reviews where the cognitive demand is still fuzzy
  • UI-heavy systems that may be hiding slow thought inside supposed fast play

Common patterns to watch for:

  • many proposals accidentally ask for more slow thinking than their fantasy can sustain
  • some designs confuse time pressure with depth
  • some planning layers create the appearance of strategy without meaningful choice
  • many frustrating systems are really bad handoffs between fast and slow modes
  • expert fluency can hide a beginner-facing cognitive disaster

Working principle

A strong design does not just ask the player to think. It asks them to think in the right way, at the right time, with the right support.

Use this skill to identify whether the proposal's cognitive demands are elegant, mismatched, exhausting, or fake-deep.

适合场景

01

OpenClaw 用户查找和安装 Skill 时

02

用户想查找某类 Agent Skill 时

03

需要根据任务场景推荐可安装能力包时

04

需要对比不同来源的安装命令和来源信息时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

补充不同宿主或平台的使用分布数据

能力 5

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

OpenClaw

90.22%
按下载量换算421

安全审计

VirusTotal

通过

ClawScan

通过

Static analysis

通过

权限和风险

需要联网

该 Skill 可能需要联网访问来源站点、仓库或外部 API;具体网络访问范围需要结合源码和 README 复核。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。当前只有一个来源,正式发布前建议补源仓库或其他目录站核验。

来源信息

继续浏览同类 Skills