MiMo-Code Feature Architecture Analysis: an investigation into how MiMo-Code incorporates and extends the open-source OpenCode project, including attribution analysis of derived Superpowers plugin skills.

MiMoCode-Analysis.md

MiMo-Code Feature Architecture Report

This report describes six core features of the MiMo-Code platform (the packages/opencode package): Persistent Memory, Intelligent Context Management, Task Tracking, the Subagent System, Goal / Stop Conditions, and Dream & Distill. Each section traces the feature from user-facing surface down through its implementation layers, database schema, and integration points. A final section analyzes how the features interact.

---

1. Persistent Memory

Overview

Persistent Memory is a cross-session knowledge store that allows agents to recall information from prior conversations, project notes, session checkpoints, and task progress. It is built on top of an SQLite FTS5 (full-text search) index over Markdown files stored on disk.

File Layout

<Global.Path.data>/memory/
  global/                          # Shared across all projects
    <key>.md
  projects/<project_hash>/         # Per-project memory
    <key>.md
    tasks/<task_id>/
      progress.md
      notes.md
  sessions/<session_id>/           # Per-session memory
    checkpoint.md
    memory.md
    checkpoint-<title>.md

Memory types are auto-detected from the filename pattern:

• memory.md / memory-*.md -> type memory
• checkpoint.md / checkpoint-*.md -> type checkpoint
• tasks/<id>/progress.md -> type progress
• tasks/<id>/notes.md -> type notes
• Everything else -> type free

Key Files

File	Purpose
src/memory/service.ts	Effect service: root(), reconcile(), search()
src/memory/reconcile.ts	Bidirectional sync between disk Markdown and FTS5 table
src/memory/fts.sql.ts	Drizzle schema for memory_fts table
src/memory/fts-query.ts	Builds safe FTS5 MATCH expressions from user queries
src/memory/paths.ts	Path parsing, building, and memory-locator logic
src/tool/memory.ts	The memory tool exposed to agents (search operation)

How It Works

1. Storage: Markdown files live on disk under <data>/memory/<scope>/<scope_id>/<key>.md. A companion SQLite table (memory_fts) holds the same content for full-text search.

2. Reconciliation (reconcile.ts): A bidirectional sync walks all Markdown files on disk, fingerprints each by size-mtimeMs, and indexes new/changed files into FTS5. Dead rows (files no longer on disk) are pruned. Reconciliation is lazy: it runs before every search (configurable via checkpoint.memory_reconcile_on_search).

