Skip to content
/notes

Meet Mini-Me, the Context System Behind My Work

·9 min read
A woman with long brown hair seen from behind at a warm desk, surrounded by source notes, routing threads, and interface panels.

I keep a private working document for evaluating potential cofounder matches.

It maps the traits I value, what I notice in a room, what I write down afterwards, and when a promising match has earned a real trial. The underlying view is mine. It draws from notes on conversations, patterns I have observed in people I work well with, criteria I have refined over time, and principles about how founding relationships survive real work.

When I returned to the document, a previous chat still described my five-trait table as empty. It no longer was. All five traits had been defined, and the document had grown into a fuller system for evaluating matches without relying on chemistry alone.

If the agent had trusted the conversation, it would have been wrong before it wrote a sentence.

Mini-Me did not decide what I should value in a cofounder. It found the current document and the related context behind it, then brought my criteria, observations, and earlier decisions back into view. I could keep refining the system from what I had already learned instead of reconstructing it from whichever chat I happened to open.

That sequence is why I built Mini-Me.

Mini-Me is the context and behavior system around my work. It gives agents a way to find the current source, understand which action I authorized, use the right judgment process, and leave the work in a state the next agent can continue.

The quiet failure is context drift

A model inventing a fact is often easier to catch. Context drift can look competent.

One agent makes a reasonable decision. Another later overwrites it because the reason was never captured. A UI gets cleaned up and loses the detail that made it usable. A source note turns into a product claim without its evidence. A stale draft stays plausible enough that nobody checks the living source behind it.

By the time anyone notices, the work has already moved backwards.

Useful continuity is concrete: What is current? What changed? What remains uncertain? Which decision should survive the next edit? What action did I authorize?

Mini-Me started as a private context vault for that problem. It has since become an operating system for how I work with agents across projects.

Four surfaces, four owners

Mini-Me now has four connected surfaces, each with one owner:

mini-me-system  -> shared agent behavior
private-vault   -> private context
project repo    -> exact project state
companion       -> local interaction layer

mini-me-system is the shareable behavior layer. It owns canonical skills, routing rules, evals, templates, and the scripts that synchronize those instructions into the tools I use. When I improve how public writing should be reviewed or how architecture research should happen, I change the canonical behavior there once, then sync the generated adapters I use. Each project keeps its own authorization rules and current state.

private-vault holds the context that should stay private: source notes, identity and voice material, applications, project shelves, research, decisions, and the rough thinking behind public work. The skill folders inside the vault are generated adapters. They are copies of the shared behavior, never the canonical source.

Each project repo owns its exact state. The current code, data, content, branch, tests, and local handoff belong with the project. Mini-Me can route an agent there and explain the wider context, but it does not replace the live files.

Mini-Me Companion is the local interaction layer. It owns the desktop shortcuts, the provider contract that decides which context can be used, diagnostics and receipts, and the safe copy-or-paste flow. The drafting backend still runs through private-vault, while voice, memory, and exact project truth stay with their proper owners.

Inside the private vault, I still gave the context a character because I did not want to navigate a giant abstract graph. Knowledge maps to a brain, identity to a head, worldview to eyes, voice to a mouth, principles to a heart, decisions to a core, action modes to hands, and trajectory to feet. The map makes the context memorable; the ownership rules decide which file wins.

Routing is part of the context

Facts alone do not tell an agent how to behave.

Mini-Me uses a simple distinction:

  • a skill defines how the agent should act
  • a context file supplies what the agent should know
  • a router decides when to load each one

The shared skills are concrete. solution-architecture-preflight shapes serious product or architecture research before implementation. user-loving-product-design reviews flows, hierarchy, states, accessibility, and trust. lara-public-writing protects voice and public boundaries. context-handoff preserves a changed mental model. agent-task-operating-loop carries substantial implementation from context through verification. auditcodex reviews completed changes before I trust them.

The router also checks intent before choosing a workflow:

answer / review / diagnose -> read and report
preflight / research       -> recommend without editing
change / build             -> edit, verify, and close out

This matters because words such as "check," "review," or "make this better" should not quietly authorize a rewrite. The agent can inspect and propose. It edits when I ask it to apply the change.

