holocron/CONTEXT.md

---
name: AI Development Repo
description: Domain language and decisions for the global AI development config repository
---

# Context

## Principles

### Provider-agnostic core
`core/` content uses plain imperative language — no tool names, provider APIs, or format assumptions. Anything referencing a specific tool belongs in `providers/`, not `core/`. Providers translate core content into the tool's expected format and language.

### CLAUDE.md index model
`AGENTS.md` is the source of always-on universal rules (provider-agnostic). `providers/claude-code/CLAUDE.md` is a thin adapter: it imports `~/.agents/AGENTS.md` via `@~/.agents/AGENTS.md` and appends Claude Code-specific additions (`@import` for governance.md, content index). Deployed to `~/.claude/CLAUDE.md` via `install.sh`. Context size is kept minimal — only what is needed every session is loaded upfront; detailed content is pulled on demand. See ADR-0012.

### Instruction file format
`core/instructions/<topic>.md` files are plain markdown — no frontmatter, no schema. The agent decides when to read each file based on task context and the content index label in `providers/claude-code/CLAUDE.md`. Frontmatter is deferred until there is evidence that agents are loading the wrong files in practice.

### Docs convention
Workflow artifacts are committed to `docs/` in subdirectories by type. All are tracked as issues.

**Naming:**
- `docs/prd/<slug>.md` — Product Requirements Documents
- `docs/ard/<slug>.md` — Architecture Requirements Documents
- `docs/bug/<slug>.md` — Bug Briefs
- `docs/notes/<slug>.md` — Exploration Notes
- `docs/adr/NNNN-<slug>.md` — Architecture Decision Records
- `docs/issues/NNNN-<slug>.md` — Issues
- `docs/spec/<slug>.md` — Living spec files (current deployed state); updated in the same PR as any behavior change

**NNNN** — zero-padded 4-digit sequential number (e.g. `0001`, `0042`). Used only for artifact types referenced by number (issues, ADRs). PRDs, ARDs, Bug Briefs, and Notes are referenced by topic and use a descriptive slug only.

**Other repo-level artifacts:**
- `LESSONS.md` — long-loop feedback log; patterns observed during development. Three or more entries on the same pattern graduate to the relevant standing file. Updated by the session-handoff skill or by the human directly.

**Slug** — kebab-case, lowercase, max 4–5 words, derived from the document title. No dates (git history carries dates). Examples: `chunk-2-instructions`, `user-auth-flow`, `database-migration`.

**When each is written:** PRDs, ARDs, Bug Briefs, and Notes are pre-work — produced by a grill session before issues are created. ADRs are post-decision — written during or after implementation of an ARD when a hard-to-reverse choice is made. An improvement kick-off produces either a PRD (user-facing scope) or ARD (architectural scope).

### Content chunk QA
Instruction files and other content chunks cannot be unit tested. Verification is human-executed after implementation: open a new Claude session, exercise the relevant behaviour, and confirm the rules take effect. Each issue includes a short acceptance criteria checklist for the human to run post-commit. Automated QA applies to tooling (scripts, hooks); manual QA applies to agent behaviour and content correctness.

**Instruction quality matters more than instruction presence.** In-context rules (including always-on CLAUDE.md rules) compete with the model's RLHF-trained defaults and can lose — even in a fresh session with the files correctly deployed. Flat one-liner imperatives are the weakest form. Rules that are specific, include a counter-example ("do X, not Y"), or show the boundary condition are significantly more reliable. When a behavioral test fails, the first question is whether the rule is underspecified, not whether in-context instruction-following is inherently unreliable. Do not accept rule violations as an expected baseline — treat them as a signal to strengthen the instruction.

### Conventional commits
All commits in this repo follow the Conventional Commits specification (`feat:`, `fix:`, `docs:`, `chore:`, `refactor:`, `test:`). Convention is defined in `core/instructions/git.md`. Changelog tooling is a follow-on issue — convention is established first.

### Project override model
Projects override on-demand content (workflows, agent roles, prompts) by placing their own versions in `.claude/`. Universal rules are additive — projects extend them, not replace them. A rule that needs per-project suppression is not truly universal.

### Sync model
Projects must never edit synced files directly — customizations live in separate override files. A sync conflict is a signal that a synced file was edited directly.

### Repo as source of truth
All project state, decisions, context, and working conventions live in this repo. External memory systems should not be used for this project — they create a split-brain risk where cached state diverges from the repo. At the start of every session, read `CLAUDE.md`, `CONTEXT.md`, `docs/VISION.md`, and `docs/spec/overview.md`. Everything needed to orient is here.

