The working system behind every project on this site
T00 is a personal AI-collaboration framework I built for working with Claude Code on a daily basis, across many projects at once.
These describe the general mechanism, not this site's private working files — each one is a reusable idea you could adopt in your own AI workflow.
A convention for keeping AI collaboration organized: substantive answers get written into a persistent reply log rather than only spoken in the terminal, while the terminal itself stays terse — short confirmations only. That way a session spanning hours or days can be picked back up without re-reading a wall of scrollback.
Why it matters for T00: it's the backbone that keeps long, multi-project sessions traceable instead of scattered across chat history.
Read the full guide →A high / medium / low tagging convention that tells an AI assistant how freely it can change something. High-trust areas need a heads-up before changes; low-trust areas can be edited boldly; untagged code defaults to a sensible middle ground.
Why it matters for T00: it stops an eager AI from silently rewriting something that was deliberately built a certain way.
Read the full guide →The idea of giving an AI assistant a small, durable memory file — preferences, conventions, recurring feedback — that carries forward between separate conversations, so context doesn't need to be re-explained from scratch every time.
Deliberately minimal: not a full transcript, just the handful of durable facts worth remembering.
Read the full guide →Packaging a repeatable multi-step workflow — like "estimate this task" or "publish this build" — into a single reusable command instead of re-typing the same instructions every time.
Turns a recurring multi-paragraph instruction into a one-word trigger, keeping repetitive workflows consistent.
Read the full guide →A way of packaging specialized instructions so an AI assistant only loads them when actually relevant, instead of every conversation carrying the full weight of every capability it might ever need.
Keeps day-to-day interactions lighter while still making deep, specialized knowledge available the moment it's needed.
Read the full guide →Before answering, restate an incoming message as a numbered list of distinct points, each tagged to which part of the original it came from — so a request that mixes several asks together doesn't quietly lose one of them.
Also a two-way habit: separating distinct asks on the way in (numbered points, one thought per line) makes them far less likely to get lost on the way out.
Read the full guide →An append-only log of decisions that involved a real tradeoff — approaches tried and rejected, constraints the code alone doesn't reveal — so the same mistake doesn't get "cleaned up" back into existence later.
Only for genuine tradeoffs, not routine work — a design doc that restates every line of code stops being useful.
Read the full guide →When part of a task genuinely can't be done properly, say so upfront — flag it clearly, spell out exactly what's missing — instead of shipping something that looks finished but doesn't actually work or has a security gap.
An honest "this part isn't real yet" is worth more than a dishonest "this looks like it works."
Read the full guide →