chore: bootstrap repo with chunks 1 and 2

Establishes the global AI development config repo from scratch:

- Chunk 1: repo skeleton, install.sh, statusline, deploy manifest
- Chunk 2: core instructions (coding/git/testing), CLAUDE.md rewrite
  (always-on + content index two-tier model), docs restructure,
  6 ADRs, ROADMAP.md, .gitkeep placeholders
- Bootstrap skills in .claude/skills/ (to be catalogued and migrated
  to .agents/skills/ in Chunk 3)

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

docs/adr/0001-pull-distribution-model.md

@@ -0,0 +1,3 @@
+# Pull distribution model
+
+Projects pull config updates from this repo consciously rather than receiving automatic pushes. We chose pull because it keeps projects in control of when they take updates — a silent push could break a project mid-sprint with no warning. Pull also scales cleanly from solo homelab to open source: anyone can fork this repo and projects remain decoupled from the origin. The trade-off is that stale projects are invisible until they pull; push would make fleet drift detectable earlier, which is why fleet sync tooling (Phase 2) revisits this at the network layer, not at the file distribution layer.

docs/adr/0002-copy-not-symlink.md

@@ -0,0 +1,3 @@
+# Copy files, not symlinks or submodules
+
+Content is deployed by copying files, not symlinking or using git submodules. Symlinks break if this repo moves or is renamed; submodules require git tooling everywhere a project runs — including on machines where this repo may not be cloned at all. Copying means a deployed project works in complete isolation from this repo's location or existence. The cost is that updates are opt-in (consistent with ADR-0001) and no automatic change detection exists. This is intentional: silent changes are a worse failure mode than stale configs.

docs/adr/0003-provider-agnostic-core.md

@@ -0,0 +1,3 @@
+# Provider-agnostic core with thin adapters
+
+`core/` uses plain imperative markdown — no tool names, provider APIs, or format assumptions. Provider-specific translations live in `providers/<name>/`. The alternative was provider-specific content everywhere, which means adding a second provider (Copilot, Cursor) requires rewriting all content from scratch rather than writing a thin adapter. The cost is a translation layer: content must be kept abstract enough to survive adaptation, which sometimes means less tool-specific precision in the core. Where precision matters more than portability, it belongs in `providers/`, not `core/`.

docs/adr/0004-skills-in-agents-dir.md

@@ -0,0 +1,3 @@
+# Skills live in .agents/skills/, not .claude/skills/
+
+Skills (slash commands) are stored in `.agents/skills/` following the [Agent Skills open standard](https://agentskills.io), not in `.claude/skills/` which is a Claude Code-specific location. Claude Code, GitHub Copilot, Cursor, and other tools read `.agents/skills/` natively without an adapter. Putting skills in `.claude/skills/` would make them Claude Code-only and contradict ADR-0003 (provider-agnostic where possible). Skills are the strongest shared primitive across providers — they should live at the most portable location available.

docs/adr/0005-two-tier-claude-md.md

@@ -0,0 +1,3 @@
+# Two-tier CLAUDE.md: always-on rules + on-demand content index
+
+The deployed `~/.claude/CLAUDE.md` has two sections: (1) a short always-on section with universal rules loaded every session, and (2) a content index of pointers to on-demand files the agent reads when the task warrants it. The alternative — a single large file with all rules, workflows, and conventions — would load coding standards, git rules, and testing conventions into every session, including sessions that never touch code or run tests. Context is a scarce resource. Keeping the always-on section under 30 lines ensures it costs almost nothing; the agent pulls deeper content only when it's relevant.

docs/adr/0006-install-always-overwrites.md

@@ -0,0 +1,3 @@
+# install.sh always overwrites deployed files
+
+`install.sh` overwrites `~/.claude/` and `~/.claude/core/` unconditionally on every run. It does not merge, diff, or ask. The rationale: the source of truth is this repo. Editing deployed files directly is a usage error — `sync.sh` would overwrite those edits on the next pull anyway. Offering a merge path would imply that editing `~/.claude/CLAUDE.md` directly is a supported workflow, which it is not. If a local customisation is needed it belongs in a project-level override file, not in the deployed global config.