Before answering any design or architecture question, check for existing decisions: `docs/adr/` (hard architectural decisions) and the resolved rows (marked ✅) in the `docs/ROADMAP.md` open questions table. Never propose an approach without verifying no decision already covers it.

### Working context
This repo is built by a junior developer as a homelab tool intended to scale to professional environments. The agent should challenge ideas and reference industry standards rather than validate assumptions. Explain the why behind decisions — assume the user is learning, not just executing. Flag significant actions before taking them.

## Glossary

### Management Application
A separate product (separate repo) for browsing, editing, and configuring AI development configs through a proper product UI. Git is the persistence layer, invisible to the user. The app is repo-agnostic — it works with any git repo that follows these conventions. This repo is the canonical default content (the official starter). See `docs/VISION.md` for the phased roadmap.

### Fleet
The set of machines and projects under management in Phase 2 of the Management Application. A fleet member is any machine that has the config deployed and can be reached by the runtime orchestration layer.

### Skills
Reusable slash commands for AI coding tools, defined as `SKILL.md` files following the [Agent Skills open standard](https://agentskills.io). Canonical location: `.agents/skills/<skill-name>/SKILL.md` in this repo; deployed to `~/.agents/skills/` on install. Providers that don't read `~/.agents/skills/` natively get a symlink adapter declared in `providers/<name>/provider-manifest.sh` (e.g. Claude Code: `~/.claude/skills/ → ~/.agents/skills/`).

### Content types
- **Instructions** — stateless rules defining AI behavior. Split into two tiers: (1) universal rules (communication, behavior) live in `AGENTS.md` (provider-agnostic), loaded into every session via the provider adapter (`CLAUDE.md` imports `AGENTS.md`); (2) topic-specific rules (coding, git, testing) live in `core/instructions/<topic>.md` and are read on-demand via `@import` in the Claude Code adapter.
- **Agents** — role definitions activated on-demand for a specific task.
- **Workflows** — compositions of skills chained into a larger task. Invokable by agents or humans. Example: `grill-me` → `write-prd` → `break-into-issues` as the canonical design workflow.
- **Prompts** — shared fragments (system prompt sections, output formats) embedded into multiple skills or workflows.

### HITL (human-in-the-loop)
Agent pauses before a consequential action; human approves before execution. Required for irreversible or high-stakes actions (architecture changes, production deployments, security configuration). The agent drafts the change plan and waits — it does not proceed autonomously. Contrast with HOTL.

### HOTL (human-on-the-loop)
Agent acts; human monitors and can intervene after the fact. Acceptable for low-stakes, bounded, reversible actions where the cost of pausing for approval exceeds the blast radius of an error. The distinction between HITL and HOTL must be explicit and documented — defaulting to HOTL for convenience is not acceptable.

### Symbolic oversight
Oversight implemented as a gesture (assigning a reviewer) rather than a functional safeguard. A reviewer without the information, time, agency, or intent to evaluate is not oversight — it is the appearance of oversight. The documented failure mode: symbolic oversight passes audits but does not catch errors. Genuine oversight requires: the reviewer has access to what was produced, time to evaluate it meaningfully, authority to reject it, and the intent to do so.

### Data classification tiers
The four-tier framework governing what data may enter AI context. Apply the tier of the most sensitive element in any dataset or prompt.

| Tier | Examples | AI Rule |
|---|---|---|
| **Public** | Publicly available info | No restrictions |
| **Internal** | Operational data, anonymised logs | Enterprise AI tools only; not consumer/free-tier |
| **Confidential** | Source code, architecture, personal data, IP | Enterprise AI + contractual data-not-trained guarantee |
| **Restricted** | GDPR Article 9 health/biometrics, credentials, regulated financial data | Never enters AI context — hard architectural prohibition |

Defined in full in `docs/ai-constitution.md` Section 3. Agent-actionable rules in `core/instructions/governance.md`.

### Sycophancy
The failure mode where RLHF-trained models prioritise approval over accuracy. Treated as a first-class reliability risk: models change correct answers to wrong ones under user pressure in a majority of observed cases, then persist in the wrong answer. Designing against sycophancy is an explicit obligation, not a quality-of-life concern. Countermeasures: explicit pushback resistance instructions, prompting for dissent, cross-validating against independent sources. Never interpret AI agreement as AI accuracy.

### AGENTS.md
The provider-agnostic always-on instruction entry point. Two files:
- **Repo-level `AGENTS.md`** — instructions for agents working inside this repo (structure, key rules, chunk workflow); imported by repo `CLAUDE.md` via `@AGENTS.md`.
- **Global `core/AGENTS.md`** — Communication and Behavior rules that apply across all projects; deployed to `~/.agents/AGENTS.md`; imported by `~/.claude/CLAUDE.md` via `@~/.agents/AGENTS.md`.

Contains always-on rules in plain markdown with no provider-specific syntax (no `@import`). Provider-specific files (`CLAUDE.md`) are thin adapters that import the relevant `AGENTS.md` and add only Claude Code-specific syntax. This pattern means a single source of truth can serve multiple providers without duplication. See ADR-0012.

### Skill composition
A skill calling another skill by name to delegate a sub-task. The calling skill focuses on the orchestration decision ("when to do X"); the called skill owns the mechanics ("how to do X"). Established compositions: `grill-me` calls `write-adr` when a decision crystallises; `implement-feature` calls `tdd` as its implementation methodology. Composition chains are formalised as workflows in Chunk 4.

### Source field
Frontmatter field (`source:`) on skill files tracking upstream provenance. An array — supports multiple upstream sources per skill. Each entry: `repo` (GitHub slug, e.g. `mattpocock/skills` — no URL, slug is stable and searchable), `commit` (exact SHA reviewed at adoption), `files` (list of files adopted with inline comments on what was taken), `updated` (date of last upstream review for this entry). Absence of `source:` means self-authored original. Upstream review cadence: start of each chunk during roadmap; quarterly after roadmap completion (post Chunk 7).

### Provider-agnostic issue tracker
Skills and workflows reference "linked issue" generically rather than a specific provider. In the file-based phase, an issue is a `docs/issues/NNNN-<slug>.md` file. When Gitea MCP is configured, the same skills use it instead. The active backend is determined at runtime by MCP availability. "Issue" is the canonical cross-provider term (GitHub, GitLab, Gitea all use it). Gitea-specific skills are a provider adapter (`providers/gitea/`), not part of the core library. See ADR-0011.

### Design phase sequence
The canonical pre-implementation sequence within any workstream: `grill-lean` (optional lightweight interrogation, no docs) → `grill-me` (primary: deep interrogation + domain alignment + ADR writing) → `write-prd` (why + what only, never how) → `architecture-review` (optional: technical approach evaluation, ≥2 options) → `break-into-issues` (independently shippable slices; proposes Gitea milestone groupings for PRDs producing >5 issues).

### PRD scope
A PRD contains: problem statement, goals, explicit non-goals, functional requirements at feature level, success criteria. Never contains: technical approach, implementation steps, or EARS-level detail. HOW is handled downstream: workstream-level technical approach belongs in `architecture-review` (≥2 options, tradeoffs, optional step after `write-prd`); issue-level HOW belongs in issue design notes. Prerequisite: a completed grill session. Validated by inline self-checks in the `write-prd` skill.

### Issue scope
An issue contains: link to parent PRD (inherited why) + one-line context for this slice, EARS-format acceptance criteria, brownfield delta markers (ADDED/MODIFIED/REMOVED), design notes for non-trivial issues (the issue-level HOW — implementation specifics scoped to this slice only), independently completable task checklist. Prerequisite: parent PRD linked, or explicit standalone justification. No issue may block another open issue. Validated by inline self-checks in `write-issue-spec` and `break-into-issues`.

### Bidirectional reference principle
Files that reference other files should declare those references explicitly. The referencing file carries the forward reference (e.g. content index in `CLAUDE.md`, `references:` in frontmatter). The referenced file carries a `when:` field describing when it is loaded. Both sides should agree — divergence signals staleness. The reverse map ("what files reference this file?") is derived by a reference scanner script (Chunk 6 tooling), not maintained manually. This principle applies to instruction files, skills, and workflow documents.

### Workstream
A focused work session oriented around a single goal — a feature, bug, improvement, or exploration. Starts with a grill to produce an artifact (PRD, Bug Brief, ADR, etc.), runs through issue implementation, and closes with docs + commit. Ongoing skills (/diagnose, /prototype, /zoom-out) are invoked ad hoc within a workstream as needed.

### Workflow artifacts
Output documents produced by a grill session that scope the work before implementation. All are committed to the repo under `docs/` following the docs convention. Each artifact generates one or more issues in `docs/issues/` but is not itself an issue.

Pre-work (grill output):
- **PRD** (Product Requirements Document) — for features and improvements with user-facing scope
- **ARD** (Architecture Requirements Document) — for architectural changes; defines what needs to change and why, analogous to a PRD but for architecture. Produced before implementation; not the same as an ADR.
- **Bug Brief** — for bugs; feeds into /diagnose
- **Exploration Note** — for ideation; may or may not produce issues

Post-decision:
- **ADR** (Architecture Decision Record) — records the decision made, alternatives considered, and rationale. Written during or after implementation of an ARD, not before. Hard-to-reverse decisions only.