# Gsp Project State Assessment

> Use before major game work to classify the repo as greenfield, prelaunch, shipped, or live-risky.

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

---


# Game Project State Assessment

## Goal
Determine what kind of project this is **before** choosing scope, architecture, or task sizing.

## Outputs

Follow the `gsp-orchestrator` output strategy:
- **inline** (default): present project state assessment in conversation.
- **minimal** or **full**: write `docs/game-studio/project-state.md` using `./shared/templates/project-state-assessment.md`.

Use:
- `./schemas/project-state.schema.json`

## What to inspect
Look for evidence such as:
- existing source tree size and maturity
- deployment configs
- CI / CD pipelines
- release notes / changelogs
- analytics / telemetry
- app store or distribution metadata
- save data, migrations, versioning, or liveops systems
- production environment files or operational runbooks
- existing user-facing docs or screenshots

## Classification rules
- **greenfield**: empty repo, tiny scaffold, or explicit from-scratch instruction
- **existing prototype / prelaunch**: meaningful code exists, but little evidence of live-product operational risk
- **shipped product**: release / deployment / store / production signals exist
- **live-risky**: shipped product plus clear signals of live users, data compatibility, or operational constraints

## Unknowns
If critical status cannot be inferred, ask only a few decisive questions.
Do not ask long interviews.