How to Actually Build This: A Structural Guide

Start smaller than you think

You don't need the dashboard. You don't need trust-tiered write paths or a scheduled agent. You need one git repo and the discipline to write things down in it. Everything else in this series is what that turned into after months of actual use — not what you should build on day one.

Here's the actual minimum: a git repo, one instructions file, one folder for facts. That's it. If you set up nothing else from this piece, set up that.

01The maturity ladder

Five levels, each one a real precondition for the next, not a nice-to-have you can grab out of order:

• 0A markdown file you paste into every conversation. Works fine for a couple weeks. Stops working the moment you have more context than fits in a paste.
• 1A git repo, two tiers of instructions, one fact per file. Global behavioral rules separate from per-project conventions; durable facts separate from both. Part one is the full case for this layer.
• 2Derived state instead of hand-maintained state, and trust-tiered writes. A generated brief instead of a status doc you forget to update; a review gate that matches the risk of whatever surface is writing. Also part one.
• 3A view layer — dashboard, chat, whatever fits. Only once the substrate already works from a terminal alone. The view is a convenience layer, never the only place the data lives. Part two is the argument for building one, and for keeping it optional.
• 4Small, boring, unattended agents. One low-stakes job, PR-gated, nothing auto-merged. Only after the trust boundaries from level 1–2 have actually been tested, not just written down. Part three covers why the order matters.

Most of the value is in levels 0 through 2. Don't feel behind if you never get to 4 — plenty of real, working setups stop at 2 and are better for it.

02The actual starter files

Real content, not a description of content. Copy these, then cut what doesn't fit.

# Instructions

## Session Start
1. Read `context.md` — how to act (tone, when to ask before doing
   something, how to handle sensitive data).
2. Read `about-me.md` — who you're working with.
3. `git pull`.
4. Skim `projects/*/overview.md` frontmatter for status and next
   steps. Give a short brief: active projects, what changed last
   time, anything urgent. Don't wait to be asked for this.

## Session End
git add -A && git commit -m "session sync" && git push

## Memory Format
One fact, one file, in `memory/`. Frontmatter:
---
name: short-kebab-slug
type: user | feedback | project | reference
tags: [tag1, tag2]
---
The fact. For feedback/project entries, add **Why:** and
**How to apply:** lines so it's usable later, not just logged.

## What NOT to save here
Anything the repo or git history already records. This file is
for what isn't derivable — decisions, corrections, preferences —
not a second copy of the codebase.

---
status: active | paused | done
priority: low | medium | high
---

## Decisions
- 2026-08-10 — chose X over Y because Z. Only real decisions
  go here, not routine implementation detail.

## Next Up
- The specific next action. Not "continue working on X" —
  name the actual thing.

## Session Notes
- What happened, dated, most recent first.

That's the whole level-1 setup. No script required yet — "read the projects folder and summarize it" is a fine brief generator until it isn't. Only build the derived-state script from part one once hand-reading the folder actually gets slow.

03Mistakes worth skipping

Three real ones from this series, generalized so you don't have to hit them yourself:

Steal this, don't worship it

None of the specific choices here are sacred. Markdown and git are the right call because they're boring and legible, not because they're the only correct answer — if your team already lives in a wiki that a model can read and write to, that might genuinely beat a git repo for you. The two-tier instruction split, the frontmatter schema, the maturity ladder — all of it is a starting shape to bend, not a spec to match exactly.

What's worth keeping regardless of the specifics: derive what you can instead of hand-maintaining it, match review friction to actual risk instead of a blanket rule, and don't build the exciting part until the boring part has survived real use. That's the actual throughline of this whole series, level 0 through 4.