Game Feature to Spec
Overview
Convert an approved direction into an implementation-neutral contract that design, engineering, QA, art, data, and production can test.
When to use
Use after a feature option is selected and before tasks, code, content production, or schema changes begin.
When NOT to use
Do not use to choose among competing feature directions or to split an existing specification into ownership packets.
Required inputs and context discovery
Require approved option, player goal, non-goals, system boundaries, platform constraints, dependencies, persistence/network authority, content needs, tuning ownership, telemetry expectations, and playtest audience.
Safety and risk level
Specification writes are low-risk. Do not invent engine, backend, analytics, or database contracts; mark unresolved authority and schema decisions BLOCKED.
Workflow
- State purpose, player outcome, scope, and non-goals.
Completion criterion: stakeholders can identify what is explicitly not being built.
- Define inputs, outputs, state transitions, authority, persistence, and failure behavior.
Completion criterion: the feature can be represented as deterministic scenarios.
- Enumerate edge cases, abuse/exploit cases, accessibility, localization, and offline/network behavior.
Completion criterion: risky branches have expected outcomes or BLOCKED owners.
- Define tuning levers, defaults, ownership, migration needs, and telemetry events.
Completion criterion: designers can tune without hidden code changes where intended.
- Write acceptance and playtest criteria tied to observable behavior.
Completion criterion: QA can derive tests without guessing product intent.
Evidence and output contract
Produce feature-spec.md with purpose, non-goals, I/O, states, authority, edge cases, tuning, telemetry, content, acceptance criteria, playtest criteria, dependencies, and open decisions.
Handoff contract
Record approved version, owners of open decisions, affected systems, required prototypes, schema risks, and the prompt for work-packet decomposition.
Pitfalls and anti-rationalization
- Do not bake one implementation into a product requirement without reason.
- Do not omit failure, offline, or exploit behavior.
- Do not use target KPIs as observed results.
- Do not hide unresolved authority behind “implementation detail.”
Verification checklist
References and scripts
Use the approved brainstorming artifact, architecture contracts, data schemas, and existing telemetry vocabulary as inputs.
1---2name: game-feature-to-spec3description: Use when an approved, chosen, or selected game mechanic direction must become a testable specification with acceptance criteria, state transitions, inputs, outputs, edge cases, tuning, telemetry, and playtest criteria.4license: MIT5---6# Game Feature to Spec78## Overview9Convert an approved direction into an implementation-neutral contract that design, engineering, QA, art, data, and production can test.1011## When to use12Use after a feature option is selected and before tasks, code, content production, or schema changes begin.1314## When NOT to use15Do not use to choose among competing feature directions or to split an existing specification into ownership packets.1617## Required inputs and context discovery18Require approved option, player goal, non-goals, system boundaries, platform constraints, dependencies, persistence/network authority, content needs, tuning ownership, telemetry expectations, and playtest audience.1920## Safety and risk level21Specification writes are low-risk. Do not invent engine, backend, analytics, or database contracts; mark unresolved authority and schema decisions BLOCKED.2223## Workflow241. State purpose, player outcome, scope, and non-goals.25 Completion criterion: stakeholders can identify what is explicitly not being built.262. Define inputs, outputs, state transitions, authority, persistence, and failure behavior.27 Completion criterion: the feature can be represented as deterministic scenarios.283. Enumerate edge cases, abuse/exploit cases, accessibility, localization, and offline/network behavior.29 Completion criterion: risky branches have expected outcomes or BLOCKED owners.304. Define tuning levers, defaults, ownership, migration needs, and telemetry events.31 Completion criterion: designers can tune without hidden code changes where intended.325. Write acceptance and playtest criteria tied to observable behavior.33 Completion criterion: QA can derive tests without guessing product intent.3435## Evidence and output contract36Produce `feature-spec.md` with purpose, non-goals, I/O, states, authority, edge cases, tuning, telemetry, content, acceptance criteria, playtest criteria, dependencies, and open decisions.3738## Handoff contract39Record approved version, owners of open decisions, affected systems, required prototypes, schema risks, and the prompt for work-packet decomposition.4041## Pitfalls and anti-rationalization42- Do not bake one implementation into a product requirement without reason.43- Do not omit failure, offline, or exploit behavior.44- Do not use target KPIs as observed results.45- Do not hide unresolved authority behind “implementation detail.”4647## Verification checklist48- [ ] Purpose and non-goals are clear.49- [ ] States, I/O, authority, and failures are specified.50- [ ] Edge cases and tuning levers exist.51- [ ] Acceptance and playtest criteria are observable.52- [ ] Open decisions have owners or BLOCKED labels.5354## References and scripts55Use the approved brainstorming artifact, architecture contracts, data schemas, and existing telemetry vocabulary as inputs.
hoatv2211