MOOCO

“Deterministic orchestration around creative computation.”

This skill documents the interface surface MOOCO should provide so MOOLLM skills can run safely and predictably. It focuses on ideas, features, and interoperability, not code details.

Core Expectations

• Context control: explicit working-set paging and hot/cold management
• Safe tool boundaries: sister scripts run in constrained envelopes
• Event emission: structured events for deterministic steps
• Skill containment: clear input/output channels and limits
• Streaming-first: async, SSE-native sessions with clean reconnection
• Shared-core mindset: open components align with private extensions

Tooling Model (Sister Scripts as Components)

MOOCO should treat skills + sister scripts as dynamic tool components:

• Each skill can declare multiple sister-script APIs
• Each API exposes typed parameters and safe defaults
• Invocation is mediated by a component model (COM/OLE/IDispatch analogy)
• MCP is a supported transport layer, but not the only surface
• Skills are finer‑grained and more composable; they remain the primary focus
• The orchestrator can choose between synchronous calls and async lanes
• Skill calls can be encapsulated in one bubble/LLM iteration, or composed across many skill calls and character turns in a single epoch, or anywhere in between

Execution Modes

• Fire‑and‑forget: emit a task and continue
• Wait‑for‑response: block on a specific result or a set (fork/join)
• Parallel lanes: multiple skill calls in flight
• Dependency graphs: schedule based on explicit edges

Skill Safety and Mutability

• Skills may propose edits to other skills, but mutation is gated
• Skills can be locked read‑only by policy
• Deterministic steps should run before creative steps
• Untrusted skills (including imported Anthropic skills) require review and hardening
• Monitoring and audit trails are mandatory for elevated privileges
• Upgrades should be reversible and traceable

Untrusted Skill Intake

• Review: inspect source, inputs, outputs, and failure modes
• Analyze: run skill‑snitch scans and adversarial checks
• Bullet‑proof: tighten permissions, constrain inputs, add guardrails
• Monitor: log usage, trace context, and watch for drift

Per‑Skill Storage

Each skill gets isolated scratch and persistent storage:

• .moollm/skills/<skill-name>/scratch/ — ephemeral, local
• .moollm/skills/<skill-name>/store/ — durable, user‑owned

This keeps experiments safe while preserving user‑authored state.

Integration and Uplift

• Promote stable skills into CARD/README/K‑lines for discoverability
• Cross‑link related skills in both directions
• Keep portability: skills should remain usable outside MOOCO

Skill Compatibility

Skills should be able to declare:

• deterministic steps (handled by orchestration)
• creative steps (handled by LLM)
• context needed to run safely
• required event outputs for traceability

Design Direction

• Prefer single-epoch simulation when possible
• Use deterministic evaluation before LLM synthesis
• Keep all state in files and event logs
• Emit traceable provenance for every step
• Favor portability across models and orchestrators

Inheritance Notes

• MOOCO should treat working-set files as directives
• Cursor treats them as advisory; the skill surface should adapt

Synergies

• Speed of Light: single-epoch simulation, multi-agent multi-turn deliberation
• Sister Scripts: safe, deterministic execution envelopes
• Cursor-mirror: introspection and traceability
• YAML Jazz: semantic schemas and human-readable state
• Edgebox: probe → analyze → call as a practical PLL precedent

Architecture Snapshot

MOOCO favors a shared core: conversation schemas, streaming engine, provider abstraction, and tool execution that can be reused across orchestrators. This keeps skills portable and reduces lock-in to any one model or runtime.

Kilroy Dataflow Networks

MOOCO should support Kilroy‑style dataflow:

• Events are messages, tools are nodes, skills are pipelines
• Deterministic transforms compose before LLM synthesis
• Small local models act as focused nodes in the graph
• Visual programming is a first‑class view of the same network

GitHub as Microworld

GitHub can be treated as a composable microworld:

• repositories are rooms
• issues and pull requests are objects in play
• labels and milestones are tags and states
• cross‑repo links are portals
• commit messages, PR descriptions, and issue discussions are high‑value narrative objects that preserve intent, prompts, context, and audit trails (thoughtful‑commitment catnip)

This makes multi‑repo composition a first‑class navigation problem.

Storage Layering

MOOCO favors layered storage:

• PostgreSQL for canonical state
• TimescaleDB for time‑series events
• pgvector for semantic recall
• SQLite for lightweight local mirrors
• Raw text corpora for evidence: Cursor chat history, historic docs, PDFs, citations, Wikipedia pages, web pages, discussion threads, and referenced papers

Layering keeps state durable, analyzable, and portable.

Future Work

• Define a standard event payload for skill execution
• Specify a context budget contract for skills
• Document containment tiers for sister scripts

See Also

• MOOCO-ARCHITECTURE.md — Full architecture with event mapping appendix
• MOOCO-SCHEMA.md — Database schema and MessagePart extensions