playbooks

home / skills / simhacker / moollm / exit

exit skill

/skills/exit

This skill helps define and navigate exits between memory palace rooms, enabling guarded, hidden, and metaphorical transitions for flexible journey design.

npx playbooks add skill simhacker/moollm --skill exit

Review the files below or copy the command above to add this skill to your agents.

Files (6)
SKILL.md
2.9 KB
---
name: exit
description: Navigation links between rooms — the edges of the memory palace
allowed-tools:
  - read_file
  - write_file
tier: 1
protocol: PIE-MENU-TOPOLOGY
tags: [moollm, navigation, room, topology, pie-menu]
related: [room, adventure, memory-palace]
adversary: dead-end
---

# Exit

> *"Every exit is a promise of adventure."*
> — The Gezelligheid Grotto Guest Book

---

## What Is It?

An **Exit** is a navigation link connecting one room to another. In MOOLLM's spatial architecture, exits are the EDGES of the memory palace graph.

Exits can be:
- **Simple** — just a destination
- **Guarded** — require conditions to pass
- **Hidden** — discoverable through exploration
- **Metaphysical** — conceptual rather than physical

---

## Pie Menu Topology

Don Hopkins' **pie menu** insight: direction IS meaning.

| Direction | Purpose |
|-----------|---------|
| **N/S/E/W** | "Highway" links to major rooms |
| **NW/NE/SW/SE** | "Grid" links to expandable sub-rooms |
| **UP/DOWN** | Vertical transitions |
| **IN/OUT** | Conceptual transitions |

Cardinal directions form the **spiderweb** — the main navigation network.
Diagonal directions form **grids** — expandable arrays of sub-rooms.

---

## Guard System

Guards are natural language conditions that control access:

```yaml
guard: "player has the brass key"
guard_js: "(ctx) => ctx.player.inventory.includes('brass-key')"
guard_py: "lambda ctx: 'brass-key' in ctx.player.inventory"
```

The `guard` field contains human-readable intent.
The `guard_js` and `guard_py` fields contain compiled code.

The adventure compiler emits `COMPILE_EXPRESSION` events for guards that need compilation.

---

## Exit Types

### Simple Exit

```yaml
north:
  destination: ../maze/room-a/
  description: "A dark passage leads north."
```

### Guarded Exit

```yaml
east:
  destination: ../treasury/
  description: "A heavy iron door."
  guard: "player has treasury key"
  locked: true
  lock_message: "The door won't budge."
  unlock_with: "treasury-key"
```

### Hidden Exit

```yaml
down:
  destination: ../secret-cellar/
  hidden: true
  hint: "The rug seems oddly placed..."
```

### One-Way Exit

```yaml
down:
  destination: ../pit/
  one_way: true
  description: "A slide into darkness. No going back."
```

### Metaphysical Exit

```yaml
inward:
  destination: ../consciousness/
  metaphysical: true
  description: "Close your eyes and think about who you really are."
```

---

## Memory Palace Integration

From Frances Yates' "The Art of Memory":

> *"The method of loci places items at specific locations along an imagined journey."*

Every exit is a **doorway** in the memory palace. The direction encodes meaning. Players navigate by spatial memory.

---

## Related Skills

- [room](../room/) — Where exits live
- [adventure](../adventure/) — Uses exits for navigation
- [memory-palace](../memory-palace/) — Exits as mnemonic paths

---

## Protocol Symbol

```
PIE-MENU-TOPOLOGY — Direction IS meaning
```

Overview

This skill models navigation links between rooms — the edges of a memory palace graph. It defines typed exits (simple, guarded, hidden, one-way, metaphysical) and encodes directional topology so direction carries semantic meaning. The skill lets designers declare guards, hints, and lock behavior to shape traversal and discovery.

How this skill works

Exits are edges that point from one room to a destination path and can carry metadata: descriptions, visibility flags, lock state, and guard expressions. Guards are written as human intent plus optional compiled expressions (JavaScript or Python) that the runtime evaluates to allow or deny passage. Directional topology (N/S/E/W, diagonals, up/down, in/out) is used to organize major routes, sub-grids, and conceptual transitions.

When to use it

  • Connect rooms in a navigation graph where direction should carry meaning.
  • Restrict access with condition-based locks or inventory checks.
  • Hide secret paths that require exploration or hints to reveal.
  • Model one-way transitions like slides or irreversible decisions.
  • Represent conceptual or inner-state transitions as metaphysical exits.

Best practices

  • Use cardinal directions for main arteries and diagonals for expandable sub-areas.
  • Keep guard text as human-readable intent and add compiled guard expressions for runtime checks.
  • Provide clear lock_message and unlock_with fields to guide players when access is denied.
  • Mark hidden exits with concise hints tied to room descriptions to encourage discovery.
  • Use metaphysical exits sparingly and attach evocative descriptions to signal non-physical transitions.

Example use cases

  • A dungeon map where north/south/east/west link major chambers and diagonals open side rooms.
  • A treasure room guarded by a key check that can be expressed as human intent and runtime code.
  • A secret cellar reachable via a hidden 'down' exit with a rug hint in the main hall.
  • A one-way slide that drops the player into a pit with no return option.
  • An introspective path that shifts a player into a conceptual 'consciousness' room.

FAQ

How do guards work?

Guards include a human-readable intent and optional compiled expressions (guard_js or guard_py). The runtime evaluates compiled expressions against the current context to decide access.

What is the pie-menu topology?

It assigns meaning to directions: cardinals form main highways, diagonals create grids of sub-rooms, up/down handle vertical movement, and in/out represent conceptual transitions.