SF
STS Forge

/map-design

Discover what a project contains by scanning source code and content folders, then populate the Design wiki with categories based on what actually exists.

Scans Content/ directories, C++ class hierarchies, and config files to discover what your project actually contains, then writes that into Docs/Design/. Makes no genre assumptions: it works for shooters, puzzles, racing, simulations, and any other UE project.

Trigger phrases#

/map-design, populate design wiki, scan game design, what does this project contain.

What it does#

/map-design runs a five-tier discovery process, then confirms categories with you before writing anything.

Tier 1: Content directory scanning#

Globs Content/ top-level subdirectories, counts assets per directory, and notes naming conventions (BP_, GA_, GE_, WBP_, SK_, SM_). High asset-count directories are flagged as primary categories.

Tier 2: C++ source mining#

Greps Source/ for UCLASS declarations and groups them by parent class. Major hierarchies (many subclasses of a shared base) reveal the project's primary gameplay concepts. It also reads game mode headers for rules, scoring, and win conditions, and checks config files for default maps and enabled subsystems.

Tier 3: Config file analysis#

Reads Config/DefaultGame.ini and Config/DefaultEngine.ini for the game mode class, map list, and enabled subsystems.

Tier 4: Plugin commandlet (optional)#

If a commandlet is configured in project-config.json under plugins.commandlets, it exports Blueprint CDO properties. Most projects do not have this configured.

Tier 5: User confirmation#

After Tiers 1-4, /map-design presents everything it found, grouped by importance, and asks you to confirm, rename, merge, or split categories. It also asks for design context that cannot be derived from code: gameplay loop description, key design pillars, and target audience.

How categories are created#

Categories are not predetermined. The skill builds a list from what it finds:

Content/Characters/   -> 12 subdirs, BP_ prefixed  -> "Characters"
Content/Vehicles/     -> 5 subdirs, BP_ prefixed   -> "Vehicles"
Content/Maps/         -> 8 .umap files             -> "Maps/Levels"
Content/UI/           -> 20 WBP_ files             -> "UI/Widgets"

After you confirm the list, it creates Docs/Design/<Category>/index.md for each category, plus individual entity pages where enough data exists.

Non-destructive merging#

Auto-generated sections are wrapped in markers:

<!-- auto: map-design YYYY-MM-DD -->
...generated content...
<!-- /auto -->

Manual prose outside these markers is always preserved. Re-running /map-design discovers new content and updates marked sections without touching anything you wrote manually.

Confidence markers#

Each page carries a confidence level based on where the data came from:

Level Source
High C++ source code or explicit config files
Medium Content/ directory naming conventions
Manual User input during the interactive phase
Unknown Gaps that still need user input

Output summary#

After completing the scan:

| Category | Source | Assets Found | C++ Classes | Pages Created |
|----------|--------|-------------|-------------|---------------|

Limitations#

/map-design cannot read Blueprint graph data or CDO property values from .uasset binary files. For projects with significant Blueprint-only logic:

  • Export data from the editor (right-click an asset, Asset Actions, Export)
  • Configure a commandlet plugin via /setup if one is available
  • Manually update Docs/Design/ pages as gameplay evolves

The Design wiki captures what gameplay is supposed to do. The Dev wiki captures how it is implemented in code. Both are used together when working on gameplay tasks.