Claude-skill-registry Game Vision Designer

Evolve and maintain game vision through Q&A interviews and decision tracking. Use when exploring game concepts, validating feature alignment, or making design decisions.

install

source · Clone the upstream repo

git clone https://github.com/majiayu000/claude-skill-registry

Claude Code · Install into ~/.claude/skills/

T=$(mktemp -d) && git clone --depth=1 https://github.com/majiayu000/claude-skill-registry "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/data/game-vision-designer" ~/.claude/skills/majiayu000-claude-skill-registry-game-vision-designer && rm -rf "$T"

manifest: skills/data/game-vision-designer/SKILL.md

source content

Game Vision Designer

The "north star" skill for Stapledon's Voyage. Maintains game vision docs, interviews the designer to evolve concepts, and validates that features align with core pillars.

Quick Start

Most common usage:

# User says: "interview me about the game"
# This skill will:
# 1. Load current vision from docs/vision/
# 2. Ask probing questions to deepen understanding
# 3. Update vision docs based on answers
# 4. Log any design decisions made

# User says: "does this feature fit the vision?"
# This skill will:
# 1. Load core-pillars.md
# 2. Check alignment with each pillar
# 3. Report: ALIGNED / NEEDS DISCUSSION / CONFLICTS

When to Use This Skill

Invoke this skill when:

User says "interview me" about game concepts
User asks "does [feature] fit the vision?"
User wants to make or record a design decision
User asks about core pillars or game direction
Other skills need vision context for their work
Starting a new major feature direction

Available Scripts

scripts/init_vision_docs.sh

Initialize the vision docs directory structure.

scripts/log_decision.sh <title> <decision> <rationale>

Log a design decision to design-decisions.md.

scripts/check_pillars.sh

Display current core pillars for quick reference.

Workflow

1. Vision Interview Mode

When user wants to explore/evolve concepts:

Load context - Read existing
```
docs/vision/
```
docs
Ask questions - Pick 2-3 from the interview bank (see resources)
Dig deeper - Follow up with "why?" and "give an example"
Update docs - Revise core-pillars.md, log decisions, note open questions

2. Feature Validation Mode

When validating a feature against vision:

Load pillars - Read
```
docs/vision/core-pillars.md
```
Check each pillar:
- Does feature serve this pillar? How?
- Does it conflict? How?
Check decisions - Any prior decisions relevant?
Report - ALIGNED / NEEDS DISCUSSION / CONFLICTS

3. Decision Logging Mode

When recording a design decision:

Capture context - Why did this come up?
Document decision - What was decided?
Record rationale - How does this serve the pillars?
Note alternatives - What was rejected and why?
Update docs - Append to design-decisions.md

Vision Doc Structure

All vision docs go to

docs/vision/

File	Purpose
`core-pillars.md`	3-5 non-negotiable design constraints
`design-decisions.md`	Log of decisions with rationale
`open-questions.md`	Unresolved design questions
`interview-log.md`	Q&A session history

Resources

Interview Questions Bank

See

resources/interview_questions.md

for full question bank organized by topic.

Vision Doc Templates

See

resources/vision_templates.md

for doc templates.

Integration with Other Skills

sprint-planner: Reads core-pillars.md before planning
design-doc-creator: References pillars when designing features
sprint-executor: Checks design-decisions.md for constraints

Notes

Pillars rarely change; if they do, document why
Every feature must serve at least one pillar
Be specific - vague pillars are useless
This is collaborative - thought partner, not gatekeeper