docs: Chunk 3 grill, PRD, ADRs, and doc updates

- docs/prd/chunk-3-skills-library.md: PRD for 42-skill library rebuild;
  AGENTS.md refactor as prerequisite; factory bootstrap order (write-eval
  first); source field schema; upstream review cadence; design phase
  sequence; IaC/Gitea scope decisions
- docs/adr/0011-provider-agnostic-issue-tracker.md: file-based default,
  Gitea as provider adapter, "issue" as canonical cross-provider term
- docs/adr/0012-agents-md-provider-agnostic-entry-point.md: AGENTS.md as
  content source, CLAUDE.md as thin adapter; partially supersedes ADR-0005
- CONTEXT.md: 8 new glossary terms (AGENTS.md, skill composition, source
  field, provider-agnostic issue tracker, design phase sequence, PRD scope,
  issue scope, bidirectional reference principle); CLAUDE.md index model
  updated; stale workflow example fixed
- docs/ROADMAP.md: changelog tooling and IaC/Gitea scope resolved; when:
  field question updated; Chunk 3 grill housekeeping note added
- docs/spec/overview.md: Chunk 3 target updated with PRD link, skill count,
  and AGENTS.md prerequisite

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

CONTEXT.md

@@ -11,7 +11,7 @@ description: Domain language and decisions for the global AI development config
 `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
-`providers/claude-code/CLAUDE.md` (source) is deployed to `~/.claude/CLAUDE.md` via `install.sh`. It has two tiers: (1) a short always-loaded section for universal rules that must apply every session — including communication style; (2) a content index of pointers to on-demand files in `~/.claude/core/` that the agent reads when needed. Context size is kept minimal.
+`AGENTS.md` is the source of always-on universal rules (provider-agnostic). `providers/claude-code/CLAUDE.md` is a thin adapter: it imports `AGENTS.md` via `@AGENTS.md` and appends Claude Code-specific additions (e.g. `@import` directives for on-demand files in `~/.claude/core/`). 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. (Pending implementation in Chunk 3 prerequisite issue — current deployed state still uses `providers/claude-code/CLAUDE.md` as the content source.)
 
 ### 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.
@@ -71,9 +71,9 @@ The set of machines and projects under management in Phase 2 of the Management A
 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 the always-on section of `providers/claude-code/CLAUDE.md`; (2) topic-specific rules (coding, git, testing) live in `core/instructions/<topic>.md` and are read on-demand.
+- **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 → to-prd → to-issues as a product design workflow.
+- **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)
@@ -100,6 +100,30 @@ Defined in full in `docs/ai-constitution.md` Section 3. Agent-actionable rules i
 ### 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 governance and instruction entry point. Lives at the repo root (project-level) and at `core/AGENTS.md` → deployed to `~/.agents/AGENTS.md` (global). Contains all always-on rules in plain markdown with no provider-specific syntax. Provider-specific files (`CLAUDE.md`) become thin adapters that import it. Claude Code reads `CLAUDE.md` natively (not `AGENTS.md` directly); `CLAUDE.md` imports `AGENTS.md` via `@AGENTS.md`. This pattern means a single source of truth can serve multiple providers without duplication.
+
+### 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 (that is issue scope). 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 (non-trivial issues 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.