Protocol Handbook
Welcome in.
The operating layer your AI inherits — start with what you want to do.
Get started
Put a dotHuman on a project
Five minutes to scaffold your .human/ workspace — then a quick review makes it yours. The path:
- 1 Check you’re ready — prerequisites
- 2 Put a dotHuman on it — run dotHumanize
- 3 Do the review — confirm the facts, supply the why
- 4 Run your first goal — the Lifecycle
Start here
New? These three orient you.Introduction
An open protocol that gives an AI a durable place to inherit your method, survive context resets, and compound lessons over time.
Pain Points We Solve
The recurring pains of AI-assisted work — agents that forget, lessons that vanish, no record of why — and what a .human/ workspace gives you instead.
How dotHuman Works
How the protocol works — the .human/ structural floor and the lifecycle engine that compounds lessons over time.
Common use cases
…or jump straight to what you’re trying to do.Put a dotHuman on an existing codebase →
Run the seed — it reads what’s there and lays a floor that reflects it.
Start a brand-new project right →
Greenfield: it interviews you and seeds the floor from your intent.
Stop your agent from forgetting →
Give it a durable briefing it re-grounds from at the start of every session.
Hand off work mid-stream →
Leave Resume Notes so the next session picks up exactly where you stopped.
Capture a repeatable workflow →
Turn accumulated lessons into a Pseudo Skill the agent reaches for on its own.
Just understand it first →
The pains it fixes — and what a .human/ workspace gives you instead.
Working with dotHuman
The mental models, plus your first build.What's in a Name?
Two easy-to-mix-up names — .human the method vs dotHuman the brand (and .human/, the workspace it lives in).
Your First dotHuman
Put your first dotHuman on a project in the right order — the few key elements that matter to start.
The Lifecycle
The loop you run on every goal — Work a Goal → Review → Carry forward. Each pass more reliable than the last.
The Two Layers
The protocol splits into two stacked layers: the in-git Constitution and the off-git .human/ layer.
Core Pillars
The everyday core that keeps your workspace reliable, goal after goal.Comprehension
The standing briefing for a fresh agent plus reference and standard docs — the \"get un-lost\" pillar.
Context Reset Doc
The off-git, personally-scoped mirror of CLAUDE.md — it primes a fresh agent to behave like the last one and keeps personal preferences out of shared project config.
Goals
Dated, self-contained work folders — each a portable WIP packet you could hand to another human mid-stream.
Evergreen
Long-lived how-to guides (runbooks) that outlive any single goal.
Reports
Time-stamped operational records (incidents, alarms) — create-when-needed, never fabricated to fill the pillar.
Captain's Log
The append-only journal that ties everything together — the cross-goal spine.
Building Blocks
The moving parts — what you run, grow, spin up, and reach for as you work.Pseudo Skills
A loosely-bound, evolving how-to that does the job of a Claude Skill without the rigid binding.
dotHumanize
The one pseudoskill you actually run — it sets up a .human/ on any folder (new or existing) and refreshes it on re-runs, stating only what it can prove.
dotCoach
The practice coach — a loose pseudoskill that teaches the emergent practices by doing, dropping a couple of starter goals after your first review.
Sidequests
Related tasks that surface mid-goal — tracked and folded in without derailing the goal or spinning up a new one.
Resume Notes
A per-goal handoff (RESUME.md) that lets the next session pick up an in-flight goal where the last one stopped — days later, or in someone else's hands.
SpecKit
The convention the dotHuman constitution follows (.specify/memory/constitution.md).
spec → plan → tasks
The workflow for non-trivial work inside a dated Goals folder, checked against the constitution.
WIP Packet
A self-contained, portable unit of work-in-progress — i.e. a Goals folder you can hand off.