Wiki System

The Design/ and Dev/ dual wiki system: how it is structured, populated, and used.

AI ForgeKit maintains two persistent wikis in your project's Docs/ directory. They ground the AI in your specific project rather than generic UE5 knowledge.

The two wikis#

Design wiki: `Docs/Design/`#

Captures what your game is supposed to do.

Categories in the Design wiki are not fixed. /map-design discovers them at runtime by reading your project's content: GDD files, asset directories, Blueprint folders, and any existing design notes. The structure of your Docs/Design/ reflects what your project actually contains, not a preset template.

The Design wiki is the source of truth for gameplay intent. When working on a feature or bug, the AI reads the relevant Design page to understand what the mechanic should do before reading the C++ implementation.

Populated by: /map-design

Dev wiki: `Docs/Dev/`#

Captures how your code implements game systems:

Systems: Docs/Dev/Systems/<system>/overview.md (discovered on-demand by /map-codebase based on module definitions, class hierarchies, and directory structure)
Modules: Docs/Dev/Modules/module-map.md
Symbols: Docs/Dev/Symbols/<ClassName>.md (central base classes)

The Dev wiki contains real class names, file paths, and module dependencies extracted directly from your source tree. It is the AI's map of your project's actual architecture.

Populated by: /map-codebase

The `_working/` ephemeral directory#

Docs/_working/ holds transient data that does not belong in the wiki:

Docs/_working/
  state/              — machine-local session state
    project-config.json    — generated by /setup
    SESSION_SNAPSHOT.json  — generated by /state-save
    SESSION_CONTEXT.md     — generated by /state-save
    build-status.json      — generated by /build
    archive/               — dated snapshots (last 3 kept)
  sessions/           — ephemeral per-task working files
    <task-name>.md         — implementation plans from planner
    validate-<topic>/      — validation loop iteration files
  notes/              — quick notes from /remember (monthly files)
  retro/              — self-learning friction logs (monthly files)
    LAST_PROCESSED.json
    Proposals/
    Backups/

Everything in _working/ is ephemeral and excluded from VCS. See Installation for the exact .gitignore / .p4ignore entries.

How the wikis are used#

On-demand loading#

The AI does not load the full wiki into context at session start. It loads Docs/index.md first, then reads specific pages only when needed for the current task. This keeps context usage low.

Dual-wiki retrieval for gameplay tasks: For a combat bug, the AI loads the relevant Design page first (what the mechanic should do) and the Dev Systems page for Combat (how it is implemented). Both together provide full context.

`/recall` searches all layers#

/recall searches Design wiki, Dev wiki, working notes, and Decisions in one query. It returns results with source attribution so you know which layer answered the question.

Non-destructive updates#

Both /map-codebase and /map-design use non-destructive merging:

/map-codebase only updates "Key Files" sections and metadata. Manual prose is never touched.
/map-design uses  markers to delimit generated sections. Content outside markers is preserved.

Both skills are safe to re-run at any time.

Confidence markers in the Dev wiki#

System pages track confidence in their data:

Confidence	Meaning
High	Classes confirmed by scanning source headers
Medium	Classes inferred from naming patterns or directory structure
Unknown / `(removed)`	Classes in prior scan that no longer exist on disk

Keeping the wikis current#

The wikis are not automatically updated on every code change. Update them:

After adding a new system or module, run /map-codebase
After adding characters, abilities, or weapons, run /map-design
After a major refactor that moves or renames classes, run /map-codebase
After gameplay design changes, update Docs/Design/ manually or run /map-design

The /health-check skill checks for wiki pages with "Last Updated" older than 30 days and flags them as WARN.

The wiki pages in Docs/Design/ and Docs/Dev/ should be committed to VCS and shared with the whole team. They are plain markdown. No machine-specific paths or credentials. The entire team benefits from a shared picture of the project's design and architecture.

The _working/ directory is excluded from VCS because it contains machine-local state (absolute paths in project-config.json, session state that is specific to one developer's conversation).

The two wikis#

Design wiki: Docs/Design/#

Dev wiki: Docs/Dev/#

The _working/ ephemeral directory#