Skip to main content

room

Rooms are intertwingled navigable activation context maps. Entering = calling. Exiting = returning.

来源信息

仓库
SimHacker/moollm
最近来源活动
2026年8月25日 01:44
检测到的 SKILL.md 语言
英语
星标
60
Forks
5

安装方式

默认使用会先检查来源的 Prompt;你也可以切换为直接命令,或下载本地副本。

检查来源文件

决定是否安装前,请先阅读 SKILL.md,以及 SkillsMP 当前展示的配套文件。

文件资源管理器
8 个文件

正在显示 SKILL.md

SKILL.md
来源说明 · 只读预览
name
room
description
Rooms are intertwingled navigable activation context maps. Entering = calling. Exiting = returning.
license
MIT
tier
1
allowed-tools
["read_file","write_file"]
related
["card","container","exit","object","memory-palace","adventure","character","soul","representation-ethics","incarnation","data-flow","multi-presence","plain-text"]
tags
["moollm","navigation","space","directory","moo","adventure","framing","ethics"]
# Room > **Rooms are intertwingled navigable activation context maps. Entering = calling. Exiting = returning.** Ethics (venue / framing inheritance): [ETHICS.md](ETHICS.md) · stack: [soul/ETHICS.md](../soul/ETHICS.md) Directories as cognitive spaces where [cards](../card/) come to life. ## The Metaphor | Filesystem | Simulation | Programming | |------------|------------|-------------| | Directory | Room | Stack frame | | `cd room/` | Enter | Function call | | `cd ..` | Exit | Return | | Files in dir | Active entities | Local variables | | Links | Exits/doors | Calls to other functions | ## Room Anatomy ``` room-name/ ├── ROOM.yml # Room definition (REQUIRED!) ├── README.md # Room's voice (optional) ├── CARD.yml # Card sidecar (optional) ├── character-*.yml # NPCs embedded in room ├── object-*.yml # Objects in room ├── inbox/ # Objects thrown INTO this room ├── outbox/ # Objects staged to throw OUT ├── region/ # Sub-region of this room │ └── ROOM.yml # Region must also declare itself! └── nested-room/ # Full sub-room (different location) └── ROOM.yml ``` --- ## Regions vs Sub-Rooms ### What's a Region? A **region** is a sub-directory that represents a **portion of the same room** — like the stage area of the pub, or the back corner of a library. ```yaml # pub/ROOM.yml room: name: "The Gezelligheid Grotto Pub" # Regions are PARTS of this room regions: stage: path: "stage/" description: "The performance stage" visibility: public back-room: path: "back-room/" description: "Private back room" visibility: private requires: "bartender approval" bar: path: "bar/" description: "The bar counter area" ``` ### Regions Have Rules Each region can have its own: ```yaml # pub/back-room/ROOM.yml room: name: "Back Room" type: region # Marks as region, not full room parent: "../" # Part of parent room # Access control access: visibility: private # Not visible to everyone requires: "bartender approval OR staff badge" who_allowed: - "characters/staff/*" - "player if has_flag('vip_access')" who_denied: - "characters/troublemakers/*" # Ethics & behavior rules: - "No recording" - "Confidential conversations" - "Staff only by default" # Privacy privacy: eavesdropping: false # Can't hear from outside visible_from_parent: false # Can't see inside from pub # What happens in the back room... narrative: on_enter: "The door closes behind you with a soft click." on_exit: "You return to the bustling pub." ``` ### Visibility Types | Type | Description | |------|-------------| | `public` | Anyone can see and enter | | `visible` | Can see but may need permission to enter | | `private` | Hidden unless you know about it | | `secret` | Hidden AND requires discovery | ### Region vs Full Sub-Room | Feature | Region | Sub-Room | |---------|--------|----------| | Part of parent? | Yes | No | | Own identity? | Partial | Full | | Exit returns to? | Parent | Varies | | Shares parent context? | Yes | No | | Type field | `type: region` | `type: room` | --- ## Directory Type Declaration ### The Rule **Every directory in an adventure MUST declare what it is.** | Directory Type | Declaration File | |----------------|------------------| | Room | `ROOM.yml` | | Region | `ROOM.yml` (with `type: region`) | | Character | `CHARACTER.yml` | | Adventure root | `ADVENTURE.yml` | | Personas | `ROOM.yml` (with `type: personas`) | | Storage | `ROOM.yml` (with `type: storage`) | ### Lint Error: Undeclared Directory ```yaml # LINT ERROR: Directory without type declaration - type: MISSING_TYPE_DECLARATION severity: WARNING path: "pub/mysterious-corner/" message: "Directory has no ROOM.yml, CHARACTER.yml, or other type declaration" suggestion: "Add ROOM.yml with appropriate type field" ``` ### Valid Non-Room Directories Some directories aren't rooms and that's OK: ```yaml # These don't need ROOM.yml: messages/ # Mail storage (system) inbox/ # Postal inbox (system) outbox/ # Postal outbox (system) sessions/ # Session logs (meta) images/ # Asset storage (meta) ``` ### Marking System Directories ```yaml # Alternative: mark as system directory # pub/messages/.meta.yml meta: type: system purpose: "Mail storage for pub" requires_room_yml: false ``` ### Container Directories (Inheritance Scopes) Some directories are **inheritance containers** — they provide shared properties to child rooms without being navigable themselves. Like OpenLaszlo's `<node>` element. ```yaml # maze/CONTAINER.yml — Not a room, but defines inherited properties container: name: "The Twisty Maze" description: "Groups maze rooms with shared grue rules" inherits: is_dark: true is_dangerous: true grue_rules: can_appear: true ambient: sound: "dripping water" light_level: 0 ``` All child rooms (`room-a/`, `room-b/`, etc.) automatically inherit these properties! Alternatively, you can make the container into an actual room: ```yaml # maze/ROOM.yml — The maze entrance IS a room room: name: "Maze Entrance" description: "Dark passages branch off in every direction..." exits: a: room-a/ b: room-b/ # ... etc ``` **DESIGN CHOICE:** - Use `CONTAINER.yml` if you want inheritance without navigation (see [container skill](../container/)) - Use `ROOM.yml` if you want the directory to be a navigable space ### Hierarchy Example ``` adventure-4/ ├── ADVENTURE.yml # Adventure declaration ├── pub/ │ ├── ROOM.yml # Room declaration │ ├── stage/ │ │ └── ROOM.yml # Region (type: region) │ ├── bar/ │ │ └── ROOM.yml # Region │ ├── back-room/ │ │ └── ROOM.yml # Private region │ └── messages/ │ └── .meta.yml # System directory (no ROOM.yml needed) ├── characters/ │ ├── ROOM.yml # Hall of characters (type: personas) │ └── don-hopkins/ │ └── CHARACTER.yml # Character declaration └── maze/ ├── ROOM.yml # Room declaration └── room-a/ └── ROOM.yml # Sub-room (full room, not region) ``` ## ROOM.yml Structure ```yaml room: name: "Debug Session" purpose: "Hunt down the authentication bug" context: - "Bug: Login fails with valid credentials" - "Suspected: Session cookie handling" cards_in_play: - instance: "goblin-001" card: "Git Goblin" goal: "Find when bug was introduced" working_set: - "ROOM.yml" - "state/progress.yml" exits: parent: "../" related: "../feature-work/" # Optional: position in 2D world-space world_position: x: 5 y: 12 # Optional: objects with positions in room-space objects: - name: "workbench" position: {x: 3, y: 7} ``` ## Spatial Coordinates Rooms can exist in **world-space**. Objects can have positions in **room-space**. ```yaml # World-space: where is this room in the world? world_position: x: 5 y: 12 # Room-space: where are objects within this room? objects: - name: "workbench" position: {x: 3, y: 7} ``` Navigation can use coordinates: - `NORTH` from (5,12) → find room at (5,13) - Named exits override coordinates **Not all rooms need coordinates.** Abstract spaces can exist outside world-space. ## Vehicles: Portable Rooms That Move Full skill: [`skills/vehicle/`](../vehicle/) — horses, coaches, wagons, caravans, TARDIS offices, RVs. **Not** [`mount`](../mount/) (NFS skill/repo overlay). A **vehicle** is a room you can embark, drive, and disembark. ```yaml # vehicle-tent.yml room: name: "Research Tent" is_vehicle: true world_position: {x: 5, y: 12} # Changes when you drive ``` | Command | Effect | |---------|--------| | `EMBARK tent` | Enter the vehicle room | | `DISEMBARK` | Exit to current world location | | `DRIVE NORTH` | Move vehicle (and occupants) to (5,13) | ### Riding the Turtle **RIDE the turtle.** Move around the room, draw on the floor, jump through doors: ``` > RIDE turtle You mount the turtle. The world scrolls beneath you. > FORWARD 100 The turtle moves forward. A red line appears on floor.svg. > RIGHT 90 > FORWARD 50 You're near the door-north. > ENTER door-north You jump through the door INTO the next room. The turtle comes with you. ``` ```yaml # turtle.yml — a vehicle within room-space turtle: position: {x: 100, y: 100} heading: 90 # degrees, 0 = north pen_down: true pen_color: "#e94560" rider: "the-explorer" ``` | Command | Effect | |---------|--------| | `RIDE turtle` | Mount the turtle, move with it | | `FORWARD 50` | Move forward, draw if pen down | | `RIGHT 90` | Turn right | | `ENTER door` | Jump through door to connected room | | `INTO subroom` | Descend into nested sub-room | | `ZOOM OUT` | See the room graph navigator | **Lineage:** Papert's Logo turtle, Rocky's Boots (1982), Robot Odyssey (1984). ### Snap Cursor & Pie Menus When you approach an object, the cursor **snaps** to it and shows a **pie menu** of scored actions: ``` EXAMINE (80) ╱ REPAIR ──●── USE (95) ← default ╲ TAKE (20) ``` **This IS The Sims interaction model:** - Objects **advertise** their available actions - Actions are **scored** based on context, needs, state - High-scoring actions appear prominently **Lineage:** Don Hopkins' [Pie Menus](https://en.wikipedia.org/wiki/Pie_menu) + Will Wright's SimAntics. ## Cursor as Vehicle: Direct Manipulation The cursor **carries tools** and applies them to the room floor: ``` > SELECT pen-tool Cursor now carries: 🖊️ pen (red) > CLICK workbench *snap* Cursor at workbench. Pen ready. > DRAG to door-north Drawing line from workbench to door-north... Line added to floor.svg ``` | Tool | Icon | Action | |------|------|--------| | `pen` | 🖊️ | Draw lines on floor | | `eraser` | 🧽 | Remove drawings | | `selector` | 👆 | Pick up and move objects | | `linker` | 🔗 | Draw connections between objects | | `stamper` | 📌 | Place copies of cards | ## Throwing Objects: Data Flow Programming **Throw objects through exits.** They pile up on the other side. ``` > THROW blueprint door-north Throwing blueprint through door-north... blueprint landed in assembly/inbox/ ``` ### Inbox / Outbox ``` room/ inbox/ # Objects thrown INTO this room land here task-001.yml outbox/ # Stage objects before throwing OUT result-001.yml ``` | Command | Effect | |---------|--------| | `THROW obj exit` | Toss object through exit | | `INBOX` | List waiting items | | `NEXT` | Process next item (FIFO) | | `STAGE obj exit` | Add to outbox | | `FLUSH` | Throw all staged objects | ### Rooms as Pipeline Stages Each room is a **processing node**. Exits are **edges**. Thrown objects are **messages**. ```yaml # Document processing pipeline: uploads/ # Raw files land here inbox/ parser/ # Extract text script: parse.py analyzer/ # LLM analyzes prompt: "Summarize and extract entities" output/ # Final results collect here ``` **This is Kilroy-style data flow:** rooms as nodes, files as messages, the filesystem as the network. ## Inventories Characters carry **inventories** — portable rooms always with them. ```yaml # character/inventory/ sword.card map.yml notes/ finding-001.md ``` | Command | Effect |
在 GitHub 查看
这个 SKILL.md 很大,SkillsMP 这里只预览前一段内容。 在 GitHub 查看