fix(docs,scanners): route conventions, style, and scanner self-containment

Scanners:
- Remove absolute-path `Load` directive from both
  quality-scan-customization-surface.md files. The hardcoded
  /Users/brianmadison/... path would never resolve in consumer
  environments. Scanners now rely solely on their embedded Opportunity
  and Abuse lens tables, matching the self-contained convention of
  every other quality-scan-*.md in the codebase.

Docs route convention:
- Append `.md` to 12 internal cross-links to match the site convention
  (/explanation/foo.md, /how-to/foo.md form). Touches
  make-a-skill-customizable.md (4), what-are-bmad-agents.md (1),
  what-are-workflows.md (2), skill-authoring-best-practices.md (2),
  module-configuration.md (1), agent-memory-and-personalization.md (1).

Docs external host:
- Swap 3 end-user-guide links from bmadcode.github.io/bmad to
  docs.bmad-method.org/how-to/customize-bmad/ to point at the correct
  published docs site for BMAD-METHOD.

Docs style:
- Rewrite how-to hook from "Use this guide when..." to "This guide
  walks through..." matching the convention used by
  distribute-your-module.md.
- Remove first-person voice from the bmad-session-prep worked example
  in customization-for-authors.md. "Here's how I'd customize it" ->
  "Here's how to think about its customization surface"; "I'm not
  trying to catalog every RPG; I ship one default" -> "The skill isn't
  trying to catalog every RPG; it ships one default"; "### What I'd
  NOT expose" -> "### What Not to Expose".

Author: bmadcode

docs/explanation/agent-memory-and-personalization.md

@@ -43,7 +43,7 @@ ALLCAPS files form the skeleton: consistent structure across all memory agents.
 
 ### Sanctum Is the Customization Surface
 
-For memory and autonomous agents, the sanctum is where customization belongs. PERSONA, CREED, and BOND are calibrated at First Breath, edited by the owner as the relationship develops, and shared across teams as sanctum files when a whole table wants the same voice. The parallel `customize.toml` override surface that stateless agents and workflows use (activation hooks, persistent facts, scalar swaps) is opt-out by default for memory archetypes. Opt in only when you have a narrow org-level need the sanctum cannot express, such as a pre-sanctum compliance acknowledgment before rebirth. See [Customization for Authors](/explanation/customization-for-authors) for the reasoning.
+For memory and autonomous agents, the sanctum is where customization belongs. PERSONA, CREED, and BOND are calibrated at First Breath, edited by the owner as the relationship develops, and shared across teams as sanctum files when a whole table wants the same voice. The parallel `customize.toml` override surface that stateless agents and workflows use (activation hooks, persistent facts, scalar swaps) is opt-out by default for memory archetypes. Opt in only when you have a narrow org-level need the sanctum cannot express, such as a pre-sanctum compliance acknowledgment before rebirth. See [Customization for Authors](/explanation/customization-for-authors.md) for the reasoning.
 
 ### Token Discipline
 

docs/explanation/customization-for-authors.md

@@ -3,7 +3,7 @@ title: 'Customization for Authors'
 description: How to decide whether your skill should support end-user customization, and what to expose when it does
 ---
 
