fxgl-project-starter

name	fxgl-project-starter
description	Start a new FXGL project through a bounded Socratic discovery flow, then turn the answers into a docs-first starter specification with ADRs, an arc42-lite architecture summary, and Mermaid use-case diagrams before scaffolding the project itself. Continue using the same questioning approach for initialization choices, and require documentation updates plus automated tests for every implemented step.
triggers	["start fxgl project","bootstrap new game","fxgl starter","project inception","socratic questions","arc42","adr","docs first","architecture brief","scaffold fxgl"]
compatibility	Java 17+, FXGL 21.x. Works best when combined with fxgl-game-lifecycle and the relevant game-type skills chosen during project discovery.
category	fxgl/workflow
tags	["fxgl","java","javafx","workflow","starter","documentation","testing"]
metadata	{"author":"fxgl-skills","version":"1.0","fxgl-version":"21.1"}
allowed-tools	["Read","Write","Edit","Bash"]

FXGL Project Starter

Purpose

Use this skill when the goal is not just "write some FXGL code", but to start a project correctly:

1. discover what the user actually wants to build
2. turn that into a reviewable project specification
3. scaffold the project only after the documentation is agreed
4. keep docs, implementation, and tests synchronized from the first commit

This is a workflow/orchestration skill. It should usually invoke more specialized skills after the starter specification is complete.

Execution Modes

This skill must support two modes.

1. Interactive Socratic Mode

Ask one focused question at a time. Use the bounded question flow from references/question-flow.md.

2. Default Mode

If no interactive user is available, proceed with conservative defaults:

• Java
• Maven
• 2D game
• local single-player
• desktop target
• no networking
• no save/load unless explicitly requested
• no AI/ML features unless explicitly requested

Never block indefinitely waiting for answers if the runtime is non-interactive.

Bounded Socratic Rule

Do not ask unbounded exploratory questions forever. Ask just enough to unlock project decisions, then move to documentation.

Minimum topics to resolve:

1. game/app type
2. target platform
3. 2D or 3D
4. input model
5. progression / save expectations
6. technical baseline (Java, build tool, modules)

If the answers remain partial after the bounded flow, document the assumptions and proceed.

Docs-First Checkpoint

Before generating any Java source files, verify that the starter specification exists and is populated. The minimum documentation set is:

• docs/project-brief.md
• docs/use-cases/core-use-cases.md
• docs/architecture/arc42-lite.md
• at least one ADR under docs/architecture/adr/

If these files do not exist yet, create them first.

Required Documentation Outputs

Project Brief

A short, easy-to-scan summary for humans:

• one-paragraph game / app summary