mike007jd Game Requirements Brainstorm
Goal
Turn the request into a requirement set that is specific enough to build a strong result.
Outputs
Follow the gsp-orchestrator output strategy:
- inline (default): present requirements and quality target in conversation.
- minimal or full: write
docs/game-studio/requirements.mdanddocs/game-studio/quality-target.md.
Use:
../../shared/templates/requirements-brief.md../../shared/templates/quality-target.md
Spec-driven compatibility
When gsp-spec-driven-planning is active and the user wants durable artifacts in the target repo:
- use the requirement brief as input to
changes/<change-id>/proposal.md - write capability deltas under
changes/<change-id>/specs/<capability>/spec.md - promote stable approved behavior into
specs/<capability>/spec.mdwhen the project wants living specs kept current
Workflow
- Extract what the user definitely wants.
- Separate must-build features, must-not-cut qualities, optional features, and explicit non-goals.
- Infer smart defaults when they are obvious.
- Ask high-value clarifying questions whenever missing information would materially affect game form, feature correctness, wow-factor, UX / onboarding, audio / feedback, or verification standards.
- Do not stop after one question if multiple unresolved details still meaningfully change the result.
- Write acceptance tests in user language.
- Decide whether the quality target should be
first-playable,polished-prototype,production-feature, orlive-patch.
Important
For greenfield showcase work, do not reduce the ask to a bare minimum. Default to high-precision questioning rather than question minimization.