-Shipping a `customize.toml` is opt-in per skill. This is the author-side counterpart to [How to Customize BMad](https://bmadcode.github.io/bmad/how-to/customize-bmad), which covers the end-user view. Read that first if you haven't; it shows what users experience when they override a skill. This guide is about deciding whether to give them that surface at all.
+Shipping a `customize.toml` is opt-in per skill. This is the author-side counterpart to [How to Customize BMad](https://docs.bmad-method.org/how-to/customize-bmad/), which covers the end-user view. Read that first if you haven't; it shows what users experience when they override a skill. This guide is about deciding whether to give them that surface at all.
 
 ## The Problem
 
@@ -54,7 +54,7 @@ Opt in only when you have a specific org-level need the sanctum can't express. P
 
 A weekly session-prep workflow for tabletop RPG game masters. It reads the last session's log, reviews open campaign threads, drafts the scene spine, stats NPCs and encounters, and produces a GM notes document to run from.
 
-Here's how I'd customize it, field by field.
+Here's how to think about its customization surface, field by field.
 
 ### `persistent_facts` (default globs the campaign bible)
 
@@ -73,7 +73,7 @@ Every GM runs a different world. Without their campaign bible in context, the wo
 system_rules_template = "resources/dnd-5e-quick-reference.md"
 ```
 
-D&D 5e, Pathfinder 2e, and Call of Cthulhu reason about encounters in very different ways. A PF2e GM who overrides this with their own rules reference gets correctly-calibrated encounter math without the workflow pretending to know a system it doesn't. I'm not trying to catalog every RPG; I ship one default that covers most users and let everyone else swap in their own reference. The `*_template` suffix signals what changes if you touch it.
+D&D 5e, Pathfinder 2e, and Call of Cthulhu reason about encounters in very different ways. A PF2e GM who overrides this with their own rules reference gets correctly-calibrated encounter math without the workflow pretending to know a system it doesn't. The skill isn't trying to catalog every RPG; it ships one default that covers most users and lets everyone else swap in their own reference. The `*_template` suffix signals what changes if the user touches it.
 
 ### `session_notes_template` (scalar)
 
@@ -107,9 +107,9 @@ activation_steps_prepend = [
 
 Not every GM keeps session logs. The ones who do want the pre-load; the ones who don't would get a broken activation if it were baked in. Opt-in via the prepend hook lets both tables use the same skill.
 
-### What I'd NOT expose
+### What Not to Expose
 
-The stage sequence (recap, threads, spine, NPCs, notes) is the skill's identity. A GM who wants a very different flow (solo journaling, West Marches gossip round) should fork. Every stage I make optional erodes what the skill is.
+The stage sequence (recap, threads, spine, NPCs, notes) is the skill's identity. A GM who wants a very different flow (solo journaling, West Marches gossip round) should fork. Every stage made optional erodes what the skill is.
 
 Mechanical encounter math toggles like `auto_balance_cr` or `verbose_stat_blocks` stay out. The LLM handles those naturally once it has the system reference. Toggles here would amount to telling the executor how to do its job.
 

docs/explanation/module-configuration.md

@@ -25,7 +25,7 @@ If you are building a single standalone agent or workflow, you do not need a sep
 
 Module configuration (this doc) and per-skill customization (`customize.toml`) are different surfaces with different jobs. Configuration is about install-time answers: paths, language, team preferences, per-module install answers. It lives in `_bmad/config.toml` and `config.user.toml` at the project root and is consumed by many skills. Customization is about per-skill behavior overrides: activation hooks, persistent facts, swappable templates. It lives in `_bmad/custom/{skill-name}.toml` and is scoped to one skill.
 
-Use configuration when the value is cross-cutting (every skill needs to know the output folder). Use customization when the value shapes one skill's behavior (this workflow's brief template). Some values legitimately fit both surfaces; the [End-User Customization Guide](https://bmadcode.github.io/bmad/how-to/customize-bmad) includes a decision table for that case. For the author-side decision about whether to expose customization at all, see [Customization for Authors](/explanation/customization-for-authors).
+Use configuration when the value is cross-cutting (every skill needs to know the output folder). Use customization when the value shapes one skill's behavior (this workflow's brief template). Some values legitimately fit both surfaces; the [End-User Customization Guide](https://docs.bmad-method.org/how-to/customize-bmad/) includes a decision table for that case. For the author-side decision about whether to expose customization at all, see [Customization for Authors](/explanation/customization-for-authors.md).
 
 ## What Module Registration Does
 

docs/explanation/skill-authoring-best-practices.md

@@ -38,7 +38,7 @@ Six dimensions to keep in mind during the build phase. The quality scanners chec
 
 ## Shipping a Customization Surface
 
-When your skill's users come from varied contexts (different orgs, different domains, different taste in output formats), a `customize.toml` surface lets them override specific fields without forking. It's opt-in per skill, and the decision is deliberate: every knob you ship is a promise the resolver will carry across releases. Before you opt in during the build, read [Customization for Authors](/explanation/customization-for-authors) for the decision framework and [How to Make a Skill Customizable](/how-to/make-a-skill-customizable) for the mechanics.
+When your skill's users come from varied contexts (different orgs, different domains, different taste in output formats), a `customize.toml` surface lets them override specific fields without forking. It's opt-in per skill, and the decision is deliberate: every knob you ship is a promise the resolver will carry across releases. Before you opt in during the build, read [Customization for Authors](/explanation/customization-for-authors.md) for the decision framework and [How to Make a Skill Customizable](/how-to/make-a-skill-customizable.md) for the mechanics.
 
 ## Common Patterns
 

docs/explanation/what-are-bmad-agents.md

@@ -91,7 +91,7 @@ Every agent ships a `customize.toml` next to its `SKILL.md`. The metadata block
 
 For memory and autonomous agents, the sanctum is the primary customization surface. Persona, creed, bond, and capabilities all live there and evolve with the owner. A `customize.toml` override surface would compete with that, so the default for those archetypes is opt-out.
 
-See [Customization for Authors](/explanation/customization-for-authors) for the decision guide, or [How to Customize BMad](https://bmadcode.github.io/bmad/how-to/customize-bmad) for the end-user view.
+See [Customization for Authors](/explanation/customization-for-authors.md) for the decision guide, or [How to Customize BMad](https://docs.bmad-method.org/how-to/customize-bmad/) for the end-user view.
 
 ## Building Agents
 

docs/explanation/what-are-workflows.md

@@ -66,7 +66,7 @@ Workflows are also excellent as the **internal capabilities** of an agent. Build
 
 Workflow customization is fully opt-in. If you don't need users to override anything, don't ship a `customize.toml` at all; the workflow runs with hardcoded paths and defaults. If you do opt in, the builder walks you through Configurability Discovery, where you name the scalars (templates, output paths, hooks) you want to expose. Users override them through the three-layer model at `_bmad/custom/{skill-name}.toml` and `.user.toml`.
 
-See [Customization for Authors](/explanation/customization-for-authors) for the decision guide and [How to Make a Skill Customizable](/how-to/make-a-skill-customizable) for the build-time steps.
+See [Customization for Authors](/explanation/customization-for-authors.md) for the decision guide and [How to Make a Skill Customizable](/how-to/make-a-skill-customizable.md) for the build-time steps.
 
 ## Building Workflows
 

docs/how-to/make-a-skill-customizable.md

@@ -3,7 +3,7 @@ title: 'How to Make a Skill Customizable'
 description: Opt your skill into end-user customization during the build, name your scalars well, and test an override
 ---
 
-Use this guide when you're building a skill and you've decided (see [Customization for Authors](/explanation/customization-for-authors)) that end users should be able to override parts of its behavior without forking. You'll hit the opt-in moment in the builder, pick names for the scalars you expose, and verify an override actually works.
+This guide walks through opting a skill into end-user customization during a build. You'll hit the opt-in moment in the builder, pick names for the scalars you expose, and verify an override actually fires. Read [Customization for Authors](/explanation/customization-for-authors.md) first if you haven't decided whether to opt in.
 
 ## When to Use This
 
@@ -15,13 +15,13 @@ Use this guide when you're building a skill and you've decided (see [Customizati
 
 - Your skill is a single-purpose utility users will invoke and forget (overriding makes no sense)
 - You're building a memory or autonomous agent whose behavior lives in the sanctum (the sanctum is already the customization surface)
-- You haven't decided yet whether you need customization (read the [author guide](/explanation/customization-for-authors) first)
+- You haven't decided yet whether you need customization (read the [author guide](/explanation/customization-for-authors.md) first)
 
 :::note[Prerequisites]
 
 - The Agent Builder or Workflow Builder is available in your project
 - You've sketched what your skill does and roughly what stages or capabilities it has
-- You've read the [author guide](/explanation/customization-for-authors) and know which knobs you want to expose
+- You've read the [author guide](/explanation/customization-for-authors.md) and know which knobs you want to expose
 :::
 
 ## Steps
@@ -141,4 +141,4 @@ Users get:
 
 - **Ship one good default. Skip the booleans.** A flag like `include_combat_section` usually means you haven't decided what the skill does yet. Pick the default. Users who want a radically different shape can fork.
 - **Sentence-shaped variance belongs in `persistent_facts`.** Tone, house rules, and domain constraints are sentences the skill carries through the run. Don't enumerate them as scalars.
-- **Read [Customization for Authors](/explanation/customization-for-authors) first.** It gives you the three questions to ask for each candidate knob before you start Configurability Discovery.
+- **Read [Customization for Authors](/explanation/customization-for-authors.md) first.** It gives you the three questions to ask for each candidate knob before you start Configurability Discovery.

skills/bmad-agent-builder/references/quality-scan-customization-surface.md

@@ -15,8 +15,6 @@ Your job is to find the sweet spot the author missed, in either direction, and t
 
 **This is purely advisory.** Nothing here is broken. Everything is either an opportunity to expose or a risk to trim.
 
-Load `/Users/brianmadison/bmad-code/bmad-bmb/custom-support/docs/explanation/customization-for-authors.md` if it's accessible for the decision framework; otherwise apply the principles below directly.
-
 ## Your Role
 
 You are NOT checking structural completeness (structure), agent cohesion (agent-cohesion), sanctum architecture (sanctum-architecture), prose craft (prompt-craft), efficiency (execution-efficiency), or UX delight (enhancement-opportunities). You are the customization-surface economist.

skills/bmad-workflow-builder/references/quality-scan-customization-surface.md

@@ -13,8 +13,6 @@ Your job is to find the sweet spot the author missed, in either direction.
 
 **This is purely advisory.** Nothing here is broken. Everything is either an opportunity to expose or a risk to trim.
 
-Load `/Users/brianmadison/bmad-code/bmad-bmb/custom-support/docs/explanation/customization-for-authors.md` if it's accessible for the decision framework; otherwise apply the principles below directly.
-
 ## Your Role
 
 You are NOT checking structural completeness (workflow-integrity), prose craft (prompt-craft), efficiency (execution-efficiency), or UX delight (enhancement-opportunities). You are the customization-surface economist.