Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
["David Ungar & Randall Smith — Self language (1987)","Seymour Papert — Constructionism","Marvin Minsky — K-lines, Society of Mind","Anthropic — Skills model foundation"]
SKILL
"A skill is documentation that learned to do things."
The meta-protocol: how skills work, how they evolve, how they compose, and how MOOLLM advances the state of the art.
Foundation: What We Share with Anthropic
MOOLLM skills build on Anthropic's excellent Skills model foundation:
Anthropic Principle
MOOLLM Implementation
Shared Why
Documentation-first
README.md + SKILL.md
Explain before automating
Tool definitions
YAML frontmatter + CARD.yml
Machine-readable specs
Composability
Prototype inheritance + dovetails
Complex from simple
Human gates
PLAN-THEN-EXECUTE protocol
Trust but verify
Skill libraries
skills/ directory
Central, shareable
The foundation is sound. MOOLLM adds to it (see sections 1-10 below).
MOOLLM's Unique Contributions
1. Skills as Prototypes (Self-like Inheritance)
"Objects all the way down." — David Ungar
Traditional skills are static documentation. MOOLLM skills are prototypes that create instances:
# Prototype (the skill)skills/adventure/├──SKILL.md# The documentation├──CARD.yml# The interface└──*.tmpl# The templates# Instance (created BY the skill)examples/adventure-4/├──ADVENTURE.yml# Instantiated from template
├──
characters/
# Populated during play
├──
pub/
# A room instance
└──
sessions/
# State over time
Why this matters:
Skills aren't just docs — they're factories
Instances inherit from prototypes but can override
State lives in instances, behavior in prototypes
Changes to prototypes automatically enhance all instances
The Semantic Image Pyramid: Multi-Resolution Reading
Like image pyramids in computer vision, skills and entities have multiple resolutions for different needs:
flowchart TB
subgraph GLANCE ["👁️ GLANCE (~5-70 lines)"]
G["INDEX entry or GLANCE.yml<br/>'Is this relevant?'"]
end
subgraph CARD ["📇 CARD.yml (~50-200 lines)"]
C["Interface, methods, advertisements<br/>'What can it do?'"]
end
subgraph SKILL ["📜 SKILL.md (~200-1000 lines)"]
S["Full protocol, examples<br/>'How does it work?'"]
end
subgraph README ["📚 README + resources (~500-5000+ lines)"]
R["Deep context, history, rationale<br/>'Why was it built?'"]
end
G --> C --> S --> R
GLANCE is the eyeball — the smallest useful unit:
For skills: INDEX.yml entry (~5 lines per skill)
For characters: GLANCE.yml (~50-70 lines vs 941)
For rooms: GLANCE.yml (~50-70 lines vs 930)
Reading Order (top-down):
Level
File
Lines
Use When
👁️ GLANCE
INDEX.yml entry / GLANCE.yml
5-70
"What is this?" Quick scan
📇 CARD
CARD.yml
50-200
"What can it do?" Interface check
📜 SKILL
SKILL.md
200-1000
"How does it work?" Protocol details
📚 DEEP
README.md + resources
500-5000+
"Why?" Full context
The Rule: Never load a lower level without first loading the level above it.
For Boot Optimization:
skills/INDEX.yml gives you GLANCE for all 110+ skills
Skills become cards that can be played, traded, collected:
# CARD.yml — The interface contractcard:id:adventurename:"Text Adventure"type: [skill, game, narrative]
emoji:🎲rarity:raremethods:EXPLORE: { description:"Move to adjacent room" }
EXAMINE: { description:"Look at something" }
TAKE: { description:"Pick up an object" }
advertisements:NARRATIVE-EXPLORATION:score:90condition:"Want interactive fiction"
Why this matters:
Clear interface contract
Advertised capabilities (like Sims objects!)
Can be played, stacked, combined
Machine-readable for orchestration
3. K-lines: Names as Activation Vectors
"A K-line is a wire-like structure that attaches to whichever mental agencies are active when you solve a problem." — Marvin Minsky
When you invoke a skill by name, you activate its entire knowledge context:
> Apply YAML-JAZZ to this configuration.# This single name activates:# - The semantic commenting philosophy# - The specific syntax patterns# - The examples and anti-patterns# - The emotional tone (jazzy, improvisational)# - Related concepts (POSTEL, soul-chat)
When you instantiate a character, their name becomes their K-line. "Palm" activates everything about Palm — history, personality, goals, relationships, the incarnation story.
Why this matters:
Names are more than labels — they're semantic activations
Context flows from invocation
Related concepts automatically available
The LLM's associative memory works FOR us
4. Ambient Skills: Always-On Behavioral Shaping
"Like air filters that clean continuously, not just when you smell smoke."
Some skills should be "in the air" — always available, always shaping output without explicit invocation. These are ambient skills.
The Key Insight: AMBIENT is an advertisement type!
This fits perfectly because:
Advertisements already have scores and conditions
The orchestrator already knows how to process advertisements
It's semantically accurate — the skill is literally advertising "I want to be in context"
Declaring an Ambient Skill:
# In CARD.ymladvertisements:# Regular advertisements (invoked on demand)CREATE-SKILL:score:90condition:"Need to make a new reusable capability"# AMBIENT advertisement (always in context)AMBIENT:score:100# Priority for context budgetcondition:always# Or: "when writing YAML"scope:session# How long it persistsresolution:summary# How much to keep in context
AMBIENT Advertisement Fields:
Field
Options
Meaning
score
0-100
Priority for context budget (higher = kept longer)
condition
always, condition string
When to activate
scope
session, conversation, room, card-only
Persistence duration
resolution
full, summary, sniff, card-only
How much to load
Examples of Ambient Skills:
# no-ai-slop: Always on, syntactic hygieneAMBIENT:score:100condition:alwaysscope:sessionresolution:card-only# Just the cardinal sins list# yaml-jazz: When writing YAMLAMBIENT:score:90condition:"when writing or editing YAML files"scope:conversationresolution:summary# representation-ethics: When simulating real peopleAMBIENT:score:95condition:"when portraying real people or sensitive topics"scope:conversationresolution:full
Orchestrator Behavior:
The orchestrator handles AMBIENT advertisements by:
Collecting: Gather all AMBIENT ads from loaded skills
Evaluating: Check conditions against current context
Sorting: Order by score (highest priority first)
Loading: Include skills at their declared resolution until context budget exhausted
Refreshing: Re-evaluate on context change (new room, new topic, etc.)
The Standard Schema Advantage:
Because CARD.yml follows a standard schema, a smart orchestrator can:
Parse all advertisements programmatically
Find AMBIENT declarations automatically
Operationalize them without LLM intervention
Inject them invisibly into the LLM's brain
This is the "magic places" principle — structured locations (like advertisements.AMBIENT) where the orchestrator knows to look.
Two Modes: Smart vs Dumb Orchestrators
Orchestrator
AMBIENT Handling
LLM Experience
MOOCO (smart)
Driver parses CARDs, injects automatically
Invisible — "I will inject them into your brain"
Cursor (dumb)
Advisory mode, manual hot list
Visible — LLM manages context manually
Smart Orchestrator (MOOCO) Promise:
The custom driver says to the LLM:
"Don't worry about looking at ambient skills with the file tool.I will inject them into your brain continuously."
The LLM never sees the mechanism. The CARD is just... there. Always.
Dumb Orchestrator (Cursor/Claude Code) Fallback:
We can't control these orchestrators, so:
Declare AMBIENT in CARD.yml — the skill advertises its ambient nature
Manual hot list — keep important CARDs in .moollm/hot.yml or working set
Resolution field — skill declares how much of itself to keep paged in (card-only, summary, full)
Trust the LLM — once the CARD is in context, the LLM knows to apply its constraints
This is "throw down the gauntlet" architecture: if you want ambient, define an AMBIENT advertisement. The mechanism adapts to the orchestrator.
Standard CARD.yml schema already enables smart orchestration
Smart orchestrator can parse the ads directly from CARD
Dumb orchestrators need manual management anyway
One file (CARD.yml) works in both modes
The existing advertisement system perfectly solves the problem with preconditions, scores, priorities, already, so we don't have to reimplement it for AMBIENT.yml
The Design Elegance:
Same CARD.yml, different runtimes:
MOOCO: Orchestrator reads AMBIENT ads, injects them
Cursor: Advisory mode, LLM manages manually
Future custom: Any orchestrator can parse the standard schema
The Air Cleaner Metaphor:
Type
What It Filters
Condition
no-ai-slop
Syntactic sludge
always
no-ai-gloss
Semantic sludge (euphemism)
always
postel
Robustness failures
always
yaml-jazz
Bad YAML structure
when writing YAML
representation-ethics
Harmful portrayals
when simulating people
Why Ambient as Advertisement:
Unified mechanism: No special "ambient" field needed — just a special advertisement
Natural scoring: Context budget allocation uses existing priority system
Conditional activation: Same condition evaluation as other ads
Composable: Ambient ads interact with other ads through normal scoring
The no-ai-* Namespace:
Ambient skills that enforce behavioral boundaries follow the no-ai-* naming pattern:
# Templatedescription:|
{{describe_appearance_based_on_species_and_personality}}
# Contextspecies:"Golden Retriever mix"personality: ["enthusiastic", "loyal", "goofy"]
# Generateddescription:|
Biscuit is a fluffy, perpetually happy Golden Retriever mix with
eyes that sparkle with boundless enthusiasm. His tail is in a
constant state of wagging, a furry metronome of joy.
# 33 turns of Stoner Fluxx in ONE LLM call:# - Andy and Kristin Looney playing their own game# - Rule changes (Hand Limit 2, Draw 3, Play All)# - Goal cards (Peace, 420, Get the Munchies)# - Keeper management across 8 players# - Natural conversation and jokes# - Consistent state throughout
Why this matters:
External multi-agent systems: Agent A → API → Agent B → API → ...
MOOLLM: Single call simulates all agents debating, deciding
10x faster, 10x cheaper, perfect consistency
Adversarial committees, ensemble inference, real deliberation
"The room defines the performance. Everything inside inherits its framing."
When you enter a space, you inherit its ethical and performative context:
# pub/ROOM.ymlroom:name:TheGezelligheidGrottoframing:mode: [performance, celebration, tribute]
inherits_to_children:truedescription:|
This is a PLACE OF PERFORMANCE AND CELEBRATION.
Everything within these walls is understood as:
- Social play
- Entertainment and expression
- TRIBUTE PERFORMANCE — honoring those we admire
what_this_means:debates:"Arguments are sport, not war"performances:"The stage is open, judgment is kind"tributes:"We invoke those we admire as loving simulations"
Why this matters:
Characters in the pub automatically inherit "performance mode"
Tribute impersonations are framed as celebration, not deception
Ethical context flows from rooms to all children
No need to repeat framing in every sub-room
Example: When Palm performs as Andy Looney in the pub, the room's framing makes it explicitly a tribute — celebrated fan performance, not deceptive impersonation.
In MOO tradition, everything can manifest in multiple ways. A MOOLLM skill is triadic:
As Room (Space to Explore):
> enter the adventure skill
You are in the Adventure Workshop.
Exits: pub, maze, character-gallery
Objects: room-templates, npc-catalog, puzzle-designs
As Character (Expert to Consult):
> ask adventure-expert about puzzle design
"Consider the lock-and-key pattern: player finds key in
room A, uses it to unlock door in room B..."
As Object (Tool to Use):
> take the room-builder
You now have the room-builder.
> use room-builder on forest-clearing
Creating forest-clearing/ with ROOM.yml template...
Card Structure for Triadic Skills:
card:name:adventureas_room:description:"A workshop for building text adventures"exits: [pub, maze, templates]
objects: [room-builder, npc-factory, puzzle-kit]
as_character:description:"An expert in interactive fiction design"expertise: [puzzle-design, pacing, atmosphere]
personality:"Creative, playful, encouraging"as_object:description:"Tools for creating adventure games"verbs: [create-room, spawn-npc, design-puzzle]
portable:true
10. Codebase as Navigable World
Modern IDEs like Cursor can mount multiple repositories. Each codebase becomes a navigable world:
Directories are rooms — enter @central/apps/insights/pyleela/brain/
Files are objects — examine Schema.py, see its classes and functions
Functions are chambers — enter createSyntheticItemIfNeeded to focus there
Characters have code locations — location: "@repo/path/file.py:142"
Parties explore together — multi-expert code review in one LLM call
Location path syntax:
@repo/path/to/file.py # File
@repo/path/to/file.py:42 # Specific line
@repo/path/to/file.py:42-67 # Line range
@repo/path/dir/ # Directory (room)
See:
room/ — Directories as rooms, files as objects with chambers
# PLAY → LEARN → LIFT cycleskill_evolution:play:action:"Do it manually. Explore. Make mistakes."example:"Dropped cheese in room A..."learn:action:"Notice patterns. Document them."example:"Each room needs a unique marker..."lift:action:"Extract reusable skill. Share it."result:skill:"maze-mapping"procedure:"Drop unique item in each room"
Documentation → Procedure → Script → Tool
This is Programming by Demonstration made systematic.
skills/
my-skill/
README.md # Human entry point (GitHub renders)
SKILL.md # Full spec with YAML frontmatter
CARD.yml # Machine-readable interface
*.tmpl # Templates at root level (optional)
File
Purpose
Required
README.md
Human-friendly landing page
✓
SKILL.md
Full spec with YAML frontmatter
✓
CARD.yml
Interface: methods, tools, state, advertisements
✓
*.tmpl
Templates for instantiation
Optional
*.py
Sister scripts for automation
Optional
Why README.md (Disagreeing with Anthropic)
Anthropic recommends against README.md in skills. We respectfully disagree:
GitHub renders README.md as the landing page
Humans browse skills before invoking them
Play-Learn-Lift starts with exploration
Two audiences: humans (README) and LLMs (SKILL.md + CARD.yml)
Keep both. README is for discovery, SKILL.md is for execution.
Publishing and metadata (MOOLLM skills)
Skills may be published independently (zip of skill dir or bare SKILL.md). Policy:designs/SKILL-PUBLISHING-POLICY.md. In short: (1) Self-contained — SKILL.md must work alone; do not rely on CARD/README for critical behavior. (2) Related skills — Document related and optional benefits_from in frontmatter and a short section in the body. (3) Part of MOOLLM — Include the standard blurb: point directly to this skill's directory root on GitHub (so any LLM can browse and fetch the full skill dir); mention repo and skills/README once. Placement follows dog-butt sniffing: optional minimal line at start (glance), full section at end. See policy for rationale. (4) Metadata — Core = name, description (Anthropic/Agent Skills compatible); MOOLLM extension = allowed-tools, permissions, related, license, tags, credits, optional moollm. Reach is inferred from permissions. Full MOOAM model (IAM-style): designs/MOOAM.md. Templates in this skill already include the blurb and metadata hints.
Diagrams: Format by Audience
Different files serve different audiences. Choose diagram formats accordingly:
File
Primary Audience
Best Format
Why
SKILL.md
LLMs
YAML Jazz
Structured, parseable, sniffable
README.md
Humans
Mermaid
Rendered by GitHub, visual
Both
—
NOT ASCII art
Wastes tokens, hard to maintain
SKILL.md — YAML Jazz for LLMs:
# LLMs parse this instantlydata_flow:input:"user request"steps:-action:"parse intent"output:"structured command"-action:"execute"output:"result"output:"formatted response"
README.md — Mermaid for Humans and curious LLMs:
graph LR
A[User Request] --> B[Parse Intent]
B --> C[Execute]
C --> D[Response]
Why NOT ASCII art:
# ❌ ASCII art wastes tokens and breaks easily
┌─────────┐ ┌─────────┐ ┌─────────┐
│ Input │───►│ Process │───►│ Output │
└─────────┘ └─────────┘ └─────────┘
skills/my-skill/
├── README.md
├── SKILL.md
├── CARD.yml
├── scripts/ # When you have multiple scripts
│ └── helper.py
├── templates/ # When you have multiple templates
│ └── INSTANCE.yml.tmpl
└── references/ # When you have supporting docs
└── algorithm.md
Phase 3: Instance Library Pattern
Skills can have a sub-directory for reusable instances!
skills/buff/
├── README.md
├── SKILL.md
├── CARD.yml
├── BUFF.yml.tmpl # Template for new buffs
└── buffs/ # ← LIBRARY of reusable instances!
├── fire-resistance/ # Instance as directory
│ └── BUFF.yml
├── haste.yml # Instance as single file
└── INDEX.yml # Multiple instances bundled
Three organization styles (all valid, mix freely):
# skills/buff/buffs/INDEX.yml# Multiple instances in one filebuffs:fire-resistance:name:"Fire Resistance"duration:10effect:"Immune to fire damage"haste:name:"Haste"duration:5effect:"+2 speed, extra action"invisibility:name:"Invisibility"duration:8effect:"Cannot be seen unless attacking"breaks_on: ["attack", "cast_spell"]
Referencing library instances:
# From anywhere in the worldcharacter:buffs:-ref:skills/buff/buffs/fire-resistance.yml-ref:skills/buff/buffs/INDEX.yml#haste
Why this matters:
Skills are FACTORIES that produce instances
Instance libraries are CATALOGS of pre-made products
Users can browse, copy, or reference existing instances
The skill teaches by example (Play-Learn-Lift!)
Rule: Top-level SKILL.md references ALL files, regardless of nesting. No hierarchical hunting.
Front-Matter Sniffing
LLMs can efficiently understand skills by reading the first ~50 lines:
# SKILL HEADER (lines 1-15)---name:my-skilldescription:"One-line summary"permissions: [files]
allowed-tools: [read_file, write_file]
related: [room, card, character]
---
# PURPOSE (lines 16-25)# My Skill>One-linerphilosophy## What It DoesBriefexplanation...# FILE MAP (lines 26-40)## Files in This Skill-`README.md`—Landingpage-`CARD.yml`—Interfacedefinition-`scripts/helper.py`—Automationtool-`templates/INSTANCE.yml.tmpl`—Instantiationtemplate
Why this matters:
LLMs don't need to read everything
Front-matter summarizes capability
File map shows what's available
50 lines = context-efficient discovery
Python Scripts: Dual-Audience Structure
When skills include Python, structure for both humans and LLMs:
#!/usr/bin/env python3"""my-skill: Brief description.
This docstring becomes --help AND is visible to the LLM.
Usage: python my-skill.py [command]
"""# IMPORTS (lines 8-15)import click
from pathlib import Path
# CONSTANTS (lines 17-25)
DEFAULT_ROOM = "start"
VALID_COMMANDS = ["explore", "examine", "take"]
# CLI STRUCTURE (lines 27-50)@click.group()defcli():
"""Main entry point."""pass@cli.command()@click.argument("target")defexamine(target: str):
"""Look at something in detail."""
...
# IMPLEMENTATION (lines 52+)# LLM only reads this far if it needs implementation details
Consumer
What They Read
Human
./tool.py --help
LLM
First 50 lines (imports, constants, CLI structure)
DRY: Command structure written once as code. No duplicate documentation.
Instantiation Modes
Skills don't always need full instantiation:
Mode
Files?
Persistence
When to Use
Mentioned
No
None
Quick invocation: "Apply POSTEL here"
Modeled
No
Chat only
Guided exploration in conversation
Embedded
In doc
Document
Design discussions (literate programming)
Instantiated
Yes
Full
Running instances with state
Start light, instantiate when needed.
Skill Composition
Skills compose like functions:
skill:name:"adventure-exploration"composes:-room# Navigation-card# Inventory-soul-chat# NPC dialogue-action-queue# Agent behavior-speed-of-light# Multi-agent simulationorchestrates:-"Use room for movement"-"Use card for items"-"Use soul-chat for conversations"-"Use speed-of-light for ensemble scenes"
Complex capabilities from simple building blocks.
Local Skill Emergence
Skills can emerge from gameplay and be captured:
# In player.yml after playinglearned_skills:-name:grue-avoidancelearned_from:"dying 7 times"technique:"always check lamp before entering dark rooms"could_lift_to:skills/grue-avoidance/-name:vendor-hagglinglearned_from:"buying lamp oil"technique:"buy in bulk, check gold first"local_only:true# Too specific to generalize
Characters carry learned skills. Objects and NPCs can teach skills.
Commands
Command
Action
SKILL [name]
Invoke or describe a skill
SKILLS
List available skills
LEARN-SKILL [name]
Begin learning a skill
LIFT-SKILL [name]
Extract local skill to central
INSTANTIATE [skill] [location]
Create instance from prototype
Protocol Symbols
Symbol
Meaning
SKILL
Invoke this meta-skill
PLAY-LEARN-LIFT
The development lifecycle
SKILL-INSTANTIATION
Create instance from prototype
PROTOTYPE
Self-like inheritance
EMPATHIC-TEMPLATES
Smart semantic instantiation
The Proof: What We've Demonstrated
This isn't theory. MOOLLM has demonstrated:
1. Autonomous Character Creation
Palm the monkey: Full incarnation with tribunal debate, self-chosen name, home, traits, goals
Biscuit the dog: Autonomous naming, species selection, home placement
2. Extended Multi-Agent Simulation
33-turn Stoner Fluxx: 8+ characters, rule changes, consistent game state
compiler:modes:development:# Full skills, all documentation# Maximum introspection capabilitystrip_unused:falseinclude_readme:trueinclude_examples:trueproduction:# Optimized for runtime efficiencystrip_unused:trueinclude_readme:false# Absorbed into SKILL.mdinline_critical_refs:trueminimal:# Smallest possible footprint# Only methods actually called in test suitestrip_unused:trueinline_all:truesingle_file_output:true
Source vs. Compiled Skills
skills/ # SOURCE: Full development skills
├── adventure/
│ ├── README.md # Human documentation
│ ├── SKILL.md # Full protocol spec
│ ├── CARD.yml # Complete interface
│ └── tests/ # Test cases for compiler
│ ├── test_cases.yml
│ └── benchmark_data/
compiled/ # OUTPUT: Optimized for target
├── cursor-leela/ # Target: Cursor + Leela AI domain
│ └── adventure/
│ ├── SKILL.md # Slimmed, README absorbed
│ └── CARD.yml # Only used methods
└── minimal/ # Target: Smallest footprint
└── adventure.yml # Single-file bundle
K-line Optimization
K-lines are activation vectors. The compiler should:
# SOURCE: Full K-line networkrelated: [room, card, character, soul-chat, speed-of-light,
action-queue, empathic-templates, yaml-jazz, postel, ...]
# COMPILED: Only K-lines actually activated in target contextrelated: [room, card, character] # Pruned to essentials
Multi-Tiered Resolution
Compiled skills should support progressive loading:
We stand on excellent foundations and warmly invite others to join us. We add instantiation, inheritance, empathy, triadic manifestation, and proven multi-agent simulation.
"Start with jazz, end with standards. But never stop playing."
