# Ue5 Phase Bans > Decide which UE5 systems are deliberately out of scope for the current phase and write bans an agent will actually respect — replication and networking, ability and gameplay-effect frameworks, Mass Entity and ECS paths, World Partition and large-world streaming, and test infrastructure beyond the minimum. Use when starting a prototype or vertical slice, when an agent proposes a heavyweight subsystem for a small problem, when an installed skill recommends a system the phase does not need, when scope keeps growing without a decision, or when deciding whether a ban should now lift. - Skill: `lichamnesia/ue5-phase-bans` (Agent Skill, multi-file: 5 files) - Install (CLI): `npx skillmds@latest add lichamnesia/ue5-phase-bans` - Raw SKILL.md: https://api.skillmd.com/api/skills/lichamnesia/ue5-phase-bans/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: lichamnesia (https://skillmd.com/u/lichamnesia) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/lichamnesia/ue5-phase-bans --- # UE5 Phase Bans Every skill you install argues for its own subject. A replication skill argues for replication. An ability-system skill argues for abilities. Each argument is correct in general and expensive right now, and no skill can tell you that, because no skill knows your phase. The result is the most common failure in agent-driven UE5 work: an agent that solves the problem you have with the architecture of a problem you do not have yet. It is invisible while it happens, because every individual decision looks like good engineering. A ban is how the phase talks back. ## Settle the ban list before the first feature 1. **Name the phase in one sentence** — what this phase must prove, and what it does not have to prove. A ban list without this is arbitrary. 2. **Ban by structural cost, not by taste.** The test: if adopting it later means touching every system you have already written, it is a ban candidate. If it is a container choice or a naming convention, it is not. 3. **Write each ban with all four parts** — banned thing, reason tied to *this* phase, what to do instead, and the condition that lifts it. A ban missing "instead" gets rationalized around, because the agent still has a real problem to solve. See [`references/writing-a-ban.md`](references/writing-a-ban.md). 4. **Start from the five defaults** in [`references/ban-catalog.md`](references/ban-catalog.md) and delete the ones that do not apply. Four are widely understood; the fifth — test infrastructure past the minimum — is the one almost nobody bans and often the largest unbanned cost. 5. **Record the result** in the project context file via `ue5-project-context`. A ban that lives only in a chat message is not a ban. 6. **Adjudicate conflicts in favor of the ban, and log them.** The procedure is in [`references/writing-a-ban.md`](references/writing-a-ban.md) — follow the ban, record one line, keep going. Do not stop to ask; the ban already is the answer. Load only what applies: - [`references/ban-catalog.md`](references/ban-catalog.md) — the five defaults, each with its structural cost, the tell that it has been breached, and what lifts it. - [`references/writing-a-ban.md`](references/writing-a-ban.md) — the four-part row, worked examples, conflict logging, and how to lift a ban without erasing the history. - [`references/breach-tells.md`](references/breach-tells.md) — symptoms that a ban is being worked around rather than followed, and what each one means. ## Required answer format When this skill fires, return: 1. **Phase statement** — one sentence: what this phase proves, and what it does not. 2. **Ban table** — banned thing | reason tied to this phase | instead | lifts when. 3. **Explicitly not banned** — systems considered and left available, with why. This prevents the list from being read as "everything heavy is forbidden". 4. **Conflicts this session** — any skill recommendation overridden by a ban, one line each. 5. **Breach findings** — any tell from `references/breach-tells.md` observed in the current code, with the file that showed it. 6. **Lift candidates** — bans whose condition now appears met, with the evidence. ## Hard rules - A ban outranks any installed skill, including a well-written one. Skill quality is not evidence about your phase. - Never ban without an alternative. "Do not use X" with no "use Y instead" is an instruction to improvise, and improvisation is what the ban was supposed to prevent. - Never ban without a lift condition. A ban that cannot be lifted reads as dogma, and the next agent will route around it silently rather than argue. - Do not ban cheap, reversible things. Every unnecessary row makes the load-bearing rows less likely to be read. - Lifting is a decision with a date and a reason, recorded by moving the row to a lifted table — never by deleting it. A later reader must be able to tell "we chose to add this" from "nobody thought about it". - A ban overridden three times in one phase is not a discipline problem. It is evidence the phase scope was drawn wrong; escalate it instead of enforcing harder. ## Verification Two checks, both cheap: **Grep check.** For each banned system, grep the codebase for its signature symbols. A ban on replication that returns hits in gameplay code has been breached. Record the command and its output date next to the ban row; a ban nobody has checked is a hope. **Cold-agent check.** Start a session with no history, give it the project context file and a task that a banned system would naturally solve, and see what it proposes. If it proposes the banned system, the ban's reason is not written clearly enough to survive contact with a fresh reader — which is the only condition under which it matters. ## Scope This skill decides *sequencing*, not merit. Every system named here is legitimate and has a phase in which it is right; nothing in the catalog is an argument that a system is bad. It does not cover: engine feature maturity as a reason to avoid something (that is `ue5-feature-maturity-gate` — a different question with a different lift condition), team process or sprint planning, or dependency and third-party plugin policy.