2. Repository shape (core only)
familiar-workspace/ is the whole product. It is one self-contained folder that you download and
use, with no install step and no build step. It ships complete: the content folders, each agent’s
own skill and subagent files, and the rules, all in place.
familiar-workspace/├── AGENTS.md / CLAUDE.md / GEMINI.md agent entry files (CLAUDE.md, GEMINI.md reference AGENTS.md);│ release text sits inside <!-- familiar:start/end -->, user notes below├── .familiar/│ ├── routes.md, state-schema.md, extension-contract.md,│ │ capabilities.json, extension-manifest.schema.json protocol│ ├── core/ 20 protocol .md files, including bootstrap.md│ ├── scripts/ standard-library helpers: project_check.py, doctor.py, ...│ ├── installed.json core version, capability states for each agent│ └── release-manifests/ built releases only: fingerprints of release-owned files├── .claude/skills/ 8 skills, one folder each; .claude/agents/ holds the subagents├── .agents/skills/ Codex and Gemini skills, identical to .claude/skills/├── .codex/agents/, .gemini/agents/ subagents for Codex and Gemini├── 1-Inputs/ Sources/, Admin/, Templates/ (read-only)├── 2-Drafts/ generated outputs plus _draft-index.md├── 3-Knowledge/ knowledge pages built from 1-Inputs/├── 4-Trackers/ tasks.md, timeline.md, meetings.md└── 5-System/ config, context, Memory/, Decisions/, Handoffs/, preferences.familiar-project is already in the folder, with created: not-yet-set. Every download is
therefore a bound project as soon as you rename it and open it. The first project-status →
Check-in writes the real date into created (§4.1, §12). Check-in replaces project-config.md only
while that file is still the shipped stub (revision: 0). A project with a filled-in configuration
and an unset marker is a migrated project. Check-in brings that configuration up to date in place
and never resets it to defaults.