# Game Feature To Spec

> 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.

- Skill: `hoatv2211/game-feature-to-spec` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add hoatv2211/game-feature-to-spec`
- Raw SKILL.md: https://api.skillmd.com/api/skills/hoatv2211/game-feature-to-spec/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- License: MIT
- Author: hoatv2211 (https://skillmd.com/u/hoatv2211)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/hoatv2211/game-feature-to-spec

---

# 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
1. State purpose, player outcome, scope, and non-goals.
   Completion criterion: stakeholders can identify what is explicitly not being built.
2. Define inputs, outputs, state transitions, authority, persistence, and failure behavior.
   Completion criterion: the feature can be represented as deterministic scenarios.
3. Enumerate edge cases, abuse/exploit cases, accessibility, localization, and offline/network behavior.
   Completion criterion: risky branches have expected outcomes or BLOCKED owners.
4. Define tuning levers, defaults, ownership, migration needs, and telemetry events.
   Completion criterion: designers can tune without hidden code changes where intended.
5. 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
- [ ] Purpose and non-goals are clear.
- [ ] States, I/O, authority, and failures are specified.
- [ ] Edge cases and tuning levers exist.
- [ ] Acceptance and playtest criteria are observable.
- [ ] Open decisions have owners or BLOCKED labels.

## References and scripts
Use the approved brainstorming artifact, architecture contracts, data schemas, and existing telemetry vocabulary as inputs.