| name | Game Vision Designer |
| description | Evolve and maintain game vision through Q&A interviews and decision tracking. Use when exploring game concepts, validating feature alignment, or making design decisions. |
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