19-game-software-requirements-specification
Installation
SKILL.md
Game Software Requirements Specification
Use When
- A game needs a controlled SRS across client, server, content and operations.
Do Not Use When
- The concept is unbounded; use the game product brief first.
- Do not prescribe engine or service APIs without a pinned decision.
Required Inputs
| Artefact | Source or provider | Required? | Behaviour when missing |
|---|---|---|---|
| Approved brief, journeys, target matrix, rules and risks | Product, design, engineering and production | Yes | Stop affected requirements and issue a gap record. |
| Online, economy/ads, learning, wellbeing, data, safety, culture/rights, visual and platform obligations | Specialist owners | Conditional | Exclude or mark the feature blocked. |
Workflow
- Establish boundaries across client, authoritative services, platform services, content/build pipeline and operations.
- Assign
GREQ-*and specify action, precondition, authoritative transition, feedback, failure and oracle. - Specify saves, time/randomness, input, content, gameplay accessibility, localisation, age treatment, learning evidence limits, wellbeing/stopping, and fact/fiction/consultation/permission controls.
- For online play specify authority, sessions, replication intent, reconnect, version skew and abuse cases.
- Add conditioned device performance, memory, loading, thermal, network and storage measures.
- Specify telemetry purpose, economy integrity, privacy by SDK, build provenance, rollback and ethical commercial behaviour. If ads are in scope, require clear identification, a predictable genuine break after the requested action, neutral decline/close, cap/pace, no-fill/offline/error and kill switch; prohibit interruption of play, learning, narrative, saving, recovery, stopping and exit.
- Specify visual-direction and UI acceptance as observable game outcomes and evidence while deferring craft to the five game skills in
design-system-skills.