Parallel work has a similar gate. Asking for 50 agents does not create 50 useful jobs. The mission runner becomes useful only when at least two non-overlapping task cards have distinct outputs, allowed context, stop conditions, and independent verification.

These rules sound procedural. In practice, they protect trust. An agent should know whether it is answering, evaluating, researching, or changing the system before it touches anything.

Project truth has different jobs

A single handoff file cannot carry all project memory without becoming a transcript dump.

The baseline I use when integrating an active project separates the jobs:

AGENTS.md / CLAUDE.md        startup and authorization rules
HANDOFF.md                   current durable truth
docs/project-log.md          dated work and session history
docs/decisions/README.md     index of durable decisions
live project files           exact implementation state

At the start of meaningful project work, the agent can use the vault's context checks to see whether those surfaces still agree:

npm run context:check -- --project /path/to/project
npm run context:sync -- --project /path/to/project

The check reports where project context may have drifted. The sync command proposes a direction; it does not silently rewrite either source. I review the proposal before anything durable changes.

This separation lets a future agent answer different questions without pretending one document knows everything. The handoff says what is true now. The project log says what happened. A decision record says why a durable choice was made. The code and content show what actually exists.

The private cofounder document was a useful test of this division. The live document held the five traits, room-test prompts, and match workflow. Related private files held my founding context, observations, and the decisions behind the framework. There was no public draft to polish and no reason to turn the document into content.

Together, those sources returned my own reasoning in a form I could use: the criteria I had already defined, the patterns behind them, and the places where an older note no longer matched my thinking. I could challenge a trait, refine the process, or keep the whole thing private. An agent working from the old chat would have started from a version of the document that no longer existed.

This is the continuity I care about. The system should make better judgment easier without turning private context into public copy or old context into current truth.

Taste has to survive the next model

Taste decay is fast in agent workflows. One model makes a paragraph generic. The next makes the generic paragraph smoother. A third explains why the polished version is stronger.

Mini-Me makes taste inspectable enough to challenge that process.

For public writing, Mini-Me retrieves the facts, scenes, artifacts, decisions, and earlier revision choices I need. An AI-polish detector flags generic patterns. I write, rewrite, and decide what the essay means.

The same principle applies elsewhere. Product reviews use explicit states, mobile behavior, accessibility, hierarchy, and the user's job. Research keeps its source and checked date before it informs a decision or public claim. Private material stays behind a publication boundary.

Durable taste needs more than a style guide. It needs the reasons behind accepted and rejected decisions, plus enough proof for a future agent to challenge them intelligently. The agent can still disagree or propose something new, but it has to contend with standards earned through real work.

The maintenance tax is real

Mini-Me still gets things wrong.

Context goes stale. A project shelf can duplicate a handoff and drift away from it. Generated adapters can fall behind their canonical skill. A broad instruction can accidentally select implementation when I only wanted a review. Even a freshness checker can identify a timestamp difference that turns out to be harmless.

As the system grew, I audited those failure modes instead of pretending the architecture had solved them. I tightened the intent gate, made parallel-agent work prove separability, added project-level logs and decision indexes, and removed stale copies of project truth from places that should only route.

The maintenance compounds. A failure I catch once can become a routing rule, an eval, or a shared skill that future models inherit. Mini-Me now gives me back more time than it takes to maintain. I spend less time rebuilding context, re-explaining decisions, and correcting work that started from the wrong assumptions.

The work will keep moving, so the system will keep needing care. What matters is that drift becomes visible early enough to correct, with a clear owner for the correction.

The point

The mental model I keep returning to is:

the model is a worker
the system owns the state
the human owns the judgment

I use the same principle in How I Use Agents to Maintain JMTE. There it protects the boundary between an agent candidate and a public claim. In Mini-Me, it protects the boundary between generated help and the context I am willing to trust later.

The public output is visible: essays, products, demos, replies, decisions. Mini-Me is the connective layer that helps those outputs accumulate instead of resetting every time I open a new chat.

I am building it so my work can continue without flattening the source, the taste, or the reasoning that made it mine.