3. Search (service.ts): Queries are tokenized (Unicode-aware, \p{L}\p{N}_ runs), wrapped in phrase-quotes, and OR-joined into an FTS5 MATCH expression. BM25 ranking gives higher scores to documents matching rarer/more query terms. A relative score floor (default 15% of top hit's score) drops common-word noise.

4. Claude Code Interop: When memory.cc_index is enabled in config, ~/.claude/projects/<slug>/memory/*.md files are also indexed under scope "cc", with type derived from YAML frontmatter metadata.type.

5. Agent Tool: The memory tool exposes a search operation to agents. It returns BM25-ranked results with snippets and advises the agent on escalation strategies when zero results are found (fewer terms, Grep for literals, history tool for verbatim recall).

Checkpoint Writer

The checkpoint-writer agent (a hidden subagent) periodically writes session memory files (checkpoint.md, memory.md, task progress.md/notes.md) as a session progresses. It is triggered by token thresholds (see Context Management below) and runs as a fork agent that reuses the parent's prompt prefix for cache alignment.

Auto-Dream / Auto-Distill

Two system-spawned background agents maintain memory hygiene. These are described in detail in section 6, Dream & Distill.

---

2. Intelligent Context Management

Overview

Context management in MiMo-Code is a multi-layered system that keeps conversations within model context limits while preserving the most important information. It comprises checkpoint writing, compaction (summarization), pruning (output truncation), budgeted reading, and overflow detection.

Key Files

File	Purpose
src/session/overflow.ts	Token-count threshold logic, pressure-level classification
src/session/compaction.ts	Summarizes old conversation into a compaction message
src/session/prune.ts	Fires checkpoints, soft-trims and hard-prunes tool outputs
src/session/budgeted-read.ts	Token-budgeted file reading with section-aware truncation
src/session/checkpoint.ts	Orchestrates checkpoint writer subagents
src/session/checkpoint-templates.ts	Templates for checkpoint.md, memory.md, notes.md
src/session/checkpoint-paths.ts	Path construction for memory files
src/session/boundary.ts	Adjusts compaction boundary for API invariants

The Context Lifecycle

1. Pressure Monitoring (overflow.ts)

Four pressure levels based on token usage as a fraction of usable context:

• Level 0: < 50% — comfortable
• Level 1: 50-70% — soft-trim old tool outputs
• Level 2: 70-85% — hard-clear tool outputs, strip non-essential content
• Level 3: >= 85% — trigger compaction

The usable() function computes available context by subtracting a reserved buffer (default 20K tokens, capped at 20K for models with large output windows) from the model's input limit.

2. Checkpoint Writing (prune.ts, checkpoint.ts)

As a conversation grows, checkpoint writers are fired at percentage thresholds of the context window:

• Window < 25K: disabled
• Window 25K-200K: 4 triggers at 20%, 40%, 60%, 80%
• Window 200K-500K: 9 triggers at 10% through 90%
• Window > 500K: 18 triggers at 5% intervals

When a threshold is crossed, a checkpoint-writer subagent is spawned (fork mode: reuses parent's LLM prefix for prompt-cache alignment). It writes:

• checkpoint.md: structured summary (Goal, Instructions, Discoveries, Accomplished, Relevant files)
• memory.md: durable project-level knowledge
• Task progress.md/notes.md for active tasks

The checkpoint writer is a fork agent: it captures the parent's full system prompt + tools + messages at spawn time into a ForkContext, so its LLM prefix matches the parent exactly (enabling prompt-cache reuse). It runs detached and writes memory files asynchronously.

3. Compaction (compaction.ts)

When context pressure hits the overflow threshold, compaction fires:

1. The conversation is split into a "head" (to summarize) and "tail" (recent turns to preserve).
2. The tail is sized to a preserve_recent_tokens budget (default 2K-8K, 25% of usable context).
3. A dedicated compaction subagent receives the head messages and produces a structured summary following a template (Goal, Instructions, Discoveries, Accomplished, Relevant files).
4. The summary replaces the old messages in the conversation.
5. If in auto mode, a synthetic "Continue" message re-enters the agent to resume work.

Compaction is per-actor: subagents have independent compaction cycles scoped by agentID, so compacting a subagent's context doesn't disturb the main session.

4. Pruning (prune.ts)

Pruning operates at two levels:

• Soft trim (pressure level 1): Long tool outputs (> 4096 chars) are trimmed to keep first/last 1.5K characters with a [... trimmed ...] marker.
• Hard prune (pressure level 2): Tool outputs older than the last 2 turns are marked with a compacted timestamp, removing them from the LLM context window. Protected tools (e.g., skill) are never pruned.

Non-essential content (media attachments, reasoning blocks) is also stripped when the cache TTL has expired.

5. Budgeted Reading (budgeted-read.ts)

When reading files into context, MiMo-Code uses token-budgeted reading:

• Simple truncation: If a file exceeds the budget, it's truncated at a line boundary with a hint showing how to read the rest.
• Section-aware truncation: For structured Markdown files, headers and index lines are always preserved, while body content is trimmed section-by-section within the budget.

---

3. Task Tracking

Overview

Task Tracking is a persistent, hierarchical work-item system built on SQLite. Tasks have structured IDs (T1, T2, T1.1, T1.2...), a state machine lifecycle, event logging, and automatic cleanup. A "task gate" mechanism prevents agents from stopping with unfinished work.

Key Files

File	Purpose
src/task/registry.ts	Effect service: CRUD operations on tasks
src/task/schema.ts	Zod schemas for Task, TaskID, TaskStatus, TaskEvent
src/task/task.sql.ts	Drizzle schema for task and task_event tables
src/task/events.ts	Bus events for task creation and updates
src/task/gate.ts	Stop-gate logic that re-enters agents with unfinished tasks
src/task/gate-state.ts	Per-session ReAct counter for the main-path task gate
src/tool/task.ts	The task tool exposed to agents (JSON and shell modes)

Task Data Model

Task:
  id:             "T1" | "T1.1" | "T1.2.3" (hierarchical, auto-assigned)
  session_id:     Foreign key to session
  parent_task_id: Optional parent for subtasks
  status:         open | in_progress | blocked | done | abandoned
  summary:        Human-readable description
  owner:          Agent/actor that owns the task
  created_at:     Timestamp
  last_event_at:  Timestamp
  ended_at:       Timestamp (terminal states only)
  cleanup_after:  Timestamp (auto-archive after N days)

Task Lifecycle

                 ┌──────────┐
      create ──> │   open   │ <── unblock
                 └────┬─────┘
                      │ start
                 ┌────▼─────┐
                 │in_progress│
                 └────┬─────┘
                      │
            ┌─────────┼──────────┐
            │         │          │
       ┌────▼───┐ ┌───▼───┐ ┌───▼────┐
       │blocked │ │ done  │ │abandoned│
       └────────┘ └───────┘ └────────┘
        (terminal) (terminal) (terminal)

State transitions are enforced:

• done and abandoned are terminal — start() on a terminal task is a no-op with a warning.
• Idempotent re-start by the same owner is a no-op (prevents event spam).
• A different owner starting an in-progress task is a genuine handoff.

Hierarchical IDs

Child IDs are auto-numbered: given parent T1, siblings become T1.1, T1.2, etc. Root tasks are T1, T2, T3... The nextChildId() function scans existing siblings and increments the max.

The Task Gate (gate.ts)

The task gate is a stop-condition mechanism: when an agent is about to finish (either a subagent or the main session), the gate checks for non-terminal (open or in_progress) tasks. Three outcomes:

1. No incomplete tasks: Agent stops normally.
2. Incomplete tasks, under ReAct cap: A synthetic system-reminder message is injected, listing the unfinished tasks and instructing the agent to complete or abandon each one. The agent re-enters its run loop (a "nudge").
3. Incomplete tasks, ReAct cap exceeded: The agent stops, but the incomplete tasks remain visible. Cap prevents infinite loops.

ReAct caps differ by mode:

• Subagent: MAX_TASK_GATE_SUBAGENT_REACT = 2 (shorter lifetime)
• Main session: MAX_TASK_GATE_MAIN_REACT = 3 (no judge model, so more conservative)

Owner semantics differ:

• Subagent mode: Only tasks owned by that actor's ID are checked.
• Main mode: All non-terminal tasks in the session are checked (catches subagent-orphaned tasks).

Event Logging

Every state transition creates a task_event row with kind (created, started, blocked, unblocked, done, abandoned, renamed) and an optional summary. Events power the UI's real-time task tree rendering and the TUI/SSE stream.

Automatic Cleanup

Terminal tasks get a cleanup_after timestamp (default 7 days from checkpoint.task_archive_days). The list() operation excludes archived tasks by default, keeping the active set clean.

---

4. Subagent System

Overview

MiMo-Code's subagent system allows the primary agent to spawn child agents (actors) that operate independently within the same session or in isolated worktrees. The system supports multiple agent types, tool whitelisting, structured output, message passing, and workflow orchestration.

Key Files

File	Purpose
src/actor/agent.ts	Agent definitions (build, plan, compose, general, explore, etc.)
src/actor/spawn.ts	Core spawn logic: lifecycle, ReAct, fork context, outcomes
src/actor/registry.ts	SQLite-backed actor registry (status, outcomes, stuck detection)
src/actor/turn.ts	Single turn execution for a subagent
src/actor/waiter.ts	Deferred-based outcome waiting
src/actor/schema.ts	Types for SpawnMode, ContextMode, Lifecycle, ToolWhitelist
src/actor/events.ts	Bus events for actor lifecycle
src/tool/actor.ts	The actor tool exposed to agents
src/workflow/runtime.ts	Workflow orchestration engine
src/workflow/sandbox.ts	QuickJS sandbox for deterministic workflow scripts

Agent Types

Agent	Mode	Description
build	primary	Default coding agent with full tool access
plan	primary	Read-only planning mode (edits denied)
compose	primary	Orchestrates workflows via built-in compose skills
max	primary	Experimental parallel reasoning (opt-in)
general	subagent	General-purpose research + multi-step tasks
explore	subagent	Fast codebase exploration (grep, glob, read only)
title	subagent	Generates session titles (hidden, no tools)
summary	subagent	Generates session summaries (hidden, no tools)
compaction	subagent	Summarizes conversations (hidden, no tools)
checkpoint-writer	subagent	Writes memory files (fork agent, hidden)
dream	subagent	Memory consolidation (hidden, read + memory tools)
distill	subagent	Workflow discovery and packaging (hidden)

Spawn Modes

1. subagent (default): Shares the parent session. Each subagent gets its own agentID for scoped message history, compaction, and task ownership. Context modes:

   • none: No conversation history (clean slate for fan-out)
   • state: Recent state summary
   • full: Full conversation history

2. peer: A full peer session in the same database, with its own system prompt and independent run loop.

The Spawn Lifecycle (spawn.ts)

1. Registration: The actor is registered in ActorRegistryTable (SQLite) with status running.
2. Task assignment: If a task_id is provided, the task's owner is set to the actor.
3. Run loop: The actor executes turns (LLM calls + tool execution) until:
   • The model stops naturally (no tool call)
   • The model calls the StructuredOutput tool (for schema requests)
   • The actor is cancelled
4. Pre-stop gate: Before stopping, the task gate checks for incomplete tasks. If found, a nudge re-enters the agent (up to MAX_PRE_REACT = 3 times).
5. Post-stop gate: After stopping, another check for incomplete tasks with up to MAX_POST_REACT = 3 re-entries.
6. Outcome extraction: The agent's final message is parsed for a **Status**: success|partial|failed|blocked header. Structured output (if requested) is extracted from the validated JSON schema result.
7. Cleanup: The actor is marked as terminal in the registry, its deferred outcome is resolved, and any inbox notifications are sent.

Fork Agents

Fork agents (used by checkpoint-writer) capture the parent's full LLM request prefix (system prompt + tools + messages-to-watermark) at spawn time. This enables:

• Prompt-cache reuse: The fork's LLM prefix matches the parent exactly.
• Independent execution: The fork runs its own turns with the captured context, immune to parent message stream changes.

The Actor Tool

The actor tool provides these operations:

• run: Synchronous subagent call (blocks until completion)
• spawn: Asynchronous subagent launch (returns immediately)
• status: Check actor status
• wait: Block until actor completes
• cancel: Cancel a running actor
• send: Send a message to an actor's inbox

It supports both JSON invocation and a shell-mode DSL (e.g., actor run explore "find all API endpoints").

Workflow System

The workflow system (src/workflow/) orchestrates multiple subagents deterministically via sandboxed JavaScript scripts:

1. Sandbox (sandbox.ts): Scripts run inside a QuickJS engine with:

   • Seeded PRNG for determinism (replay-correctness)
   • Stripped Date, WeakRef, FinalizationRegistry
   • 64MB memory limit, 12h wall-clock deadline
   • Host functions injected as globals (agent(), parallel(), pipeline(), etc.)

2. Runtime (runtime.ts): Manages workflow lifecycle:

   • Process-wide concurrency semaphore (default: min(16, 2xCPU))
   • Per-run lifecycle cap (default: 1000 agents)
   • Per-agent wall-clock timeout (optional)
   • Journaling for resume/replay (successful agent results are persisted)
   • Nested workflows with cycle detection and depth limits (default maxDepth = 8)

3. Built-in workflows: deep-research is shipped with the binary.

4. Persistence (persistence.ts): Workflow state (script, journal, counters) is persisted to disk for crash recovery and resume.

Isolation Modes

• Shared (default): Subagent shares the parent session (cheaper, no per-agent session).
• Worktree isolated: Each agent gets a fresh git worktree. File tools resolve to the worktree. After completion:
  • If the agent succeeded and left changes: worktree is kept, surfaced as _worktree: { branch, directory, changed }.
  • If pristine/failed: worktree is removed.

---

5. Goal / Stop Condition

Overview

The Goal system allows users to set a stop condition on a session via the /goal command. Once set, the main run loop refuses to stop until an independent "judge" model evaluates the conversation transcript and determines the condition is satisfied (or genuinely impossible). This creates a goal-directed autonomous loop.

Key Files

File	Purpose
src/session/goal.ts	Goal service: set, get, clear, evaluate, bumpReact
src/session/prompt.ts	Main run loop integration (goal evaluation after each turn)

How It Works

1. Setting a goal: Via /goal <condition> command. The condition is stored in InstanceState (per-project, in-memory) keyed by session ID. A SessionGoal.Updated bus event is published for UI rendering.

2. The Judge (goal.ts): After each assistant turn where a goal is active:

   • The full conversation (converted to native model messages, including tool calls/results/images) is sent to a separate model call.
   • The judge receives a system prompt instructing it to evaluate the transcript and return a structured verdict:

     {"ok": true, "reason": "<evidence from transcript>"}
     {"ok": false, "reason": "<what is missing>"}
     {"ok": false, "impossible": true, "reason": "<why unachievable>"}

   • The judge is independent: it does not do the work, only reads the transcript. This keeps its verdict cold relative to the working agent's optimism.

3. Verdict handling:

   • ok: true: Goal is satisfied. The goal is cleared, a SessionGoal.Updated event is published (goal: undefined), and the session proceeds normally.
   • ok: false (no impossible flag): The agent is re-entered with a system-reminder containing the judge's reason, nudging it toward the goal. A "react" counter increments.
   • ok: false, impossible: true: The goal is genuinely unachievable. The goal is cleared and the agent is informed.

4. ReAct cap (MAX_GOAL_REACT = 12): Prevents infinite token burn on a never-satisfiable condition. After 12 judge-driven re-entries, the agent stops regardless.

5. Re-entry mechanism: When the judge says "not yet", a synthetic user message is injected:

   The judge evaluating your goal "<condition>" found it is not yet satisfied:
   <judge's reason>
   Continue working toward the goal. Do not repeat actions that have already failed.
   

6. State lifecycle: Goal state lives in InstanceState (per-project instance), keyed by session ID. It is cleared on instance teardown (not persisted across process restarts).

Integration with Other Features

• Task gate: The goal evaluation runs after the task gate check. The order is: (1) model finishes a turn, (2) task gate checks for incomplete tasks, (3) if tasks are complete, goal judge evaluates. This means goals and tasks work together: tasks track the work items, goals track the overall condition.
• Context management: Goal evaluation is a full LLM call that reads the entire conversation, so it is subject to the same context limits. Checkpoints and compaction ensure the judge has a coherent view even for long sessions.
• Bus events: SessionGoal.Updated events carry the active goal (or undefined when cleared) and the latest verdict. The TUI uses these to render the active-goal indicator and verdict status.

---

6. Dream & Distill

Overview

Dream and Distill are two complementary background agents that run automatically on session start to maintain and enrich the project's knowledge base over time. Dream consolidates session trajectories into durable project memory. Distill identifies repeated manual workflows and packages them into reusable assets (skills, agents, commands). Both are triggered by the main session run loop and run in detached background sessions, invisible to the user's current conversation.

Key Files

File	Purpose
src/session/auto-dream.ts	Auto-trigger scheduling logic (interval checks, spawn guards)
src/agent/prompt/dream.txt	System prompt for the Dream agent
src/agent/prompt/distill.txt	System prompt for the Distill agent
src/agent/agent.ts	Agent definitions (dream and distill agent configs)
src/session/prompt.ts	Run loop integration (fires dream/distill on first step of new session)
src/agent/config.ts	SYSTEM_SPAWNED_AGENT_TYPES set (marks dream/distill as system-spawned)

Configuration

Both features are controlled per-project via mimocode.json:

{
  "dream": {
    "auto": true,           // enable/disable auto-trigger (default: true)
    "interval_days": 7      // minimum days between runs (default: 7)
  },
  "distill": {
    "auto": true,           // enable/disable auto-trigger (default: true)
    "interval_days": 30     // minimum days between runs (default: 30)
  }
}

Agent Definitions

Both agents are registered as hidden subagents with restricted tool access:

Agent	Tools Allowed	Description
dream	read, write, edit, glob, grep, memory, bash	Memory consolidation. External directory access limited to the data/memory tree.
distill	read, write, edit, glob, grep, memory, bash	Workflow packaging. Same external directory restrictions as dream.

Both are marked in SYSTEM_SPAWNED_AGENT_TYPES, which means:

• They are excluded from prune/bootstrap/memory/recall scans.
• They get tool whitelist defaults.
• They run with interactive: false (no permission prompts to the user).

Auto-Trigger Logic (auto-dream.ts)

Both dream and distill use the same shouldAutoRun() scheduling logic:

1. Enabled check: If auto is false in config, skip immediately.
2. Spawn gap guard: A process-global timestamp (lastDreamSpawnTime / lastDistillSpawnTime) enforces a minimum 10-second gap between spawns, preventing rapid re-triggers from multiple session starts.
3. Interval check: Queries the SQLite session table for the most recent session titled "Auto Dream" (or "Auto Distill"). If less than interval_days have elapsed since the last run, skip.
4. First-run eligibility: On the very first run (no prior dream/distill session exists), the system checks whether the project is old enough to have anything worth processing. It looks at the earliest top-level session (no parent_id) and skips if the project is younger than the interval.

Integration with the Run Loop (prompt.ts)

Both agents are triggered at step === 1 of the main session run loop (the first LLM turn of a new top-level session, i.e., one without a parentID):

// Pseudocode from prompt.ts, line ~2253
if (step === 1 && !session.parentID) {
  const dreamTrigger = shouldAutoDream(cfg)
  const distillTrigger = shouldAutoDistill(cfg)

  if (dreamTrigger || distillTrigger) {
    // Dynamic import to avoid module-init cycle
    const { AppRuntime } = await import("@/effect/app-runtime")

    if (dreamTrigger) {
      // Create a new detached session titled "Auto Dream"
      // Fire-and-forget: runs in background, no await
      AppRuntime.runPromise(
        create session -> prompt(dream agent, DREAM_TASK)
      )
    }
    if (distillTrigger) {
      // Same pattern for distill
      AppRuntime.runPromise(
        create session -> prompt(distill agent, DISTILL_TASK)
      )
    }
  }
}

Key design points:

• Detached fire-and-forget: The dream/distill sessions run via AppRuntime.runPromise (not awaited), so they don't block the user's session.
• Separate sessions: Each run creates a brand-new session with the title "Auto Dream" or "Auto Distill". The title serves as the scheduling marker -- shouldAutoRun queries for sessions with that title to determine when the last run occurred.
• Inherits the parent's model: The dream/distill agents use the same model (providerID/modelID) as the user's current session.

Dream: Memory Consolidation

The Dream agent's system prompt (dream.txt) defines a 6-phase consolidation pipeline:

Phase 0 -- Locate Data: Use memory search with broad queries ("project", "session", "rule", "decision", "error"), glob/inspect memory paths, and locate the SQLite database. If memory is empty and there are no project sessions, stop.

Phase 1 -- Orient: Read the current project's MEMORY.md, session notes.md, recent checkpoint.md files, and query SQLite for recent sessions. Record the current MEMORY.md section structure to avoid duplicates.

Phase 2 -- Gather From Memory Files: Extract candidate durable facts from recent checkpoint files, task progress notes, and notes entries that aren't already in project memory. Prefers recent and repeated signals over exhaustive reading.

Phase 3 -- Verify Against Raw Trajectory: Cross-reference candidate facts against the raw trajectory database using read-only SQLite queries. Promotes a fact only when supported by:

• An explicit user statement
• A clear design decision
• Repeated evidence across sessions

Uses keyword searches in user turns for terms like "always", "never", "remember", "rule", "decision", "tradeoff", "repeat", "again", "every time" -- including equivalents in the user's language.

Phase 4 -- Consolidate: Edit the project's MEMORY.md using structured sections:

• ## Rules -- project-level rules explicitly stated by the user
• ## Architecture decisions -- decision + date + rationale
• ## Discovered durable knowledge -- cross-session durable facts
• ## Patterns -- repeated problems and solutions
• ## Gotchas -- easy-to-miss traps

Principles: merge duplicates, convert relative dates to ISO, remove contradicted entries, keep entries to 1-3 lines, preserve source session IDs.

Phase 5 -- Prune And Verify: Keep MEMORY.md under 200 lines / 10KB. Remove superseded entries, verify file paths with Glob, verify function/class names with Grep, mark unverifiable claims [unverified].

Output: Summary of consolidated/updated/deleted entries, workflow candidates (pointer to distill), and health metrics (line count/200, size/10KB).

Distill: Workflow Packaging

The Distill agent's system prompt (distill.txt) defines a 7-phase pipeline:

Phase 0 -- Locate Data: Same data discovery as Dream. Stops if there is no recent project activity.

Phase 1 -- Inventory Existing Assets: Before proposing anything, scan for existing skills, custom commands, custom agents, and plugins across config directories (.mimocode/, .claude/, .agents/, .opencode/). Record what each already covers.

Phase 2 -- Discover Repeated Workflows From Memory: Scan checkpoint files, task progress, notes, and MEMORY.md Patterns/Rules sections for recurring procedures. Prefer recent and repeated signals.

Phase 3 -- Confirm Against Raw Trajectory: Verify candidates against the raw database using read-only SQLite queries. Look for:

• Repeated tool/command usage (aggregated by tool + input preview)
• User turns containing "again", "every time", "like last time", "the usual"
• Repeated command sequences, file paths, and error/fix cycles

A candidate is only real when it occurred at least twice, or is clearly likely to recur and is costly to repeat.

Phase 4 -- Shortlist: Produce a compact shortlist with evidence, frequency/confidence, recommended form, and rationale. Only keep candidates that meet all criteria: repeated, stable inputs, repeatable procedure, material improvement, not already covered.

Phase 5 -- Choose The Smallest Form: Pick the smallest appropriate form for each high-confidence candidate:

• Skill: Write SKILL.md with YAML frontmatter under .mimocode/skills/<name>/
• Custom subagent: Write .mimocode/agent/<name>.md with frontmatter and system prompt
• Command: Write .mimocode/command/<name>.md with template body using $ARGUMENTS/$1
• Automation: Package as a re-runnable command (no built-in scheduler)
• Extend existing: Edit an existing asset rather than duplicating
• Skip: Too one-off, ambiguous, or poorly evidenced

Phase 6 -- Create And Validate: Create only high-confidence items. Keep them narrow, practical, and easy to validate. Verify referenced paths and names after writing.

Output: Shortlist with evidence, created/extended assets with paths, skipped items with reasons, and candidates needing more evidence. "Created nothing" is a valid successful result.

Complementary Roles

Dream and Distill have intentionally non-overlapping responsibilities:

Aspect	Dream	Distill
Purpose	Consolidate facts into memory	Package workflows into assets
Output target	MEMORY.md (project memory)	.mimocode/skills/, .mimocode/agent/, .mimocode/command/
Default interval	7 days	30 days
Key verb	Consolidate	Package
Handoff	Notes workflow candidates for distill	Consumes dream's memory as input

The dream prompt explicitly states: "If you notice a repeated manual workflow worth packaging, leave it to the /distill command. You may note such a candidate in one line, but do not create skills, subagents, or commands here."

---

Feature Interactions

The six features form a tightly integrated autonomous coding system. This section describes the concrete interaction pathways between them.

Interaction Architecture

                         ┌──────────────────────────────────────────┐
                         │           User's Session                  │
                         │                                           │
   /goal ──────────────> │  ┌─────────────────────────────────┐     │
   "all tests pass"      │  │        Run Loop (prompt.ts)      │     │
                         │  │                                   │     │
                         │  │  Step 1:                          │     │
                         │  │   ├─ Auto-dream trigger ──────┐  │     │
                         │  │   └─ Auto-distill trigger ───┐│  │     │
                         │  │                               ││  │     │
                         │  │  Each turn:                    ││  │     │
                         │  │   ├─ fireCheckpoints() ───┐   ││  │     │
                         │  │   ├─ LLM call             │   ││  │     │
                         │  │   └─ prune() ─────────────┐│   ││  │     │
                         │  │                            ││   ││  │     │
                         │  │  Turn end:                  ││   ││  │     │
                         │  │   ├─ Task gate ──────┐      ││   ││  │     │
                         │  │   └─ Goal judge ───┐ │      ││   ││  │     │
                         │  │                     │ │      ││   ││  │     │
                         │  └─────────────────────┼─┼──────┼┼──┼┼──┼─────┘
                         │                        │ │      ││  ││  │
     ┌───────────────────┘              ┌─────────┘ │      ││  ││  │
     │  Goal judge is an independent    │ Task gate │      ││  ││  │
     │  LLM call reading the full       │ re-enters │      ││  ││  │
     │  conversation transcript         │ if tasks  │      ││  ││  │
     │                                  │ remain    │      ││  ││  │
     ▼                                  ▼           │      ││  ││  │
┌─────────┐                        ┌─────────┐     │      ││  ││  │
│  Goal   │                        │  Task   │     │      ││  ││  │
│  Judge  │                        │  Gate   │     │      ││  ││  │
└─────────┘                        └─────────┘     │      ││  ││  │
                                                   │      ││  ││  │
     ┌─────────────────────────────────────────────┘      ││  ││  │
     │  Checkpoint writer is a fork subagent that          ││  ││  │
     │  captures parent's LLM prefix for cache reuse       ││  ││  │
     │  and writes checkpoint.md, memory.md, etc.          ││  ││  │
     ▼                                                     ││  ││  │
┌──────────────────┐   ┌──────────────────┐               ││  ││  │
│  Checkpoint      │   │  Pruning         │               ││  ││  │
│  Writer (fork)   │   │  (soft/hard trim)│               ││  ││  │
└──────────────────┘   └──────────────────┘               ││  ││  │
         │                                                ││  ││  │
         ▼                                                ││  ││  │
┌──────────────────┐   ┌──────────────────────────────────┘│  ││  │
│  Memory Files    │   │  Background sessions               │  ││  │
│  (disk + FTS5)   │   │                                     │  ││  │
│                  │   │  ┌─────────┐   ┌─────────┐         │  ││  │
│  checkpoint.md   │   │  │  Dream  │   │ Distill │         │  ││  │
│  memory.md       │   │  │ (7d)    │   │ (30d)   │         │  ││  │
│  progress.md     │   │  └─────────┘   └─────────┘         │  ││  │
│  notes.md        │   │       │              │              │  ││  │
└──────┬───────────┘   └───────┼──────────────┼──────────────┘  ││  │
       │                        │              │                 ││  │
       │  memory search tool ───┘──────────────┘                 ││  │
       │  (BM25 over FTS5)                                      ││  │
       │                                                         ││  │
       │  ┌──────────────────────────────────────────────────────┘│  │
       │  │  Prune fires checkpoints at context-window %,        │  │
       │  │  then soft/hard-trims tool outputs at pressure       │  │
       │  │  levels 1/2.                                         │  │
       └──┘                                                       │  │
                                                                    │  │
     ┌──────────────────────────────────────────────────────────────┘  │
     │  Actor tool / Workflow engine                                   │
     │  Spawns subagents (general, explore) or runs QuickJS scripts    │
     │  Each subagent has its own compaction, task gate, and outcome   │
     └─────────────────────────────────────────────────────────────────┘

Detailed Interaction Pathways

A. Context Management <-> Persistent Memory

Context management is the primary writer of persistent memory, and persistent memory is a reader for the agent's working context.

1. Checkpoint Writer writes Memory: As context pressure builds, prune.ts fires checkpoint writers at percentage thresholds. Each checkpoint writer (a fork subagent) writes structured Markdown files to the memory tree: checkpoint.md (session summary), memory.md (project knowledge), and tasks/<id>/progress.md (task progress). These files are the on-disk representation that the FTS5 index later serves up.

2. Compaction reads Memory: When compaction fires, the summary template instructs the compaction agent to preserve "Discoveries" and "Relevant files" -- information that was often originally captured by a prior checkpoint writer. The compaction summary effectively compresses what checkpoint writers expanded.

3. Budgeted Reads protect Memory files: When the main agent reads large memory files (e.g., a verbose MEMORY.md), budgeted-read.ts ensures the content fits within a token budget by truncating body sections while preserving headers and index lines -- keeping the navigational skeleton intact.

4. Memory Reconciliation on Search: Every memory search call triggers reconciliation (reconcile.ts), which syncs the FTS5 index with the latest checkpoint-writer output. This means an agent can search for information that was written by a checkpoint writer earlier in the same session.

B. Task Tracking <-> Subagent System

Task tracking and the subagent system are tightly coupled: tasks track who is doing what, and the subagent system provides the "who."

1. Task Ownership = Actor ID: When a subagent starts a task via task start T1, the task's owner field is set to the actor's agentID. This ownership flows through to the task gate: a subagent's stop-gate only checks tasks it owns, while the main session's gate checks all tasks (catching orphaned subagent tasks).

2. Task Assignment at Spawn: The actor tool accepts an optional task_id parameter. When provided, the spawned actor's start logic sets the task's owner to the actor's ID, creating a direct binding between the actor and its assigned work item.

3. Task Gate in Spawn Lifecycle: The spawn lifecycle (spawn.ts) has two task-gate checkpoints:

   • Pre-stop gate (MAX_PRE_REACT = 3): Before the actor's run loop exits, checks for incomplete tasks owned by the actor.
   • Post-stop gate (MAX_POST_REACT = 3): After the actor stops, a final check with nudges.

   This ensures subagents don't silently abandon tasks. If a subagent is part of a workflow, the workflow's never-throw contract means the agent resolves to null on failure -- but the task gate's nudges give the agent chances to complete or explicitly abandon first.

4. Task Progress Files and Checkpoints: The checkpoint writer reads active tasks from the TaskRegistry and writes tasks/<id>/progress.md and tasks/<id>/notes.md files into the memory tree. These files serve as the human-readable, persistent record of task progress that survives compaction and session boundaries.

C. Goal / Stop Condition <-> Task Tracking

Goals and tasks operate at different abstraction levels but interact in the run loop's stop pipeline.

1. Ordered Evaluation: In the main session run loop (prompt.ts), after each assistant turn:

   • First, the task gate checks for incomplete tasks and may nudge.
   • Then, if no tasks remain (or the cap is hit), the goal judge evaluates the transcript against the goal condition.

   This ordering means tasks are the "work items" layer and goals are the "overall condition" layer. An agent working toward a goal will typically create tasks for the individual steps, and both systems cooperate to keep the agent working.

2. Different ReAct Caps: Goals have a much higher cap (MAX_GOAL_REACT = 12) than the task gate (MAX_TASK_GATE_MAIN_REACT = 3). This is intentional: the goal judge is an independent model call that can distinguish "genuinely impossible" from "still working," while the task gate has no such intelligence and must be conservative.

3. Goal Overrides Stop: Even if no tasks remain, a set goal prevents the session from stopping. The goal judge is the ultimate arbiter of whether the work is done. Tasks can all be done but the goal condition may still be unsatisfied (e.g., "all tests pass" is not met despite completing the implementation task).

D. Dream & Distill <-> Persistent Memory

Dream and distill are the primary maintenance agents for the persistent memory system.

1. Dream writes Memory: The dream agent's output is edits to the project's MEMORY.md. It consolidates information from raw session trajectories, checkpoint files, and task progress into durable, verified knowledge entries. Dream is the primary mechanism by which session-specific information is promoted to project-level memory.

2. Distill writes Assets (not Memory): Distill's output is reusable workflow assets (skills, agents, commands) written to .mimocode/. It does not directly edit MEMORY.md, but it reads memory files to discover cross-session patterns. The dream agent may leave one-line pointers ("consider running /distill") when it spots a repeated workflow.

3. Memory Search as Discovery Tool: Both dream and distill use the memory tool (BM25 search) as their first discovery step (Phase 0), issuing broad queries to understand the current state of the knowledge base. Dream searches for "project", "session", "rule", "decision", "error"; distill searches for "workflow", "repeat", "every time", "rule", "decision".

4. Reconciliation: After dream writes new memory files, the next memory search call triggers reconciliation, which indexes the new content into FTS5. This means dream's output is immediately available for future memory searches (including by the next dream or distill run).

E. Dream & Distill <-> Context Management

1. Dream/Distill are Checkpoint-Exempt: Because dream and distill are registered in SYSTEM_SPAWNED_AGENT_TYPES, the checkpoint system (prune.ts) skips them when firing thresholds. This prevents a self-referential loop where a background consolidation session triggers its own checkpoint writers.

2. Dream/Distill use Budgeted Reads: When reading large memory files or trajectory data, the dream/distill agents benefit from the same budgeted-read infrastructure that protects the main agent's context window. Section-aware truncation preserves the navigational skeleton of MEMORY.md.

F. Subagent System <-> Context Management

1. Per-Actor Compaction: Compaction is scoped by agentID. Each subagent's context is compacted independently of the main session and other subagents. The filterCompactedEffect method in MessageV2 accepts an optional agentID parameter that scopes the message stream to a specific actor.

2. Fork Agents for Cache Alignment: The checkpoint writer is a fork agent that captures the parent's full LLM request prefix at spawn time. This ensures:

   • The fork's system prompt and tool schema match the parent exactly.
   • The LLM provider can reuse the cached prompt prefix (saving input tokens and latency).
   • The fork writes memory files with full context of what the parent was working on.

3. Workflow Agent Timeouts: The workflow runtime supports per-agent wall-clock timeouts (agentTimeoutMs). If a subagent hangs (e.g., an LLM with high time-to-first-token), the runtime cancels it and resolves the agent call to null rather than letting it stall the workflow's parallel/pipeline barriers. This prevents one stuck subagent from consuming the entire context window through accumulated token usage.

G. Goal / Stop Condition <-> Context Management

1. Goal Judge Reads Full Transcript: The goal judge receives the full conversation as native model messages (including tool calls/results/images). For long sessions where compaction has occurred, the judge sees the compaction summary rather than the original messages. This means the judge's evaluation is based on the compacted representation -- which is by design, since the compaction summary preserves the goal, instructions, discoveries, and accomplished work.

2. Goal Evaluation Token Cost: Each goal judge call is a full LLM inference over the entire transcript. In a session with high context pressure, this adds to the token budget. The checkpoint system ensures that the transcript stays within bounds so the judge call doesn't itself trigger overflow.

H. Subagent System <-> Dream & Distill

1. Dream/Distill Run as Subagents: Both dream and distill are registered as hidden subagents (mode: "subagent") with restricted tool whitelists. They are spawned via the same actor infrastructure that powers the actor tool, but they run in detached background sessions rather than sharing the user's session.

2. Dream/Distill Sessions are Scheduling Markers: The auto-trigger logic (auto-dream.ts) queries the session table for sessions titled "Auto Dream" or "Auto Distill". These sessions are ordinary session rows -- they show up in session history, have messages, and can be inspected. Their titles serve as the scheduling signal.

3. System-Spawned Classification: Both agents are in SYSTEM_SPAWNED_AGENT_TYPES, which means:

   • The actor registry's stuck-actor scanner doesn't count them (they're expected to be long-running).
   • The checkpoint system doesn't fire checkpoint writers for their sessions.
   • Memory recall searches skip their messages (they're system maintenance, not user work).

---

Summary

The six features form a layered autonomous coding platform:

Layer	Features	Role
Orchestration	Goal / Stop Condition	"When to stop" -- autonomous goal-directed execution with independent verification
Work Management	Task Tracking	"What to do" -- structured work items with ownership, hierarchy, and stop-gates
Execution	Subagent System	"Who does it" -- parallelized, delegated, and orchestrated agent execution
Context	Context Management	"What fits" -- keeping conversations within limits while preserving key information
Knowledge	Persistent Memory, Dream & Distill	"What we know" -- cross-session knowledge storage, consolidation, and workflow discovery

The system is designed so each layer is independently useful but gains power from integration: tasks get tracked across subagent boundaries, context management preserves task progress in memory, goals operate above tasks, and dream/distill maintain the knowledge base that all layers depend on.

---

7. MiMo-Code and OpenCode: Relationship and Differentiation

This section investigates how MiMo-Code incorporates and extends the open-source OpenCode project.

Provenance

MiMo-Code is a snapshot fork of OpenCode, not a git fork. The MiMo-Code repository begins with a single "Initial open-source release" commit containing the full codebase, with no shared git ancestry. It was based on an OpenCode snapshot from early-mid 2025, before OpenCode's subsequent refactoring into a deep multi-package architecture (packages/core, packages/tui, packages/llm, etc.). MiMo-Code then independently evolved the codebase in a fundamentally different direction.

Architectural Simplification

OpenCode factors its code into ~26 packages in a deep monorepo:

OpenCode Package	Role
packages/core/	Shared types, Effect runtime, schema, events, filesystem, config, permissions
packages/llm/	LLM provider abstraction
packages/tui/	Terminal UI (opentui-based)
packages/cli/	CLI entry point
packages/server/	HTTP server
packages/effect-drizzle-sqlite/	Effect wrapper for Drizzle SQLite
packages/effect-sqlite-node/	Effect wrapper for Node SQLite

MiMo-Code collapsed most of this into essentially two packages:

MiMo-Code Package	Role
packages/opencode/	The entire application (CLI, server, TUI, agents, workflows, memory, etc.)
packages/shared/	Shared utilities (filesystem, global paths, file locking, utility functions)

The core abstractions that OpenCode provides via @opencode-ai/core (Effect Schema types, event system, runtime utilities, schema definitions) were rewritten inline in MiMo-Code using:

• Zod instead of Effect Schema for all schema definitions
• Local BusEvent instead of @opencode-ai/core's event system
• Direct Drizzle instead of effect-drizzle-sqlite
• Inline modules instead of cross-package imports

What MiMo-Code Inherited from OpenCode

The following subsystems originate from OpenCode and remain recognizably similar in MiMo-Code:

Subsystem	Description
Session management	Session creation, message storage, message parts (text, tool, reasoning, file, compaction), the basic run loop structure
LLM provider abstraction	Provider/model resolution, streaming, token counting, the ai SDK integration
Tool system	Tool definition framework, tool registration, the basic set of tools (bash, read, write, edit, glob, grep)
Config system	mimocode.json/opencode.json parsing, config directory resolution, agent/model/permission configuration
Permission system	Permission rulesets, allow/deny/ask actions, path-based and tool-based permission rules
Plugin system	Plugin lifecycle hooks, plugin loading from .opencode/ / .mimocode/ directories
MCP integration	Model Context Protocol server discovery and tool exposure
Git integration	Git operations, worktree management, diff/status
IDE integration	LSP server, IDE detection
Compaction	The basic compaction mechanism (summarize old conversation, preserve recent tail)
Skill system	Skill loading from .opencode/skills/ / .mimocode/skills/ directories
Sync	Cross-device session synchronization
Auth	Provider authentication (API keys, OAuth)
Storage	SQLite database layer (Drizzle ORM)
CLI/TUI	Terminal user interface (forked from opentui)

What MiMo-Code Added on Top of OpenCode

The following subsystems were built entirely by MiMo-Code and have no equivalent in OpenCode:

New Modules (directories)

Module	Lines (approx.)	Description
src/actor/	~1,500	Full multi-agent actor system: spawn, registry, lifecycle, inbox, waiter, stuck detection
src/workflow/	~2,500	QuickJS-sandboxed workflow orchestration: runtime, sandbox, persistence, journaling, built-in workflows
src/task/	~600	Structured task management: hierarchical IDs, lifecycle state machine, event sourcing, completion gate
src/memory/	~350	Persistent memory with FTS5 search: reconciliation, BM25 ranking, Claude Code interop
src/history/	~400	FTS5 full-text search over conversation history: incremental indexing, context retrieval
src/inbox/	~200	Inter-actor asynchronous message passing: DB-backed inbox, wake-on-arrival
src/metrics/	~250	Telemetry/analytics: model call, tool call, and agent request metrics
src/team/	~100	Multi-agent team coordination: team directories, member management
src/file/	~300	Filesystem service (inlined from @opencode-ai/core/filesystem)
src/flag/	~100	Feature flags via MIMOCODE_* environment variables
src/global/	~50	Global path resolution with cache versioning
src/npm/	~100	NPM package management for sandboxed installs

Major New Files in Existing Modules

File	Lines	Description
src/session/checkpoint.ts	~1,478	Session checkpointing: fork-agent writers, threshold-based triggers, progress reconciliation
src/session/goal.ts	~232	Per-session stop conditions with independent judge model
src/session/auto-dream.ts	~123	Auto-triggering of dream/distill background agents
src/session/prune.ts	~481	Enhanced pruning with checkpoint-based recovery (OpenCode's prune is simpler)
src/session/budgeted-read.ts	~118	Token-budgeted file reading with section-aware truncation
src/session/run-state.ts	~135	Per-session, per-agent runner management
src/session/checkpoint-*.ts	~600	Supporting modules: paths, templates, alignment, validation, retry, context, progress
src/tool/actor.ts	~803	Multi-verb actor tool (run/spawn/status/wait/cancel/send)
src/tool/workflow.ts	~164	Workflow tool (run/status/wait/cancel/resume)
src/tool/memory.ts	~81	Memory search tool
src/tool/history.ts	~80	History search tool
src/agent/prompt/dream.txt	~155	Dream agent system prompt
src/agent/prompt/distill.txt	~199	Distill agent system prompt
src/agent/prompt/checkpoint-writer.txt	~80	Checkpoint writer agent system prompt

Key Rewrites of OpenCode Subsystems

Subsystem	OpenCode Approach	MiMo-Code Approach
"Task" tool	Launches subagent sessions (foreground/background)	Repurposed as task tracker: create/list/get/start/block/unblock/done/abandon/rename. Subagent launching moved to the new actor tool.
Schema system	Effect Schema (Schema.Struct, Schema.filter, etc.)	Zod (z.object, z.enum, z.discriminatedUnion, etc.) throughout
Compaction	Simple summarization with tail preservation	Enhanced with plugin hooks, protected tool awareness, preserve_recent_tokens budget calculation, per-actor scoping
Context overflow	Compaction-only (summarize when overflow)	Multi-layered: checkpoint writes at thresholds, rebuild-from-checkpoint, pruning (soft/hard), pressure levels, budgeted reads
Agent definitions	Simple agent configs in agent.ts	Expanded with modelRef (model group resolution), toolAllowlist, and three new hidden agents (dream, distill, checkpoint-writer)

Claude Code Compatibility Layer

A significant effort in MiMo-Code that has no equivalent in OpenCode: maintaining compatibility with Anthropic's Claude Code ecosystem.

Feature	Implementation
Session import	src/session/claude-import.ts reads Claude Code's SQLite databases and imports conversations
Memory indexing	src/memory/reconcile.ts optionally indexes ~/.claude/projects/<slug>/memory/*.md
MCP server inheritance	Discovers Claude Code's .claude/ MCP server configs
Commands/skills loading	Reads Claude Code's command and skill files
Granular disable flags	MIMOCODE_DISABLE_CLAUDE_CODE_* env vars for each compatibility layer
Settings compatibility	Reads Claude Code's settings files when MIMOCODE_MIMO_ONLY is not set

Dependency Differences

Aspect	OpenCode	MiMo-Code
Binary name	opencode	mimo
Package name	opencode	mimocode
Schema library	Effect Schema	Zod
LLM provider package	@opencode-ai/llm	Inline src/provider/
Core package	@opencode-ai/core	Inline + @mimo-ai/shared
Effect version	effect@beta.74	effect@beta.48
TUI framework	@opentui/core@0.3.x	@opentui/core@0.1.x
Workflow sandbox	N/A	quickjs-emscripten
Unique deps	@ff-labs/fff-bun, photon-node, htmlparser2, ws	quickjs-emscripten
Bun version	1.3.14	1.3.11

Scale Comparison

Metric	OpenCode (packages/opencode/src/)	MiMo-Code (packages/opencode/src/)
Top-level directories	45	54 (+9 new)
TypeScript files (approx.)	350	478 (+128 new)
Lines of code (approx.)	74,000	86,000 (+12,000 new)
Unique tools	~15	~25 (+10 new)
Agent types	7	12 (+5 new)

Summary of the Relationship

MiMo-Code's relationship to OpenCode can be characterized as:

1. Foundation: MiMo-Code builds on OpenCode's core infrastructure (session management, LLM providers, tool system, config, permissions, TUI, storage). These inherited systems handle the fundamentals of a coding agent.

2. Autonomous agent platform: MiMo-Code's primary addition is a comprehensive autonomous agent platform layered on top of OpenCode's foundations: the actor system, workflow engine, task management, persistent memory, goal system, and checkpoint-based context management. These transform OpenCode from an interactive coding assistant into a platform for autonomous, multi-agent, goal-directed coding workflows.

3. Architecture consolidation: MiMo-Code simplified OpenCode's 26-package monorepo into 2 packages, replacing Effect Schema with Zod and inlining cross-package dependencies. This reduces indirection at the cost of a larger single package.

4. Ecosystem compatibility: MiMo-Code added a Claude Code compatibility layer (session import, memory indexing, MCP inheritance) that OpenCode does not have.

5. Divergent evolution: After the initial snapshot fork, the two codebases have evolved independently. OpenCode has continued refactoring its package structure and adding features like a v2 server API and connector authentication. MiMo-Code has focused on building out the autonomous agent platform described in this report.

---

8. Attribution Analysis: Third-Party and Plugin-Originated Features

This section examines the extent to which MiMo-Code's claimed features are original implementation versus code, designs, or skills derived from existing open-source projects -- particularly the Superpowers plugin for OpenCode (https://github.com/obra/superpowers by Jesse Vincent) and other community plugins.

8.1 The Superpowers Plugin

Superpowers is an MIT-licensed OpenCode plugin by Jesse Vincent that provides an "agentic skills framework": a collection of structured skill prompts (plan, execute, debug, review, etc.) that teach an LLM how to work through complex multi-step development tasks. It is an optional plugin -- users add it to their opencode.json and it injects skills via the plugin hook system.

8.2 Superpowers Skills Bundled as "Compose" Skills

MiMo-Code embeds a modified version of the entire Superpowers skill suite directly into the binary, rebranded as "compose" skills. This is not a plugin -- the skills are compiled into the application at build time via a Bun macro (bundle.macro.ts) that reads the .bundle/ directory and inlines the content.

Licensing

MiMo-Code includes a LICENSE-superpowers file that correctly attributes the skills to Jesse Vincent under the MIT License. A separate LICENSE-karpathy file attributes portions to the andrej-karpathy-skills project by multica-ai (also MIT).

Skill-by-Skill Comparison

The following table maps each Superpowers skill to its MiMo-Code compose counterpart:

Superpowers Skill	MiMo-Code Compose Skill	Relationship
executing-plans	execute	Significantly modified -- task tool integration, compose:ask for blockers, autonomous fallback
writing-plans	plan	Significantly modified -- spec section anchors, structured execution handoff with memory-persisted preferences
brainstorming	brainstorm	Significantly modified -- autonomous override gates, spec section anchors, compose:ask structured options
subagent-driven-development	subagent	Significantly modified -- spec-anchored review gate, two-phase evidence-gated review, task binding with TIDs
dispatching-parallel-agents	parallel	Minor rename/reformat -- superpowers: references changed to compose:
systematic-debugging	debug	Minor rename/reformat -- compose:ask for structured options
test-driven-development	tdd	Minor rename/reformat -- compose:ask for structured options
using-git-worktrees	worktree	Significantly modified -- memory-persisted consent, compose:ask for all user interactions
verification-before-completion	verify	Near-identical -- only naming changes
writing-skills	new-skill	Minor rename/reformat -- TodoWrite replaced with task tool
requesting-code-review	review	Minor rename/reformat -- Task tool dispatch changed to actor tool
receiving-code-review	feedback	Minor rename/reformat -- compose:ask for structured options
finishing-a-development-branch	merge	Significantly modified -- compose:ask for all confirmations, autonomous safe defaults
(none)	ask	Entirely new -- structured question-asking protocol with autonomous fallback
(none)	report	Entirely new -- implementation report writing with spec cross-linking
using-superpowers	(not ported)	Bootstrap/intro skill -- not needed when bundled

Universal Changes Across All Skills

Every ported skill has systematic find-replace changes:

• superpowers:X -> compose:X in all cross-references
• TodoWrite -> task tool / task create / task done <TID>
• Task("general-purpose", ...) -> actor run general ... dispatch syntax
• docs/superpowers/ -> docs/compose/ in all paths
• ~/.config/superpowers/ -> ~/.config/compose/
• All user-facing questions converted from free-text to compose:ask with structured options

What Was Added to the Skills

The primary additions to the superpowers skills are:

1. Autonomous mode: Every user interaction point has a "when no user is available" fallback that decides autonomously -- critical for MiMo-Code's unattended agent execution.
2. compose:ask integration: All free-text questions replaced with structured multiple-choice options via the question tool.
3. Task tool integration: TodoWrite references replaced with MiMo-Code's task tracking tool and hierarchical task IDs.
4. Spec section anchors: New [S1], [S2]... bracketed IDs in specs that link plan tasks back to spec sections -- used by the two-phase review gate in compose:subagent.

8.3 Superpowers Specs Referenced in Engine Code

MiMo-Code's engine source code contains 10 references to superpowers spec documents that do not exist in the MiMo-Code repository:

Source File	Referenced Spec
src/actor/spawn.ts:88	docs/superpowers/specs/2026-05-26-fork-agent-prefix-cache-design.md
src/agent/agent.ts:296	docs/superpowers/specs/2026-05-26-fork-agent-prefix-cache-design.md
src/agent/agent.ts:312	docs/superpowers/specs/2026-06-05-checkpoint-writer-permission-deadlock-design.md
src/session/llm-request-prefix.ts:47	docs/superpowers/specs/2026-05-26-fork-agent-prefix-cache-design.md
src/session/prune.ts:42	docs/superpowers/specs/2026-06-03-checkpoint-threshold-density-design.md
src/session/checkpoint.ts:121	docs/superpowers/specs/2026-06-03-rebuild-tail-microcompact-design.md
src/session/checkpoint.ts:643	docs/superpowers/specs/2026-06-09-checkpoint-writer-child-session-and-no-fork-fallback-design.md
src/session/checkpoint.ts:699	docs/superpowers/specs/2026-05-26-fork-agent-prefix-cache-design.md
src/session/checkpoint.ts:1353	docs/superpowers/specs/2026-06-03-rebuild-tail-microcompact-design.md
src/session/prompt.ts:2398	docs/superpowers/specs/2026-04-28-bounded-computation-agents-design.md

These specs are dated 2026-04-28 through 2026-06-09 and cover design decisions for:

• Fork agent prefix cache alignment (the ForkContext mechanism)
• Checkpoint threshold density (the percentage-based trigger schedule)
• Rebuild-from-checkpoint with tail microcompact
• Checkpoint writer permission deadlock avoidance
• Bounded computation agents

None of these spec documents exist in the public Superpowers repository (which has specs only through 2026-04-06). The specs appear to be private/internal design documents that were referenced in the code but not included in the MiMo-Code repository. This strongly suggests that the engine-level features (fork agents, checkpoint threshold system, permission deadlock design) were designed using the Superpowers project's spec-driven workflow and likely in collaboration with or under guidance from the Superpowers author.

8.4 Feature Attribution Summary

The following table assesses the origin of each MiMo-Code feature described in this report:

Feature	Core Engine Code	Skills / Prompts	Attribution
Persistent Memory (FTS5 search, reconciliation, memory paths)	Original to MiMo-Code. No equivalent in OpenCode or Superpowers.	N/A	MiMo-Code original
Intelligent Context Management (pressure levels, budgeted reads)	Partially original. OpenCode has basic compaction; MiMo-Code added pressure levels, budgeted reads, checkpoint-based recovery. Design informed by superpowers specs.	N/A	Enhanced from OpenCode, design influenced by Superpowers specs
Checkpoint Writer (fork agent, threshold triggers, progress files)	Original to MiMo-Code. Fork-agent pattern, threshold schedule, checkpoint templates all new. Design specs reference superpowers spec naming convention.	checkpoint-writer.txt prompt is original	MiMo-Code original, design pattern possibly from Superpowers collaboration
Compaction	Inherited from OpenCode. Enhanced with per-actor scoping, plugin hooks, protected tools.	N/A	Enhanced from OpenCode
Task Tracking (hierarchical IDs, lifecycle, event sourcing, gate)	Original to MiMo-Code. The concept of task tracking was suggested by superpowers' TodoWrite references, but the entire implementation (SQL schema, registry, gate, gate-state) is new.	N/A	MiMo-Code original (concept possibly inspired by Superpowers' TodoWrite usage)
Subagent System (actor registry, spawn lifecycle, inbox, waiter)	Partially original. OpenCode has a simpler task tool that launches subagent sessions. MiMo-Code replaced it with a comprehensive actor system (actor/, inbox/, workflow/).	N/A	Significantly extended from OpenCode's basic subagent launching
Workflow Engine (QuickJS sandbox, persistence, journaling)	Original to MiMo-Code. No equivalent in OpenCode or Superpowers.	N/A	MiMo-Code original
Goal / Stop Condition (judge model, ReAct cap)	Original to MiMo-Code. No equivalent in OpenCode or Superpowers.	N/A	MiMo-Code original
Dream & Distill (auto-trigger, consolidation, packaging)	Original to MiMo-Code. No equivalent in OpenCode or Superpowers.	dream.txt, distill.txt prompts are original	MiMo-Code original
Compose Skills (plan, execute, debug, review, etc.)	Not engine code -- these are prompt-only skills.	Derived from Superpowers. 13 of 15 skills are modified ports of superpowers skills; 2 are new (ask, report). All auxiliary files (scripts, templates, prompts) are carried over from superpowers.	Derived from obra/superpowers (MIT), with MiMo-Code modifications for autonomous mode and task tool integration
Compose Skill Integration (extraction, bundling, compose agent)	Original to MiMo-Code -- the bundling mechanism (bundle.macro.ts, extract.ts) and the compose primary agent that orchestrates skills are new.	N/A	MiMo-Code original

8.5 Assessment

Engine features are predominantly original. The core systems -- persistent memory, the actor model, workflow engine, task tracking, goal system, checkpoint writer, dream/distill -- have no direct equivalent in OpenCode or any known OpenCode plugin. These represent substantial original engineering by the MiMo-Code team.

The "Compose" skill suite is derived from Superpowers. 13 of 15 compose skills are modified versions of Superpowers skills by Jesse Vincent, with systematic adaptations for MiMo-Code's tool ecosystem (task tool, actor tool, question tool) and autonomous operation mode. The attribution is correctly stated in LICENSE-superpowers.

The design language shows Superpowers influence. The code comments referencing docs/superpowers/specs/ documents (which don't exist in the public MiMo-Code repo) suggest that the Superpowers project's spec-driven design methodology was used to design some of the engine features -- particularly the fork-agent prefix cache, checkpoint threshold density, and permission deadlock avoidance. This is design influence rather than code copying.

One additional attribution: The LICENSE-karpathy file indicates portions of the compose "Simplicity guidelines" derive from the andrej-karpathy-skills project by multica-ai (MIT License).

In summary: MiMo-Code's differentiation from OpenCode rests on genuinely original engine work (actors, workflows, memory, goals, tasks, checkpoints, dream/distill). The Compose skill suite -- which powers the compose agent mode and is the primary user-visible "agentic workflow" feature -- is a bundled and modified version of the community Superpowers plugin, correctly attributed under the MIT License. The relationship is analogous to a Linux distribution bundling and customizing an upstream package: the core platform is new, but one of its key user-facing capabilities has upstream provenance that should be clearly communicated.