docs: sync website, book, and blog with engine-only graph + 33-command surface

Bring every documentation surface up to date with the post-3.0.0 state
(/draft:index removed, OKF removed, engine-only graph). The engine-fetch
and tooling changes already landed in 1f09de0; this commit covers the
remaining documentation/website drift.

Website:
- index.html, what-is-draft, llms.txt/llms-full.txt, feed.xml, podcast.xml:
  command count 34->33, specialists 25->24, shell tools 34->32; drop OKF copy;
  remove /draft:index (card, FAQ, tables); version labels v2.8->v3.0; install
  leads with `npx @drafthq/draft install <host>`; de-dup command grid
  (+graph, +upload). Regenerated topic pages + sitemap via build-book.sh.
- llms-full.txt: graph section rewritten to engine-only (schema.yaml only).

Book (chapters + notebook sources):
- Rewrite ch.18 monorepo-federation to scope-aware /draft:init + root-link.json.
- Fill ch.22 command-reference and ch.23 file-reference stubs.
- architecture.md "25-section"->"10-section"; appendix table lists all 33 skills.

Blog:
- Rewrite local-graph-engine to engine-only (live query, nothing committed).
- Fix hotspots.jsonl / architecture.json references in 3 more posts.

Root:
- README: drop /draft:index row. CONTRIBUTING: SKILL_ORDER lives in lib.sh.
- Add docs/audit/DOC_DRIFT_AUDIT.md drift tracker.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Author: mayurpise

CONTRIBUTING.md

@@ -84,7 +84,7 @@ Execution instructions...
 ```
 
 2. The body **must** start with `# Title` followed by a blank line (build script skips first 3 body lines via `tail -n +4`)
-3. Add the skill name to `SKILL_ORDER` array and add header/trigger case entries in `scripts/build-integrations.sh`
+3. Add the skill name to the `SKILL_ORDER` array in `scripts/lib.sh`, then add a case entry in `get_skill_header()` AND `get_copilot_trigger()` in `scripts/build-integrations.sh`
 4. Run `make build && make test`
 5. Add the command to `README.md`
 6. Add a test if the skill has validatable behavior

README.md

@@ -129,7 +129,7 @@ curl -o .gemini.md https://raw.githubusercontent.com/drafthq/draft/main/integrat
 | **`/draft:docs`** | Router for authoring and documentation workflows |
 | **`/draft:discover`** | Router for discovery, debugging, investigation, and quality |
 | **`/draft:init`** | Analyze codebase, create context files + state tracking |
-| **`/draft:index`** | Aggregate monorepo service contexts |
+| **`/draft:graph`** | Build / refresh the knowledge-graph snapshot |
 | **`/draft:new-track`** | Collaborative spec + plan with AI |
 | **`/draft:decompose`** | Module decomposition with dependency mapping |
 | **`/draft:implement`** | TDD workflow with checkpoints |
