Claude Code Team Setup for UEFN — free, open, and it learns from its own mistakes
I build UEFN experiences for a living, and right now that means juggling around 50 islands at once. Keeping AI coding tools from mixing up projects, forgetting context, or repeating the same dumb Verse mistake on island #40 that got fixed on island #12 was turning into its own full-time job. So I built a proper team for it, and I’m giving it away.
This is a Claude Code setup: five specialized subagents, each with one narrow job, instead of one general-purpose assistant trying to do everything at once and stepping on its own toes.
- project-bootstrap — runs once per project. Maps an existing codebase and deduces its functional spec, or, if the island is empty, asks you the right questions instead of inventing a design. Either way it also runs an initial quality pass: pre-existing bugs, a prioritized bug-fixing roadmap, and concrete suggestions to improve retention in the first 5 minutes of gameplay.
- coder — writes and fixes Verse code, and never calls a task done while it fails to compile. Follows a strict compile-fix loop instead of leaving broken code behind with a shrug.
- qa-regression — hunts for regressions and bugs nobody asked about after every playtest, automatically, via a Claude Code hook. No manual step, no “I’ll check it later.”
- planner-docs — the only one that touches the documentation. Keeps status, roadmap, and bug backlog current so you never open a project after two months away and have no idea where you left off.
- release-gate — an honest go/no-go verdict before you ship or show something, based on what’s actually documented, not vibes.
The part I’m most proud of: a shared skill called uefn-lessons. Regular per-project memory resets every time you start a new island — something learned fixing a bug on project #12 is invisible on project #37. uefn-lessons doesn’t reset. It’s a single knowledge base, installed once, that every project’s agents read before writing code and add to whenever they hit a genuine Verse/UEFN/MCP gotcha — not project-specific stuff, but the kind of thing that’ll bite you again on the next island too. The more projects you run through this kit, the fewer blind spots you start each new one with. That’s the actual point of the whole thing: get measurably better at this over time, instead of relearning the same lessons 50 times.
A few setup steps are left manual on purpose — I’d rather you see exactly what’s getting installed than hide it behind a one-click script. That’s a transparency choice, not laziness.
Free to grab, fully documented setup guide included, works for one island or fifty.
Get it on Discord: FORTNITE - UEFN IT/EN Community - Mimmo_the_Root
If it saves you time, support code ROOT in the Item Shop, and come say hi: YouTube: https://www.youtube.com/@Mimmo_the_root · Twitch: mimmo_the_root - Twitch · X: mimmo the Root | UEFN | Fortnite | SAC: ROOT (@mimmo_the_root) / X · TikTok: https://www.tiktok.com/@mimmo_the_root · Instagram: https://www.instagram.com/mimmo_the_root
— Mimmo_the_root
Setup guide:
# Claude Code team setup for UEFN projects
## About the author
Built by **Mimmo_the_root**. This kit exists to solve my own problem: working with AI tools
across the ~50 islands I’ve built over the years, without losing my mind keeping them
straight. That’s the lens everything here was designed through.
A few setup steps are left manual on purpose, not because they couldn’t be scripted — I’d
rather you see and understand what’s being installed on your machine than hide it behind a
one-click installer. That’s a deliberate transparency choice, not a limitation.
If this kit saves you time, support code: **ROOT** in the Item Shop, and consider following
along:
- Discord (get the scripts, ask questions, see what’s next): FORTNITE - UEFN IT/EN Community - Mimmo_the_Root
- YouTube: https://www.youtube.com/@Mimmo_the_root
- Twitch: mimmo_the_root - Twitch
- X: mimmo the Root | UEFN | Fortnite | SAC: ROOT (@mimmo_the_root) / X
- TikTok: https://www.tiktok.com/@mimmo_the_root
- Instagram: https://www.instagram.com/mimmo_the_root
- Epic Games community page: Mimmo_the_root
## What this kit does
This is a Claude Code setup for developing UEFN (Unreal Editor for Fortnite) projects with a
small team of specialized subagents, designed so a developer working across many projects can
keep them from mixing together. Point it at a project and it handles:
1. **One-time setup**: reads a project’s existing code and maps its structure — or, if the
project is still empty, asks the owner for requirements instead of inventing them.
2. **Initial project analysis**: on an existing codebase, produces a functional spec deduced
from the code, a quality check that finds pre-existing bugs with a prioritized bug-fixing
roadmap, and concrete proposals to increase playtime and reduce drop-off in the first 5
minutes of gameplay.
3. **Ongoing development**: a coder agent that implements features and fixes, always following
a compile-and-fix loop so a task is never left in a state where the code doesn’t build.
4. **Automatic regression search and documentation updates** after every playtest session, via
a Claude Code hook — no manual step required.
5. **Release readiness**: a go/no-go verdict before a release or showcase, based on open bugs
and documented progress.
6. **Getting better across projects, not just within one**: a shared `uefn-lessons` skill (see
section 3b) that Verse/UEFN gotchas get added to as they’re discovered on any project, so
coding on island #37 benefits from what was learned on island #12 — not just from what
happened earlier in the same project.
Five agents divide the work, each with a narrow role: **project-bootstrap** (one-time initial
analysis or requirements gathering), **coder** (writes/fixes code), **qa-regression** (finds
bugs and regressions), **planner-docs** (keeps the documentation updated), and **release-gate**
(final go/no-go verdict). Details on each are in section 4 below.
—
## Two setup phases — read this first
Setup happens in two separate phases, done from two different folders. Mixing them up is the
most common source of confusion, so keep this straight:
| | Phase 1 — Environment setup | Phase 2 — Per-project setup |
|—|—|—|
| **How often** | Once per machine | Once per UEFN project |
| **You launch `claude` from** | The UEFN **installation** folder (e.g. `C:\Program Files\Epic Games\Fortnite`) | Each project’s own `Content/` folder |
| **What it does** | Gets the MCP server running and registers it with Claude Code | Installs the per-project scaffold (docs, agents’ working files, hooks) and connects it to that specific project |
| **Covered in** | Phase 1 below | Phase 2 below |
Do Phase 1 once, completely, before touching any individual project. Then repeat Phase 2 for
every project you want to use this kit on.
## Phase 1 — Environment setup (once per machine)
1. **Create the MCP server config.** In your **UEFN installation folder** (not a project
folder — on Windows typically `C:\Program Files\Epic Games\Fortnite`, adjust for your setup),
create a file named `.mcp.json` with this content:
```json
{
"mcpServers": {
"unreal-mcp": {
"type": "http",
"url": "http://127.0.0.1:8000/mcp"
}
}
}
```
2. **Start (or restart) UEFN.** If UEFN was already open, close it first — this file needs to
already be in place when UEFN starts for the server to be configured correctly.
3. **Enable the server**, in UEFN: **Edit > Editor Preferences > Model Context Protocol** →
turn on *Auto Start Server*.
4. **Verify the server is listening** (default port 8000, adjust if you changed it):
-
Windows: `netstat -ano | findstr :8000`
-
macOS/Linux: `lsof -i :8000` (or `netstat -an | grep 8000`)
A line naming the port as listening means it worked — move on. No output at all means it
didn’t: recheck steps 1-3 before continuing (file content and location, UEFN actually
restarted after the file was created, *Auto Start Server* actually toggled on).
5. **Install this kit’s user-level files:**
-
Copy everything from `user-level-agents/` into `~/.claude/agents/` (Windows:
`%USERPROFILE%\.claude\agents\`). Five files: coder, qa-regression, planner-docs,
project-bootstrap, release-gate.
-
Copy `user-level-memory/CLAUDE.md` into `~/.claude/CLAUDE.md`. If that file already
exists, paste this content at the end of it — don’t overwrite what’s already there.
-
Copy `user-level-skills/uefn-lessons/` into `~/.claude/skills/uefn-lessons/`. This is the
shared, cross-project knowledge base described below — install it once here so it’s
already in place before you set up your first project.
6. **Optional but recommended — register the server right now, as a sanity check.** You can
skip steps 6-8 entirely if you want: `Claude/SETUP-INSTRUCTIONS.md` (Phase 2, step 2) checks
for the server itself and registers it automatically the first time you set up a project, if
it isn’t registered yet. Doing it here too just confirms everything from step 1-4 actually
works before you move on to a real project. Open a terminal inside the UEFN installation
folder — the same one from step 1 — and launch `claude`.
7. **Register the MCP server once, at user scope**, so every future project on this machine
sees it automatically, with nothing to copy per project:
```
claude mcp add --transport http unreal-mcp --scope user http://127.0.0.1:8000/mcp
```
8. **Verify it’s registered**: `claude mcp list` should show `unreal-mcp` with scope “user”.
Optionally, ask Claude to list the available MCP tools to confirm the connection works
end-to-end, not just that it’s listed.
Phase 1 is done. You won’t repeat any of this for future projects — go to Phase 2 for each one.
## Phase 2 — Per-project setup (repeat for every project)
Prerequisite in UEFN, for this specific project: **Project Settings** → enable *Python Editor
Scripting* and *UEFN MCP Toolsets*. This one is per-project and can’t be skipped by Phase 1.
1. **Copy by hand** (drag & drop from your file explorer, or copy/paste) the entire **contents**
of this kit’s `project-template/` folder into the project’s `Content/` folder (see the next
section for why it goes inside `Content/` specifically, not next to it) — without renaming
or moving anything else already there.
2. **Open a terminal inside that `Content/` folder** — not the installation folder from Phase 1
— and launch `claude`.
3. Tell it: **“Read Claude/SETUP-INSTRUCTIONS.md and set up this project.”**
From there Claude Code takes over, following the included `Claude/SETUP-INSTRUCTIONS.md`: it
goes up one level to read the real project name (not “Content”) and writes it into `CLAUDE.md`,
double-checks the MCP connection is actually reachable from here, asks you for the missing
descriptive information (what the project is, its type, any particular conventions), lists the
available MCP tools and sets up the post-playtest hook’s matcher on its own, verifies the
project open in UEFN is the right one, and finally — only if everything checks out — uses
`project-bootstrap` for the first analysis (or to gather requirements if the level is empty).
`Claude/SETUP-INSTRUCTIONS.md` is only needed for this first configuration: afterward you can
leave it there (it doesn’t get in the way) or ask Claude to delete it.
## Why the MCP server is set up this way
The MCP server config lives at the UEFN installation level and gets registered with Claude Code
once, globally — not per project — because the server itself is a single instance for whichever
UEFN editor window is open: it’s not tied to any one project’s folder, and there’s nothing to
gain from repeating its setup 50 times. The `user` scope registration from Phase 1 step 7 saves
the connection in `~/.claude.json` and makes it available automatically in every Claude Code
project on this machine — verify it any time with `claude mcp list`. (If you’d rather scope
registration to a single project instead, `–scope project` does that, at the cost of repeating
step 7 for every project.)
**The one thing to always keep in mind:** that server always serves only the project *currently
open in UEFN* — not “whichever project’s folder Claude Code was launched from.” If you open
Claude Code inside a project’s `Content/` but UEFN still has a different project open, the MCP
tools will silently act on that other project. The simplest practical rule: open the project
you want to work on in UEFN first, before starting a Claude Code session for it. Every
MCP-using agent in this kit also double-checks this itself before touching anything (see
section 4).
## 1. Disk layout: work inside the project’s `Content/` folder
Deliberate choice: the per-project scaffold (`CLAUDE.md`, `.claude/`, `Claude/`) lives INSIDE
`Content/`, not next to it. `Content/` is the native subfolder UEFN creates on its own in every
project for assets and Verse code, and it’s the one covered by UEFN’s native save/cloud-sync —
putting our documentation, logs, and scripts inside it too means nothing is lost even if you
switch machines or reinstall. Open Claude Code directly inside `Content/`:
```
/ ← the real project folder (unique name, e.g. the island’s name)
└── Content/ ← UEFN’s NATIVE folder — this is where we launch `claude`
├── CLAUDE.md <- fixed location, required by Claude Code
├── .claude/
│ └── settings.json <- fixed location (hidden), required by Claude Code
├── Claude/ <- everything else we manage, clearly visible and separate
│ ├── docs/
│ │ ├── SPEC.md
│ │ ├── STATUS.md
│ │ ├── ROADMAP.md
│ │ ├── BUGS.md
│ │ ├── RETENTION-NOTES.md
│ │ └── RELEASE-READINESS.md
│ ├── logs/
│ ├── reference/
│ │ └── logger-template.verse.txt
│ └── hooks/
│ └── after-playtest.sh
└── (the rest of Content/: native assets, Verse, levels — whatever UEFN already manages)
```
**The technical problem this choice introduces, and how we solve it**: `Content/` is named
identically across every project. If the “project name” were read from the name of the folder
you launch `claude` from, it would always come out as “Content” — useless both for telling
projects apart and for the MCP safety check above. That’s why the real name isn’t read from the
current folder but from the one that CONTAINS `Content/` (one level up): a computation done
once during Phase 2 setup, written at the top of `CLAUDE.md`, and from then on only ever read —
never recomputed from the current folder’s name. If the name written in `CLAUDE.md` is
“Content” or “content,” setup was run from the wrong place (one level too high, not inside
`Content/`): it needs to be redone from inside `Content/`.
**To verify once**: since `Claude/` and `.claude/` aren’t assets or Verse but do live inside
`Content/`, check with a UEFN packaging/validation build that they don’t end up in the
experience shipped to players. If they do, consider renaming them so the cook step ignores
them, or moving back to a layout alongside `Content/` — see also the note at the top of
`CLAUDE.md`.
`.claude/` (with the dot, hidden) and `Claude/` (no dot, visible) are two different things and both are needed — it’s not a mistake that both exist. The first is a **reserved** folder that Claude Code itself reads for its own configuration — a fixed path the program looks for at startup, just like `.git/` for Git. It can’t be renamed, and `settings.json` can’t be moved elsewhere (into `Claude/`, for instance): if you do, Claude Code silently stops reading it — no error, the post-playtest automation hook and the configured permissions simply stop being applied, and you only notice because “nothing happens automatically anymore.” The second, `Claude/`, is entirely ours: you can open it, read it, reorganize it, no constraints — everything Claude Code doesn’t need to find in one exact spot goes here.
`CLAUDE.md` stays at the root you launch `claude` from — `Content/`, per the above — because that’s where Claude Code looks for it automatically at startup (alternatively it can also live at `.claude/CLAUDE.md`, but not inside `Claude/`).
## 2. The five agents in your team
Separating “who writes,” “who verifies,” and “who documents” is the recommended pattern for Claude Code agents, because each one works with a role narrowly scoped to its task and doesn’t interfere with the others. This kit adds a fourth agent for the most delicate moment (a project’s very first run, with no historical documentation yet) and a fifth to evaluate release readiness.
- **project-bootstrap** — use it ONCE ONLY, the first time on a project (while `Claude/docs/SPEC.md` is still empty). It figures out on its own whether it’s looking at existing code or a new project:
-
**Existing code** → maps the project structure (where assets, devices, Verse scripts are) into `Claude/docs/SPEC.md`; deduces its functional spec (flagging what needs confirming); does a quality check and creates `Claude/docs/BUGS.md` with a prioritized initial bug-fixing roadmap; proposes concrete improvements in `Claude/docs/RETENTION-NOTES.md` to increase playtime and reduce first-5-minutes drop-off.
-
**New/empty project** → doesn’t invent anything: it stops and asks targeted questions (goal, audience, main mechanics, references, constraints, what’s needed for a first playable MVP), then populates `Claude/docs/ROADMAP.md` and `Claude/docs/STATUS.md` with the answers.
- **coder** — writes and modifies code/Verse, implements features, refactors. Always reads `CLAUDE.md` and `Claude/docs/STATUS.md` before starting, so it picks up where things were left off instead of reinventing context.
- **qa-regression** — doesn’t write features: analyzes build/runtime logs, looks for regressions against what’s already marked “done,” and also flags bugs nobody explicitly asked about (“unseen” bugs), adding them to `Claude/docs/BUGS.md`. If the project is connected to UEFN via MCP, it can run a verification play-session — and it’s also invoked automatically after every playtest (see section 5).
- **planner-docs** — the only one that writes to the documentation files on a regular basis. Updates `Claude/docs/STATUS.md` (progress status, known issues, next step), `Claude/docs/ROADMAP.md` (planning), and prioritizes `Claude/docs/BUGS.md`, with dated, chronological entries.
- **release-gate** — use it before a release/showcase, not in day-to-day work. Doesn’t find new bugs and doesn’t write code: it reads the already-existing `BUGS.md`, `STATUS.md`, `ROADMAP.md`, and `SPEC.md` and gives a verdict (ready / ready with reservations / not ready) in `Claude/docs/RELEASE-READINESS.md`, with dated entries that don’t overwrite history.
If a specific project ever needs different agent behavior, create an agent with the same name inside that project’s `.claude/agents/` — it takes priority and only overrides it there.
## 3. Base rules that apply to every project
A handful of base rules — naming/organization, centralized logging, always-multiplayer, performance/FPS, state machine — aren’t specific to any one project: they apply across the board. Instead of repeating them in every project’s `CLAUDE.md`, they live in `user-level-memory/CLAUDE.md` (already copied to `~/.claude/CLAUDE.md` in Phase 1) — Claude Code loads this file in EVERY session, on any project, automatically.
In short, what it contains and where it’s applied:
1. **Naming/organization**: new content in `custom_*` folders (e.g. `custom_verse/`), organized by content/asset type/use per [Epic’s official documentation]( Starting and Organizing a Project in Fortnite | Fortnite Documentation | Epic Developer Community ). Also covers the **Outliner**: devices grouped into folders matching the experience’s actual areas (Lobby, Game Area 1, Devices, etc.), each named `_` (e.g. `teleport_lobby`) instead of left with a default name. `project-bootstrap` detects the convention already in use on an existing project and, if the Outliner is disorganized, proposes a reorganization plan for the owner to review rather than renaming things itself.
2. **Centralized logging**: the `DebugLoggingEnabled` pattern is in the scaffold as `Claude/reference/logger-template.verse.txt`. `coder` uses/adds it where missing; `qa-regression` cites it as the first move when logs aren’t enough to diagnose a bug (“add logging, don’t guess”).
3. **Always multiplayer**: `coder` and `qa-regression` must explicitly reason in multiplayer terms (server/client authority, multiple players on the same object), not just “works in solo preview.”
4. **Performance/FPS**: `qa-regression` flags framerate drops or suspicious logic during playtests, even when it isn’t a strict error.
5. **State machine**: default pattern for phase-based logic in new projects; targeted refactor proposal (not a full rewrite) when needed on existing flag-based projects.
6. **Header documentation in Verse code**: every file must have a comment block summarizing what it does, comments above logical sections, and a date + version number updated on every substantial change (there’s no Git, so this is the only history available). `coder` maintains it; `project-bootstrap` flags files still missing it in BUGS.md.
## 3b. Getting smarter across projects: the `uefn-lessons` skill
Per-project agent memory (`memory: project` on `coder`/`qa-regression`) is siloed to one
island — something learned fixing a bug on project #12 is invisible on project #37. That’s
fine for lessons that only make sense on that one project (this project’s specific devices,
this project’s design decisions), but a waste for lessons that are really about Verse, UEFN,
or the MCP tooling itself and would save time on every island.
For those, this kit adds a second, shared memory layer: `user-level-skills/uefn-lessons/`,
installed once (Phase 1, step 5) to `~/.claude/skills/uefn-lessons/SKILL.md`. `coder` and
`qa-regression` both read it before starting work, the same way they read their own project
memory, and both add a short entry to it — not to per-project memory — whenever they hit
something non-obvious that isn’t specific to the current project (a Verse syntax gotcha, a
device type that behaves differently than documented, a recurring MCP quirk). The file ships
with a handful of placeholder examples showing the expected one-line format; replace them with
real entries as they come up.
This is the actual mechanism for coding getting measurably better across your projects over
time, rather than each new island starting from the same blind spots as the last one — but
only if entries are added consistently rather than skipped when a session is focused on
finishing its task. Since it’s a single shared file across every project, occasionally skim it
yourself and prune anything that turned out to be wrong or too specific to have been added
there in the first place.
## 4. How to invoke them during work
Inside a Claude Code session opened inside the project’s `Content/`:
- Natural language: *“use the coder agent to implement the respawn checkpoint”*
- Explicit mention (guaranteed delegation): `@“coder (agent)” implement the respawn checkpoint`
- Claude can also pick the right agent on its own based on each one’s `description` field, if the task is clear.
### The very first session on a project
1. Open a terminal inside the project’s `Content/` folder (after Phase 2 setup above), launch `claude`.
2. Ask it to use **project-bootstrap**. If code already exists, within a few minutes you’ll have `Claude/docs/SPEC.md`, `Claude/docs/BUGS.md` (with a bug-fixing roadmap), and `Claude/docs/RETENTION-NOTES.md` ready to read and correct where needed. If the project is empty, it will ask you the necessary questions: answer them in the conversation.
3. From here on, for that project, use the normal workflow (below).
### Typical workflow for later sessions
1. Open a terminal inside the project’s `Content/`, launch `claude`.
2. Work with **coder** to implement/fix code.
3. Once changes are made, ask **qa-regression** to check logs and regressions (and, if connected to UEFN, run a verification play-session) — or let it fire automatically after the playtest (section 5).
4. Before closing, ask **planner-docs** to update `Claude/docs/STATUS.md` with what was done, known issues, and the next step.
5. Close the session: next time you reopen that project, just ask Claude to “read the project status” and it’ll immediately know where things were left off.
If you work on one project at a time, this flow is linear: open the right project in UEFN, open Claude Code inside its `Content/`, work, close, move to the next.
## 5. Automation: bug/regression search and doc updates after every playtest
Claude Code has a **hook** system: commands that fire on their own when a specific event happens — including `PostToolUse`, which fires right after a given tool has been used. This lets us hook into exactly the moment “a test play-session just ended,” which is different from “Claude Code was closed”: you can test multiple times in the same session and get an automatic check every time.
**Discovered through live testing:** the `unreal-mcp` server doesn’t expose a distinct tool per action (one for “start session,” one for “stop session,” etc.) — it exposes a single **generic dispatcher tool**, `mcp__unreal-mcp__call_tool`, which internally routes all of its toolsets’ actions via the call’s payload. This means the `matcher` alone can’t distinguish “a play-session just ended” from any other MCP call (reading a Verse file, moving a device, etc.) — it would fire on everything.
So in the scaffold’s `.claude/settings.json`, the matcher fires on every call to the dispatcher, and the real filter lives inside the hook script, which reads the hook’s JSON payload from stdin:
```json
“hooks”: {
“PostToolUse”: [
{
"matcher": "mcp__unreal-mcp__call_tool",
"hooks": \[
{
"type": "command",
"command": "powershell.exe -NoProfile -ExecutionPolicy Bypass -File \\"${CLAUDE_PROJECT_DIR}/Claude/hooks/after-playtest.ps1\\"",
"timeout": 300
}
\]
}
]
}
```
`Claude/hooks/after-playtest.ps1` (PowerShell — use it if bash isn’t available on the machine, as on “pure” Windows; `after-playtest.sh` is the equivalent for bash/WSL/Git Bash) reads the payload from stdin and checks whether this specific call is really a session/game stop (it looks for `stopgame`/`stopsession` in the raw payload text, without depending on one exact JSON field that might change between server versions). Only if it matches:
1. It runs **qa-regression** in non-interactive mode, which analyzes logs and state and adds any problem found to `Claude/docs/BUGS.md` (under “Newly reported”).
2. It runs **planner-docs**, which updates `Claude/docs/STATUS.md` and moves/prioritizes the new bugs in the backlog.
3. It also saves everything to a log file inside `Claude/logs/`, so there’s always a readable trace of what happened.
On any other MCP call, the script exits immediately without doing anything — otherwise every single Verse file read would restart the whole check, wasting tokens.
**One thing to verify once per project** (included in `Claude/SETUP-INSTRUCTIONS.md`): run a test play-session and check that the log in `Claude/logs/` appears only when you stop it, not on every MCP action. If it never fires, or always fires, this server’s payload might not contain the expected strings: uncomment the debug line at the top of the script to log the raw payload once and adjust the pattern accordingly.
**Tip:** let it run automatically, but check `Claude/docs/BUGS.md` and the logs in `Claude/logs/` every so often in the first few weeks, so you can correct course if you notice inaccurate reports.
## 6. Scaling to many projects: a dashboard idea
Once you want a bird’s-eye view across all your projects (instead of opening them one by one), the fact that every `Claude/docs/STATUS.md` follows the same format makes it easy to build a script that scans every project folder and reads `Claude/docs/STATUS.md` from each one, producing a single summary (a table with last update, next step, open issues). This isn’t included in the kit itself, since it depends on how and where projects are laid out on disk — it’s a natural next step to build once you have a few projects set up with this kit.
## Heads up: there are TWO files called `settings.json`, in two different places — they are not the same thing
A common source of confusion, so it’s worth spelling out. Your machine has (or will have) two folders both named `.claude`, in different places, each with its own `settings.json` that should NEVER be merged by hand:
| | `~/.claude/settings.json` | `/.claude/settings.json` |
|—|—|—|
| **Where it lives** | In your user folder (one, on the whole machine) | Inside EVERY project folder (one copy per project) |
| **Who creates it** | Claude Code itself, the first time it’s installed/started | The kit — you’ll find it ready in `project-template/.claude/settings.json`, to copy |
| **What it contains** | Your personal app preferences: `theme`, `autoUpdatesChannel`, etc. | THAT project’s post-playtest automation hook and permissions |
| **What to do with it** | **Don’t touch it.** It has nothing to do with this kit, leave it as is | Copy it (or better: copy all of `project-template/`) into every project, as is |
Claude Code reads both automatically and combines them on its own (project settings are layered on top of user settings) — you never need to paste one’s content into the other.
—
### Sources
- [Unreal MCP is now available in UEFN — Fortnite.com](https://www.fortnite.com/news/unreal-mcp-is-now-available-in-uefn)
- [UEFN MCP — official Epic Games documentation]( UEFN MCP | Fortnite Documentation | Epic Developer Community ) — note: Epic’s own instructions describe a per-project `.mcp.json` created in each project’s root folder instead of the machine-level setup above. This kit uses the machine-level approach described in Phase 1 instead, confirmed working across multiple projects; if you hit issues with it, Epic’s per-project method is the documented fallback.
- [Claude Code — Subagents]( Create custom subagents - Claude Code Docs )
- [Claude Code — Settings]( Claude Code settings - Claude Code Docs )
- [Claude Code — Hooks](Hooks reference - Claude Code Docs)