/map-codebase
Scan the project source tree and populate the Dev wiki with real class and module data, discovering system boundaries from what actually exists in the code.
Scans Source/ for UE reflection macro declarations and writes real class data
into the Dev wiki at Docs/Dev/. Systems are discovered from the code itself,
not assigned from a fixed list.
Trigger phrases#
/map-codebase, map the codebase, scan source files, populate area maps,
update dev wiki, what classes are in my project.
Also runs automatically after major refactors that add or move files.
Do NOT use for: exploring a single file (use the explorer agent), or code review (use /review).
What it does#
/map-codebase runs a structured scan in seven steps:
- Check VCS: warns if source files have uncommitted changes and asks for confirmation
- Discover modules: globs for
*.Build.csfiles to find all UE modules - Extract declarations: greps headers for
UCLASS,USTRUCT,UENUM,UINTERFACE - Discover system boundaries: groups classes by module, inheritance hierarchy, and directory structure to determine what systems exist
- Update system pages: merges discovered classes into
Docs/Dev/Systems/pages - Update module map: writes
Docs/Dev/Modules/module-map.mdwith Build.cs dependency data - Create symbol pages (optional): for central base classes referenced across many systems
How systems are discovered#
Systems are not predetermined. The skill creates them on demand from what it finds in the codebase, using three signals:
- Module boundaries: each
Build.csdefines a module. Modules with 10 or more classes likely represent a distinct system, named after the module. - Inheritance hierarchies: any base class with 5 or more subclasses defines a
system. "15 classes inherit from
AWeapon" becomes a "Weapons" system. - Directory structure:
Source/Inventory/with 10 files becomes an "Inventory" system.
Groups that overlap across these three signals are merged, keeping the most
descriptive name. Common UE patterns (UGameplayAbility subclasses, replicated
classes with RPCs, UInputAction) are recognized when present, but never assumed.
Classes that do not fit any discovered system are listed as "unclassified" in the summary. If three or more unclassified classes share a clear theme, the skill suggests creating a new system for them.
Non-destructive merging#
/map-codebase is safe to re-run at any time:
- Manually written prose, notes, and architecture context in system pages is never touched
- Only "Key Files" sections and metadata (Last Updated, Confidence) are updated
- Classes that no longer exist on disk are marked
(removed)rather than deleted - Only content the skill originally generated is ever overwritten
Auto-generated sections are wrapped in markers:
<!-- auto: map-codebase YYYY-MM-DD -->
<!-- /auto -->
Dev wiki format#
System pages receive a Key Files table:
## Key Files
| File | Type | Description |
|------|------|-------------|
| Source/Combat/Abilities/GA_MeleeAttack.h | UCLASS (UGameplayAbility) | Melee attack ability |
| Source/Combat/Effects/GE_ApplyDamage.h | UCLASS (UGameplayEffect) | Base damage effect |
Confidence is set to High when the system boundary is clear (explicit module or large hierarchy), and Medium when it is inferred from directory layout.
Output summary#
After completing the scan:
## Codebase Map Summary
Scanned: YYYY-MM-DD HH:MM
### Modules Discovered
| Module | Files | Headers | Sources |
### Systems Discovered
| System | Source (module/hierarchy/directory) | Classes | Confidence |
### Unclassified
- (classes that did not fit any discovered system)
### Pages Created/Updated
- (list of all Docs/Dev/ files changed)
When to run#
- After
/setupon first installation (the wizard offers this automatically) - After adding a new system or module
- After a major refactor that moves or renames classes
- Whenever the Dev wiki feels out of date
For single-file exploration, ask directly or use the explorer agent.