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>

docs/adr/0011-provider-agnostic-issue-tracker.md

@@ -0,0 +1,11 @@
+# Provider-agnostic issue tracker with file-based default and provider adapters
+
+Skills and workflows reference a "linked issue" generically rather than coupling to a specific issue tracker. In the file-based phase, an issue is a `docs/issues/NNNN-<slug>.md` file. When a provider MCP (e.g. Gitea MCP) is configured, skills detect it at runtime and use it instead. The active backend is determined by MCP availability — no config flag required. "Issue" is the canonical cross-provider term; GitHub, GitLab, and Gitea all use it natively.
+
+Gitea-specific skills (`setup-gitea-mcp`, `post-pr-review`, `create-issue`) are a provider adapter at `providers/gitea/` — structurally identical to how `providers/claude-code/` adapts core content for Claude Code. They are not part of the core skill library.
+
+Two alternatives were rejected. Gitea-specific skills in the core library would block use before Gitea is configured and embed a provider assumption into skills that are otherwise provider-neutral. Per-provider skill variants (e.g. `implement-feature` + `implement-feature-gitea`) create maintenance overhead with no functional gain — the only difference is the issue lookup mechanism, not the skill logic.
+
+The file-based default was chosen because this repo must work before Gitea is set up. File-based issues are already the working convention (`docs/issues/`), established in Chunk 1. Gitea is the first concrete provider and will be configured after Chunk 3; existing file-based issues will be migrated at that point.
+
+This decision makes the skills library usable on any machine without external service dependencies, while keeping Gitea integration as a first-class path once available. The provider adapter pattern (`providers/gitea/`) is consistent with ADR-0007 (provider adapters as symlinks) and ADR-0008 (factory boundary).

docs/adr/0012-agents-md-provider-agnostic-entry-point.md

@@ -0,0 +1,11 @@
+# AGENTS.md as provider-agnostic governance entry point; CLAUDE.md as thin adapter
+
+`AGENTS.md` is the single source of truth for always-on agent instructions. It lives at the repo root (project-level) and at `core/AGENTS.md` deployed to `~/.agents/AGENTS.md` (global). It contains all universal rules in plain markdown with no provider-specific syntax. Provider-specific files (`CLAUDE.md`) become thin adapters that import it — the repo-level `CLAUDE.md` contains `@AGENTS.md` plus any Claude Code-specific additions; the global `~/.claude/CLAUDE.md` imports `~/.agents/AGENTS.md` similarly.
+
+Claude Code reads `CLAUDE.md` natively, not `AGENTS.md`. The Anthropic documentation explicitly recommends the import pattern for repos that use `AGENTS.md` for other tools: `CLAUDE.md` contains `@AGENTS.md` and appends Claude Code-specific content below. This means `CLAUDE.md` continues to exist as the Claude Code entry point but carries no original content — it is purely an adapter.
+
+`AGENTS.md` must be self-contained: no `@import` syntax (which is Claude Code-specific and would make the file provider-specific). On-demand instruction loading via `@import` stays in the Claude Code adapter (`CLAUDE.md`), pointing to `core/instructions/` as today. The `core/` deployment path (`~/.claude/core/`) is unchanged in this chunk; migration to `~/.agents/` is deferred to Chunk 7 when a second provider (Copilot) provides evidence of what that provider needs.
+
+This partially supersedes ADR-0005 (two-tier CLAUDE.md model). ADR-0005 established the always-on / on-demand split and remains correct as a structural pattern. What changes is where the always-on content lives: previously in `providers/claude-code/CLAUDE.md`, now in `AGENTS.md`. The adapter layer ADR-0005 described still exists; `CLAUDE.md` is now the adapter rather than the source.
+
+The alternative — keeping always-on content in `providers/claude-code/CLAUDE.md` — was rejected because it violates ADR-0003 (provider-agnostic core). Content that applies to all agents regardless of provider has no business living in a provider-specific file. When Copilot arrives in Chunk 7, duplicating that content into a Copilot adapter or maintaining two sources of the same rules is exactly the drift ADR-0003 was written to prevent.