@@ -234,7 +234,7 @@ AI tools are fast but unstructured. Draft applies Context-Driven Development to
 ```
 product.md       →  "Build a task manager"
 tech-stack.md    →  "React, TypeScript, Tailwind"
-architecture.md  →  Comprehensive: 28 sections + 5 appendices, Mermaid diagrams (source of truth). Mature brownfield projects with strong existing agent docs (CLAUDE.md, INVARIANTS.md, etc.) receive early Context Quality Audit, graph fidelity dashboard, and explicit Relationship + Gaps sections (no blind duplication).
+architecture.md  →  Comprehensive: 10-section graph-primary engineering reference, Mermaid diagrams (source of truth). Mature brownfield projects with strong existing agent docs (CLAUDE.md, INVARIANTS.md, etc.) receive early Context Quality Audit, graph fidelity dashboard, and explicit Relationship + Gaps sections (no blind duplication).
 .ai-context.md   →  200-400 lines: condensed from architecture.md (token-optimized AI context)
 .state/          →  freshness hashes, signal classification, run memory (incremental refresh)
 spec.md          →  "Add drag-and-drop reordering"

book/notebook-sources/00_what_is_draft.md

@@ -8,7 +8,7 @@ You installed an AI coding assistant. It writes code fast. But it also picks the
 
 ## What Draft Is
 
-Draft is a free, open-source plugin that adds structured development methodology to AI coding agents. It provides 28 slash commands and 7 specialized agents that turn your AI assistant from an autonomous guessing machine into a disciplined executor of pre-approved work.
+Draft is a free, open-source plugin that adds structured development methodology to AI coding agents. It provides 33 slash commands and 7 specialized agents that turn your AI assistant from an autonomous guessing machine into a disciplined executor of pre-approved work.
 
 The core idea: before AI writes a single line of code, it analyzes your codebase, generates a specification, builds a phased plan, and waits for your approval. Only then does implementation begin — constrained by your architecture, your conventions, and your acceptance criteria.
 
@@ -26,7 +26,7 @@ Draft is for developers and teams who use AI coding assistants and have experien
 
 ## What You Get
 
-4 primary workflow commands (`/draft:init`, `/draft:new-track`, `/draft:implement`, `/draft:review`) plus 5 routers (`/draft:plan`, `/draft:ops`, `/draft:docs`, `/draft:discover`, `/draft:jira`) as the recommended public interface. 22 specialist commands are dispatched by the routers for targeted work (debug, bughunt, deep-review, tech-debt, ADR, etc.).
+4 primary workflow commands (`/draft:init`, `/draft:new-track`, `/draft:implement`, `/draft:review`) plus 5 routers (`/draft:plan`, `/draft:ops`, `/draft:docs`, `/draft:discover`, `/draft:jira`) as the recommended public interface. 24 specialist commands are dispatched by the routers for targeted work (debug, bughunt, deep-review, tech-debt, ADR, etc.).
 
 The router model reduces cognitive load: state your intent to a router and it dispatches to the right specialist with context.
 
@@ -36,7 +36,7 @@ The router model reduces cognitive load: state your intent to a router and it di
 
 Draft works with the AI coding tools you already use:
 
-* Claude Code— Native plugin installation via/plugin install
+* Claude Code— Native plugin installation via`npx @drafthq/draft install claude-code`
 * Cursor— Native support for the.claude/plugin structure
 * GitHub Copilot— Via.github/copilot-instructions.md
 * Gemini— Via.gemini.mdbootstrap file

book/notebook-sources/02_context_driven_development.md

@@ -32,7 +32,7 @@ What it locks in:technology choices, dependency constraints, accepted patterns.
 
 ### architecture.md — How (Structure)
 
-The source of truth. A comprehensive 25-section engineering reference generated from exhaustive codebase analysis. It includes module boundaries, dependency graphs, data flows, API definitions, concurrency models, security architecture, and testing infrastructure — all with real Mermaid diagrams and actual code snippets from your codebase.
+The source of truth. A comprehensive 10-section engineering reference generated from exhaustive codebase analysis. It includes module boundaries, dependency graphs, data flows, API definitions, concurrency models, security architecture, and testing infrastructure — all with real Mermaid diagrams and actual code snippets from your codebase.
 
 What it locks in:module boundaries, interaction contracts, data flow patterns, invariants. The AI cannot violate your architecture because the architecture is explicitly documented with every component, every interface, and every constraint.
 
@@ -68,7 +68,7 @@ This is where the AI gets enough context to make correct decisions without the f
 
 ### Tier 2: Long-Term Storage
 
-architecture.mdis the full, comprehensive reference — 25 sections plus appendices, with Mermaid diagrams and code snippets. It is loaded for deep reviews, architecture refreshes, and complex analysis tasks. Most day-to-day development never touches this tier directly.
+architecture.mdis the full, comprehensive reference — 10 sections with Mermaid diagrams and code snippets. It is loaded for deep reviews, architecture refreshes, and complex analysis tasks. Most day-to-day development never touches this tier directly.
 
 Smaller context windows produce better AI decisions. By loading only what's needed, Draft reduces token consumption, decreases hallucination risk, and keeps the AI focused on the relevant subset of your architecture. The right context for the task — not all the context, all the time.
 

book/notebook-sources/03_getting_started.md

@@ -12,7 +12,7 @@ Draft installs with a single command. No API keys, no accounts, no hosted servic
 
 ### Claude Code (Recommended)
 
-That's it. You now have all 28 commands available as/draft:*slash commands.
+That's it. You now have all 33 commands available as/draft:*slash commands.
 
 ### Cursor
 
@@ -85,7 +85,7 @@ After the five-phase analysis, Draft creates thedraft/directory with these files
 
 ### architecture.md (Source of Truth)
 
-A comprehensive 25-section engineering reference with appendices. This is the primary artifact — designed for both human engineers and AI agents. It includes:
+A comprehensive 10-section engineering reference. This is the primary artifact — designed for both human engineers and AI agents. It includes:
 
 * Executive summary and system identity
 * Component map and module documentation

book/notebook-sources/10_context_tiering.md

@@ -34,7 +34,7 @@ This file isderivedfromarchitecture.md, not written directly. Draft's condensati
 
 ## Tier 2: The Full Architecture
 
-The filedraft/architecture.mdis the source of truth. It is a comprehensive, human-readable engineering reference with 25 sections and 4 appendices, complete with Mermaid diagrams, code snippets, interaction matrices, and state machine definitions. It exists for two audiences: AI agents performing deep analysis, and engineers who need to understand a module without reading source code.
+The filedraft/architecture.mdis the source of truth. It is a comprehensive, human-readable 10-section engineering reference, complete with Mermaid diagrams, code snippets, interaction matrices, and state machine definitions. It exists for two audiences: AI agents performing deep analysis, and engineers who need to understand a module without reading source code.
 
 Tier 2 is loaded only for deep analysis:/draft:initrefresh,/draft:deep-review,/draft:decompose, and full architecture refreshes. Most day-to-day development never touches it. When it is loaded, it provides exhaustive context that Tier 1 intentionally omits: per-module state machines, thread safety annotations, the full implementation catalog, concurrency model details, and configuration reference tables.
 
@@ -76,7 +76,7 @@ Evening: you run/draft:deep-reviewon the auth module after a security concern. D
 
 ## Why Not Just Load Everything?
 
-Token budgets are finite. A 400-line.ai-context.mdplus a 2000-linearchitecture.mdplus 150 facts consumes significant context window space — space that competes with the actual code being analyzed, the spec being checked, and the plan being followed. Tiering is not an optimization. It is a necessity. Without it, large projects would hit context limits before the AI could even begin working.
+Token budgets are finite. A 400-line.ai-context.mdplus a comprehensive 10-sectionarchitecture.mdplus 150 facts consumes significant context window space — space that competes with the actual code being analyzed, the spec being checked, and the plan being followed. Tiering is not an optimization. It is a necessity. Without it, large projects would hit context limits before the AI could even begin working.
 
 The three-tier system also reflects a truth about information relevance: most of your project's architectural knowledge is irrelevant to any single task. Loading it anyway does not make the AI smarter. It makes it noisier. Focused context produces focused output.
 

book/notebook-sources/18_monorepo_federation.md

@@ -4,69 +4,59 @@ Part VI: Enterprise· Chapter 18
 
 4 min read
 
-A monorepo with twelve services has twelvedraft/directories after initialization. Each service has its own architecture documentation, its own tech stack, its own context files. But nobody has a unified view of the whole system — which services depend on which, what technologies are used where, or how the pieces fit together./draft:indexbuilds that view.
+Draft has no separate index command. Monorepo support is built directly into `/draft:init`, which is scope-aware and root-first. Run it at the repo root to build the whole-repo knowledge graph; run it inside a sub-module and it resolves the repo root automatically, builds that module's snapshot, and writes `draft/graph/root-link.json` pointing up to the root graph — so every module has full cross-module understanding without an extra step. Federation is the root-link mechanism, not a separate command.
 
 ## The Monorepo Context Problem
 
-Running/draft:initon each service in a monorepo produces excellent per-service context. The auth service has a detailed.ai-context.mdexplaining its JWT validation flow. The billing service documents its Stripe integration. But cross-service questions remain unanswered: what happens when auth goes down? Which services share PostgreSQL? Is anyone still using the deprecated notification API?
+A monorepo with twelve services raises a cross-module question that per-service context cannot answer: what happens when the auth service changes? Which services share PostgreSQL? Which team owns the notification API? Per-service `/draft:init` runs produce excellent local context — detailed `.ai-context.md` files for each service — but answering cross-service questions requires connecting those views.
 
-/draft:indexanswers these questions by aggregating service-level context into root-level knowledge files, without deep code analysis. It reads what/draft:initalready produced and synthesizes a system-of-systems view.
+Draft solves this through the root-link mechanism built into `/draft:init`. There is no separate aggregation step. Running `/draft:init` anywhere in the monorepo is enough.
 
-## Auto-Detection
+## How Scope-Aware Init Works
 
-Draft detects services by scanning immediate child directories (depth=1 only, never recursive) for standard project markers:
+`/draft:init` is root-first. When invoked at the repo root, it builds the whole-repo knowledge graph in `draft/graph/`. When invoked inside a sub-module (for example, `services/billing/`), it:
 
-* package.json— Node.js services
-* go.mod— Go services
-* Cargo.toml— Rust services
-* pom.xml/build.gradle— Java services
-* pyproject.toml/requirements.txt— Python services
-* Dockerfile— Containerized services
-* src/directory with code files
-It excludesnode_modules/,vendor/,.git/, and hidden directories. Each detected directory is categorized as initialized (has adraft/subdirectory) or uninitialized. Only initialized services contribute to the index.
+1. **Resolves the repo root** — walks ancestor directories looking for an existing `draft/` directory, then falls back to `git rev-parse --show-toplevel`, then falls back to cwd.
+2. **Builds the module snapshot** — runs full analysis for the sub-module and writes its graph under the module's own `draft/graph/`.
+3. **Writes `draft/graph/root-link.json`** — a pointer from the module's graph to the root graph. This file tells any Draft command running inside the module where the whole-repo graph lives.
 
-## What Gets Generated
+The result: a Draft command running inside `services/billing/` can answer cross-module questions by following the root link to the root graph, without re-running any analysis at the root level.
 
-/draft:indexproduces six root-level files that together form a complete system map:
+## The root-link.json File
 
-### service-index.md
+`draft/graph/root-link.json` is a small JSON file written by `/draft:init` when it detects it is running inside a sub-module. It contains the absolute path to the root `draft/graph/` directory and metadata about when the link was established. Commands that need cross-module context read this file and query the root graph directly.
 
-A directory of all detected services with their status, tech stack, dependencies, team ownership, and links to their individual context files. This is the entry point — the table of contents for the entire monorepo.
+If no root graph exists yet, the root link points to a pending state and falls back gracefully to module-local context. Running `/draft:init` at the repo root later fills the gap — no re-initialization of sub-modules required.
 
-### dependency-graph.md
+## The Committed Graph: Only schema.yaml
 
-Cross-service dependency mapping with a Mermaid topology diagram, a dependency matrix (depends-on and depended-by for every service), and a topological implementation order. This file answers "what breaks if this service changes?" and "what must exist before this service can function?"
+The knowledge graph itself is engine-only. The `codebase-memory-mcp` engine (by DeusData, 159 languages, 100% local) maintains the structural graph in-process. No `architecture.json`, `hotspots.jsonl`, or `*.mermaid` files are committed to the repository.
 
-### tech-matrix.md
+The only committed file in `draft/graph/` is `schema.yaml` — a gate marker containing engine metadata, project identity, and point-of-index counts. Its `access: engine-live` field signals that structural data is queried live from the engine, not read from committed files.
 
-A technology distribution report showing which languages, databases, frameworks, and infrastructure components are used across which services. It identifies organizational standards (technologies used by the majority of services) and variances (services that deviate, with documented justifications).
+## Flags
 
-### Synthesized Root Context
+`/draft:init` supports two flags relevant to monorepo workflows:
 
-If the root-leveldraft/product.md,draft/architecture.md, anddraft/tech-stack.mdare missing or are placeholders,/draft:indexsynthesizes them from service-level data:
+* `--module-only` — Analyzes only the current sub-module; skips root-level synthesis. Use when you want to refresh a single service without touching the root graph.
+* `--graph-only` — Builds or refreshes the graph without regenerating prose context files (architecture.md, .ai-context.md, etc.). Use for fast graph updates after code changes.
 
-* product.md— Aggregated product vision from all service visions, deduplicated target users, capability matrix mapping features to services
-* architecture.md— System-of-systems view with topology diagram, service directory, shared infrastructure, and cross-cutting patterns
-* tech-stack.md— Organizational standards derived from majority usage, approved variances, shared libraries
-After generatingarchitecture.md, the Condensation Subroutine runs to produce a root-level.ai-context.md— a token-optimized aggregate of all service knowledge.
+## The Workflow
 
-## Root-Level vs. Service-Level Context
+A typical monorepo onboarding sequence:
 
-After indexing, the monorepo has two layers of context:
+1. Run `/draft:init` at the repo root — builds the whole-repo graph and generates root-level context files.
+2. Run `/draft:init` inside each sub-module that needs its own spec/plan context — each one generates module-local context and writes a `draft/graph/root-link.json` pointing to the root.
+3. Work inside any sub-module — Draft automatically loads module-local context for implementation tasks and follows the root link for cross-module analysis (impact, deep-review, bughunt across services).
 
-When working within a single service, the AI loads that service's context. When making cross-service decisions — adding a new API dependency, changing a shared schema, planning a migration — the AI loads root-level context.
+Re-run `/draft:init` (or `/draft:init --graph-only`) after significant architecture changes to any service, before major cross-service planning, or as part of documentation hygiene. The graph engine handles incremental updates; unchanged modules are not re-analyzed.
 
-## Service Manifests
+## Cross-Module Analysis
 
-For each initialized service,/draft:indexcreates or updates amanifest.jsoninside the service'sdraft/directory. This manifest contains the service name, type, summary, primary technology, dependencies on other services, dependents (reverse lookup), team ownership, and indexing timestamps. Manifests enable fast re-indexing without re-reading all markdown files.
+Once root links are in place, any graph-aware Draft command can scope across modules:
 
-## Initializing Missing Services
-
-Running/draft:index --init-missingoffers to initialize uninitialized services. For each one, Draft prompts with four options:y(initialize this service),n(skip),all(initialize all remaining), orskip-rest(skip all remaining). This makes it practical to bring an entire monorepo under Draft management incrementally.
-
-## Bughunt Mode
-
-/draft:indexalso supports a bughunt aggregation mode. Running/draft:index bughuntexecutes/draft:bughuntsequentially across all initialized services (or a specified subset), then generatesdraft/bughunt-summary.md— an aggregate report showing bug counts by severity across all services, directories requiring immediate attention, and links to individual service reports.
-
-Re-run/draft:indexafter initializing a new service, after significant architecture changes to any service, before major cross-service planning, or as part of weekly documentation hygiene. The command preserves manual edits in sections marked with<!-- MANUAL START -->and<!-- MANUAL END -->comments.
+* `/draft:impact` — follows the root link to find downstream dependencies across service boundaries.
+* `/draft:deep-review` — loads cross-module invariants from the root graph when reviewing a service that calls others.
+* `/draft:bughunt` — can be scoped to a single service or run against the root graph for a system-wide sweep.
 
+The federation is transparent: commands do not need to know whether they are running in a mono-module repo or a large monorepo. The root-link mechanism handles the routing.