| name | mooco |
| description | Custom orchestrator design notes and skill interface expectations |
| license | MIT |
| tier | 0 |
| allowed-tools | [] |
| protocol | MOOCO |
| tags | ["moollm","orchestration","design","context","safety"] |
| related | ["speed-of-light","play-learn-lift","sister-script","cursor-mirror","yaml-jazz","postel"] |
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
