MonoMind AI Lab · The owner's deck
A central hub for the owner of many projects. Author the global knowledge once, set the guardrails that apply everywhere, and keep the latest context from every repository in a single private workspace — without ever asking a builder for access.
Part 1 · What it is
Each project already keeps its own record — its own state, its own decisions, its own learnings — and that is right: the people doing the work own the record of the work. What is missing is the other two halves.
Guardrails, workflows and the skills your agents use apply everywhere, so they get retyped everywhere — six repositories, six slightly different versions, and no answer to which one is current.
Seeing every project at once means cloning six repositories and reading six NOW.md files, one at a time, in six checkouts you do not otherwise keep.
Part 1 · What it is
No database, no service to log into, no runtime dependency. An agent reads it; so can you.
Part 1 · What it is
The repository anyone can read. It is a template: the commands, the record templates, and the onboarding material. It contains no organisation's records — not yours, not anyone's.
The repository you make from the scaffold. It holds your guardrails and a folder for every project. Builders hold no permission on it — not write, not read.
Part 1 · What it is
Project Context is the other half of the pair, and this deck assumes it. A repository with no Hub is a complete product; nothing on the repository side requires one.
Their state, their milestone
Their constraints and lessons
Plain Markdown · Git-tracked · no runtime dependency · portable
The tier that applies everywhere
A folder per project overseen
Part 2 · What you get
Identity, guardrails, workflows, goals, resources. Written once, in global/, and pushed into the repositories that need them.
Its mark — remote, branch, visibility, who builds it — your summary of it, and the blueprint you author: the goal it serves and the shape it has to keep.
A pull copies each repository's plan, tasks, decisions, learnings and open questions into pulled/. You read them here, together, without cloning anything.
owners_window/ is where you write about what is coming: half-formed projects, reflections, an argument with yourself.
Part 2 · What you get
Part 3 · How it works
Nothing in a project repository ever reaches out to a Hub. There is no call home, no registration, no credential. The direction is one way by construction: you have access to their repository because you administer it, and they have none to yours.
Hub → repository. Branch only, diff shown, you confirm
Repository → Hub. Read-only against their repository
Marks a repository, installs Project Context, then pushes
Part 3 · How it works
It is the only command that writes into a repository the Hub does not live in, so it is gated every single time.
A stamp naming a commit that does not contain those bytes is a false provenance record. --allow-dirty overrides.
An over-budget file is refused by name; so is a Hub whose own doctor reports errors. --skip-doctor overrides that one.
Uncommitted changes there stop it. The default branch is refused outright as a write target.
The prompt says plainly that this writes, pushes and opens a pull request. --yes skips it; a non-interactive session without it is declined, not assumed.
Switches to that branch, writes, stages only its own paths, and commits with Source-Commit: and Project-Id: trailers.
--set-upstream, and never --force. A repeated sync adds a commit rather than rewriting one, so a reviewer's place in an open request survives.
Against the default branch. An already-open request for that branch is updated, not duplicated.
Part 3 · How it works
This is the decision worth understanding, because it is about exposure rather than convenience. Push works from an allow-list, never a deny-list — so any folder you add to the Hub later is non-pushed by default, and needs no special case to stay put.
| Setting | Files | Why |
|---|---|---|
| Pushed by default | SUMMARY.md, GUARDRAILS.md, WORKFLOWS.md, skills/, shared/ — and that project's blueprint/ | What a builder needs to do the work correctly |
| Opt-in per project | GOALS.md, RESOURCES.md, people/, agents/ | Objectives across every project, internal dashboards, and a roster of people are each more sensitive than the guardrails a builder actually needs. Name one in that project's allow-list when you want it there |
| Never, at any setting | IDENTITY.md | A project repository may have collaborators outside the organisation. A Hub whose configuration lists it does not get to push it — the entry is dropped and you are told |
| Filtered automatically | Any README.md; any file still carrying the unfilled-seed marker | A README explains the Hub, not your organisation. An unfilled seed is a placeholder, and an empty guardrail in front of an agent is worse than no guardrail |
Part 3 · How it works
Every record you push is loaded on every session in every repository that has it. You pay for what you keep, so the budget is enforced at the boundary rather than left to discipline.
| Record | Words | Scope |
|---|---|---|
| global/SUMMARY.md | 150 | The global tier in one page |
| any one global/ file | 400 | Per file, whichever record it is |
| the whole pushed global subset | 2,000 | Everything the allow-list sends, added up |
| blueprint/EPIC.md | 600 | Per project — what it is for, and what must be true when it is done |
| blueprint/ARCHITECTURE.md | 1,200 | Per project — the shape it has to keep |
Push refuses before anything is written, and names the offending file with its word count and its limit. No branch is created, nothing reaches the repository, and no partial sync is left behind.
Frontmatter, fenced code and HTML comments are stripped first — otherwise a short record with a long example looks over budget while a wall of prose stays under it. Every number is overridable in the Hub's marker file; the identity rule is not.
Part 3 · How it works
owners_window/ is your room: future projects, reflections, the thing you will regret not writing down. No template, no naming convention, no schema.
It is not in the read order either. An agent working in the Hub opens it only when you name it.
| It has become | Write it as |
|---|---|
| A project that should exist | projects/<id>/MARK.md, then blueprint/EPIC.md |
| A rule that applies everywhere | A record in global/ — usually GUARDRAILS.md or WORKFLOWS.md |
| A change of direction | An edit to that project's blueprint/EPIC.md |
Freeform in, structured out. Promotion is a deliberate act and an ordinary edit — nothing automates it, and nothing should.
Part 4 · How to use it
Clone or fork it. Private, and it stays private — that is the governance model, not a setting you revisit.
Claude Code or Codex is where the onboarding agent runs. No Obsidian plugin is needed to start.
The scaffold ships the agent, so “set this up”, “activate the hub” or “onboard me” is enough. In a host with no agent format, paste the adapter prompt instead — it is the same seven steps.
It identifies the host, writes a thin pointer file for it, helps you seed the global tier, registers your first project, and offers to configure Obsidian. Then it reports what it wrote, what it skipped, and what is still empty.
Read ADAPTER-PROMPT.md at the root of this folder and follow it.
The agent runs with file tools only — no shell, no network. “Never runs git init, never adds a remote, never pushes” is a fact about what it is able to do, not a promise it makes. Anything touching Git is yours to run, or belongs to the commands.
Running it again is safe: it checks before every write and skips anything you have changed.
Part 4 · How to use it
A builder who disagrees with a guardrail, an epic item or an architecture record files a question, or captures a proposal capsule. Both sit in their repository until your next pull — they cost no permission, no fork, and no pull request against a repository they cannot see.
Each milestone item carries a Serves: line naming the blueprint/EPIC.md item it advances, and their doctor errors on one that names none. The asymmetry is deliberate: an epic item no plan serves is only a warning, because your epic is allowed to run ahead of the milestone in front of them.
Their own review lists what is waiting on a person, oldest first — including a stale-snapshot finding when the global tier you pushed has not been refreshed in ninety days. That one is aimed at you.
Part 4 · How to use it
Part 4 · How to use it
A guide that documents commands you cannot run is worse than one carrying a short list like this. Everything else in this deck is built and tested against v0.2.0.
Asking the Hub a question that spans every project. Retrieval works inside a repository today, and a builder's packet sees their project plus the global snapshot — the correct blast radius. Reading across the projects folder is the Hub's job, and is not built.
The pending list, oldest unanswered first, across every project. The repository-side review is built; the Hub does not yet aggregate them, so today you read what a pull brought up.
Deliberately deferred until an automated query proves slow. Never in a project repository.
Get started
Make a private repository from the scaffold, open it, and ask it to set itself up. Then register one project and push once — you will know inside an afternoon whether it earns its place.
Made with Hi Ted, Meet Lisa