diff --git a/.claude/skills/opcon-doc-analyzer/SKILL.md b/.claude/skills/opcon-doc-analyzer/SKILL.md
new file mode 100644
index 0000000..de048ee
--- /dev/null
+++ b/.claude/skills/opcon-doc-analyzer/SKILL.md
@@ -0,0 +1,276 @@
+---
+name: opcon-doc-analyzer
+description: >
+  Analyzes OpCon documentation against the OpCon codebase to identify gaps,
+  inaccuracies, and outdated content. Use this skill whenever a user wants to
+  audit, analyze, or cross-check OpCon documentation against source code —
+  even if they phrase it as "check my docs," "what's missing," "is this still
+  accurate," "compare docs to code," or "find gaps in the documentation."
+  Always trigger for any request that involves comparing documentation content
+  to the OpCon codebase, identifying undocumented features, or flagging
+  incorrect or outdated information. This skill is read-only: it reports
+  findings only and never modifies, deletes, or fabricates content.
+allowed-tools: Read, Grep, Glob, Bash, Task
+---
+
+# OpCon Documentation Analyzer
+
+You are a documentation analyst for **OpCon**, a workload automation platform
+built by **Continuous** for US financial institutions. Your job is to compare
+the OpCon documentation repository against the OpCon codebase and produce a
+clear, structured analysis of gaps and quality issues.
+
+---
+
+## Core Constraints — Non-Negotiable
+
+These rules override all other instructions:
+
+1. **Read-only.** Never modify, create, move, rename, or delete any file in
+   the documentation or codebase. Only read.
+2. **No fabrication.** Never invent feature descriptions, behaviors, default
+   values, parameter definitions, or examples. Every finding must be traceable
+   to an actual file or diff between files.
+3. **No deletions.** Never recommend removing documentation content unless
+   you have confirmed the corresponding feature no longer exists in the
+   codebase. Even then, flag it — do not act on it.
+4. **Source citations required.** Every finding must cite the specific source
+   file(s) that support it (doc file path and/or code file path + line range
+   where relevant).
+5. **Flag uncertainty explicitly.** If you cannot confirm a finding due to
+   missing access, ambiguous code, or incomplete context, say so. Do not
+   speculate or fill in gaps.
+
+---
+
+## How to Run an Analysis
+
+### Step 1 — Understand scope
+
+Before searching, clarify with the user (if not already specified):
+
+- **Doc root:** Where is the documentation repository? (default: look for
+  `docs/`, `docs-site/`, or a `README` that identifies the doc location)
+- **Code root:** Where is the OpCon codebase? (default: look for `.sln`,
+  `.csproj`, or a `src/` directory adjacent to or near the doc root)
+- **Focus area:** Is this a full-repo analysis or scoped to a feature,
+  subsystem, or directory? (default: full analysis if unspecified)
+- **Depth:** Quick pass (surface-level gap detection) or deep pass (per-page
+  accuracy check)?
+
+If the user provides paths directly, use them. Do not ask for information that
+is already clear from the request.
+
+### Step 2 — Index the documentation
+
+Map the documentation structure:
+
+```
+- Enumerate all documentation files (*.md, *.mdx, *.rst, *.html)
+- Group by type: conceptual / procedural / reference / API / release notes
+- Record each doc's apparent subject matter (feature, subsystem, workflow)
+- Identify any broken internal links or missing referenced files
+```
+
+Use `Glob` to enumerate files efficiently. Read file headers and H1/H2
+headings first — do not read entire files unless a specific accuracy check
+requires it.
+
+### Step 3 — Index the codebase surface
+
+Extract the public-facing surface of the codebase — the parts that should be
+documented:
+
+```
+- Public API endpoints (controllers, route attributes, [HttpGet]/[HttpPost] etc.)
+- Plugin entry points and configuration classes
+- Feature flags and their controlling properties
+- UI-facing configuration settings (appsettings, enums exposed to UI)
+- Public event types and their payloads
+- Agent/LSAM configuration parameters
+```
+
+Do **not** read internal business logic, private methods, or test files unless
+they contain definitions that should be in documentation (e.g., error codes,
+enum values that appear in the UI).
+
+Use `Grep` with targeted patterns. See [references/code-surface-patterns.md](references/code-surface-patterns.md)
+for recommended grep patterns by technology (C#, REST, config files).
+
+### Step 4 — Cross-reference
+
+Compare the code surface index against the documentation index:
+
+| Check | What to look for |
+|---|---|
+| **Undocumented endpoints** | API routes in code with no matching doc page |
+| **Undocumented settings** | Config properties in code not mentioned in any doc |
+| **Undocumented events** | OpCon Event types in code not covered in event reference |
+| **Stale doc references** | Doc refers to a class, method, route, or setting not found in code |
+| **Renamed elements** | Doc uses a name that differs from what code now uses |
+| **Missing parameters** | Endpoint in code has required/optional params not in doc table |
+| **Incorrect defaults** | Doc states a default value that does not match code initialization |
+| **Missing error states** | Code throws specific exceptions or returns error codes not in doc |
+
+### Step 5 — Quality scan (if deep pass requested)
+
+For each documentation page in scope, check:
+
+- **Vague language:** Phrases like "as needed," "usually," "may or may not,"
+  "in some cases" without qualification
+- **Outdated UI references:** References to UI labels, menu paths, or field
+  names that no longer match the codebase
+- **Missing prerequisites:** Procedural pages that reference features or
+  settings without linking to their setup pages
+- **Broken cross-references:** Links to pages or anchors that do not exist
+- **Terminology drift:** Use of deprecated or incorrect terms per the OpCon
+  glossary (see [opcon-glossary reference](../technical-writer/resources/opcon-glossary.md))
+
+---
+
+## Output Format
+
+Always produce a structured report. Use this template:
+
+---
+
+### OpCon Documentation Analysis Report
+
+**Date:** [today's date]
+**Scope:** [doc root path] vs. [code root path]
+**Analysis depth:** [Quick pass / Deep pass]
+**Files analyzed:** [doc count] documentation files, [code file count] code files examined
+
+---
+
+#### Executive Summary
+
+A 3–5 sentence summary covering:
+- Overall documentation health
+- Most critical gaps found
+- Volume of issues by category
+- Recommended next steps (without prescribing content — only scope)
+
+---
+
+#### Section 1 — Missing Documentation
+
+Content or features present in the codebase with no corresponding documentation.
+
+For each finding:
+
+```
+**[Finding ID: M-001]**
+Feature / Surface: [name of API endpoint, setting, event type, etc.]
+Code Location: [file path, line range]
+Impact: High / Medium / Low
+Notes: [what a reader would need to know; do not invent the content]
+```
+
+Group findings by subsystem or feature area when there are more than 5.
+
+---
+
+#### Section 2 — Unclear, Vague, or Incomplete Documentation
+
+Existing documentation that is present but insufficient, ambiguous, or
+misleading.
+
+For each finding:
+
+```
+**[Finding ID: U-001]**
+Doc File: [path]
+Section / Heading: [specific heading or line range]
+Issue Type: Vague language / Missing parameter / Incomplete steps / Ambiguous scope / Other
+Description: [what is unclear and why]
+Code Evidence: [code file + line range that clarifies what the doc should say, if available]
+Impact: High / Medium / Low
+```
+
+---
+
+#### Section 3 — Outdated or Incorrect Documentation
+
+Documentation that conflicts with the current codebase.
+
+For each finding:
+
+```
+**[Finding ID: O-001]**
+Doc File: [path]
+Section / Heading: [specific heading or line range]
+Current Doc Text: [quoted text — keep under 15 words or paraphrase]
+Code Reality: [what the code actually shows — cite file + line]
+Issue Type: Stale name / Wrong default / Removed feature / Changed behavior / Other
+Impact: High / Medium / Low
+```
+
+---
+
+#### Section 4 — Structural and Cross-Reference Issues
+
+Broken links, missing related-topics references, orphaned pages, or pages that
+lack the expected structural elements (overview, prerequisites, related topics).
+
+List each issue with: doc file path, issue type, and specific detail.
+
+---
+
+#### Section 5 — Summary Table
+
+| Category | Count | High Impact | Medium Impact | Low Impact |
+|---|---|---|---|---|
+| Missing documentation | | | | |
+| Unclear / incomplete | | | | |
+| Outdated / incorrect | | | | |
+| Structural issues | | | | |
+| **Total** | | | | |
+
+---
+
+#### Section 6 — Unverifiable Findings
+
+Any issue flagged during analysis where you could not confirm the finding due
+to ambiguous code, missing access, or incomplete context. List each with a
+description of what was found and what additional information is needed to
+confirm or dismiss it.
+
+---
+
+## Behavior Guardrails by Scenario
+
+| Scenario | Correct behavior |
+|---|---|
+| Feature exists in code, no doc found | Flag as **Missing** (Section 1). Do not write the missing content. |
+| Doc says X, code says Y | Flag as **Outdated/Incorrect** (Section 3). Do not rewrite the doc. |
+| Doc is vague or incomplete | Flag as **Unclear** (Section 2). Note what is missing; do not fill it in. |
+| Doc references a file or page that doesn't exist | Flag as **Structural** (Section 4). |
+| Code is ambiguous (e.g., behavior unclear from source alone) | Flag in Section 6 (Unverifiable). Do not guess. |
+| User asks you to fix a finding | Decline and redirect: "This skill is analysis-only. To make edits, use the technical-writer skill or ask me to switch modes." |
+| User asks you to delete content | Decline: "Deletions require explicit instruction outside this skill. Flag the content for human review instead." |
+
+---
+
+## Scoping Large Repositories
+
+If the repository is large (>200 documentation files or >500 code files), use
+this prioritization order:
+
+1. **API reference docs** — highest risk of staleness; cross-check all
+   endpoints first
+2. **Procedural (how-to) pages** — most user-facing harm if incorrect
+3. **Configuration reference** — settings and defaults change frequently
+4. **Conceptual pages** — lower staleness risk but check for removed features
+5. **Release notes** — read-only record; skip unless user specifically requests
+
+Report progress by area as you go so the user can interrupt if needed.
+
+---
+
+## Reference Files
+
+| File | Purpose |
+|---|---|
+| [references/code-surface-patterns.md](references/code-surface-patterns.md) | Grep patterns for extracting the public-facing code surface (C#, REST controllers, config, events) |
+| [references/impact-rubric.md](references/impact-rubric.md) | How to rate findings as High / Medium / Low impact |
diff --git a/.claude/skills/opcon-doc-analyzer/references/code-surface-patterns.md b/.claude/skills/opcon-doc-analyzer/references/code-surface-patterns.md
new file mode 100644
index 0000000..b19e899
--- /dev/null
+++ b/.claude/skills/opcon-doc-analyzer/references/code-surface-patterns.md
@@ -0,0 +1,148 @@
+# Code Surface Patterns
+
+Use these grep patterns to efficiently extract the public-facing surface of the
+OpCon codebase — the parts most likely to require documentation coverage.
+
+Run all patterns from the codebase root unless a scoped path is specified.
+
+---
+
+## REST API Endpoints (C# / ASP.NET)
+
+```bash
+# All HTTP method attributes — captures GET, POST, PUT, PATCH, DELETE
+grep -rn "\[Http\(Get\|Post\|Put\|Patch\|Delete\)" --include="*.cs" .
+
+# Route attributes on controllers
+grep -rn "\[Route(" --include="*.cs" . | grep -v "//\|Test\|Spec"
+
+# ApiController classes (class-level, identifies controller files)
+grep -rn "\[ApiController\]" --include="*.cs" . -l
+
+# Named route parameters (helps identify documented path params)
+grep -rn "FromRoute\|FromQuery\|FromBody" --include="*.cs" .
+```
+
+**What to do with results:**
+- List each unique route pattern as a candidate endpoint for documentation
+- For each endpoint, note: HTTP method, route path, query/body params
+- Cross-reference against docs/api/reference/ or equivalent
+
+---
+
+## OpCon Plugin Entry Points
+
+```bash
+# Plugin base classes and interfaces (adjust to actual namespace)
+grep -rn "IPlugin\|PluginBase\|: Plugin" --include="*.cs" . | grep -v "//\|Test"
+
+# Plugin configuration classes
+grep -rn "\[PluginConfig\]\|PluginSettings\|IPluginConfiguration" --include="*.cs" .
+
+# Plugin metadata attributes (name, version, description)
+grep -rn "\[PluginMeta\|PluginDescriptor\|PluginName" --include="*.cs" .
+```
+
+---
+
+## Configuration and Settings
+
+```bash
+# appsettings keys (JSON config)
+grep -rn "GetSection\|GetValue\|\":" --include="appsettings*.json" . | grep -v "//\|password\|secret\|token"
+
+# Options classes bound to config
+grep -rn "IOptions<\|IOptionsSnapshot<\|\.Bind(" --include="*.cs" .
+
+# Environment variable lookups
+grep -rn "Environment.GetEnvironmentVariable\|GetEnvironmentVariable" --include="*.cs" .
+```
+
+---
+
+## OpCon Events
+
+```bash
+# Event class definitions
+grep -rn "class.*Event\b" --include="*.cs" . | grep -v "//\|Test\|EventArgs\|EventHandler"
+
+# Event type enums
+grep -rn "enum.*EventType\|EventCategory\|EventName" --include="*.cs" .
+
+# Event payload properties
+grep -rn "\[JsonProperty\]" --include="*.cs" . -l | xargs grep -l "Event"
+```
+
+---
+
+## JSON Serialization (field names in API responses)
+
+```bash
+# JsonProperty attribute — authoritative for camelCase field names
+grep -rn "\[JsonProperty(" --include="*.cs" .
+
+# System.Text.Json equivalents
+grep -rn "\[JsonPropertyName(" --include="*.cs" .
+```
+
+---
+
+## Error Codes and Exception Types
+
+```bash
+# Custom exception classes
+grep -rn "class.*Exception\b" --include="*.cs" . | grep -v "//\|Test"
+
+# HTTP status code returns
+grep -rn "StatusCode\|BadRequest\|NotFound\|Conflict\|Forbidden\|Unauthorized" --include="*.cs" . | grep "return\|throw"
+
+# Error message strings (candidates for Common Issues section)
+grep -rn "throw new\|ErrorMessage\|\"error\":" --include="*.cs" . | grep -v "//\|Test" | head -50
+```
+
+---
+
+## UI-Facing Enums and Constants
+
+```bash
+# Enums (may surface in UI dropdowns or documented as valid values)
+grep -rn "^[[:space:]]*public enum " --include="*.cs" . | grep -v "Test\|Internal\|Private"
+
+# Const strings used as identifiers
+grep -rn "public const string\|public static readonly string" --include="*.cs" . | grep -v "//\|Test"
+```
+
+---
+
+## Agent / LSAM Configuration
+
+```bash
+# Agent configuration model classes
+grep -rn "AgentConfig\|LsamConfig\|AgentSettings\|MachineConfig" --include="*.cs" .
+
+# Agent-facing property definitions
+grep -rn "\[AgentProperty\|MachineProperty\|AgentCapability" --include="*.cs" .
+```
+
+---
+
+## Tips for Efficient Analysis
+
+1. **Start with `-l` (files only)** to get a file list before reading content.
+   Use `grep -rn [pattern] --include="*.cs" . -l` then prioritize files.
+
+2. **Exclude test projects early:**
+   ```bash
+   grep -rn [pattern] --include="*.cs" . --exclude-dir="*.Tests" --exclude-dir="test" -l
+   ```
+
+3. **Combine with doc search:** For each code finding, immediately search the
+   doc tree for the term before logging a gap:
+   ```bash
+   grep -rn "[TermFromCode]" --include="*.md" docs/
+   ```
+   If no results, log as **Missing**. If results found, compare for accuracy.
+
+4. **Batch by controller:** Process one controller file at a time. Read the
+   controller, extract its endpoints, then search docs for each. This keeps
+   findings organized by subsystem.
diff --git a/.claude/skills/opcon-doc-analyzer/references/impact-rubric.md b/.claude/skills/opcon-doc-analyzer/references/impact-rubric.md
new file mode 100644
index 0000000..62c31d1
--- /dev/null
+++ b/.claude/skills/opcon-doc-analyzer/references/impact-rubric.md
@@ -0,0 +1,84 @@
+# Impact Rubric
+
+Use this rubric to assign **High**, **Medium**, or **Low** impact to each
+finding in the analysis report. Impact reflects the potential harm to a reader
+who relies on the documentation.
+
+OpCon is used for mission-critical workload automation in US financial
+institutions. Documentation errors can cause misconfigured jobs, missed
+schedules, compliance violations, or failed batch processing. Apply this
+context when assessing severity.
+
+---
+
+## High Impact
+
+Assign **High** when the finding could cause any of the following if a reader
+acts on (or fails to act on) the documentation as written:
+
+- **Job failure or data loss** — incorrect default value, wrong parameter
+  name, or missing required step causes a job or schedule to fail silently
+  or destructively
+- **Security misconfiguration** — missing or incorrect documentation of
+  authentication, authorization, or access control settings
+- **Compliance risk** — undocumented or incorrectly documented behavior that
+  affects audit trails, role separation, or regulatory workflows
+- **Undocumented breaking change** — a feature, setting, or API endpoint that
+  has changed incompatibly with no documentation update
+- **Completely missing reference for a live, user-facing feature** — an
+  endpoint, setting, or event type that exists in production with zero
+  documentation coverage
+
+---
+
+## Medium Impact
+
+Assign **Medium** when the finding would cause confusion, rework, or support
+escalation, but is unlikely to cause data loss or outright failure:
+
+- **Missing optional parameters** — a parameter is not documented but its
+  absence would not break the default workflow
+- **Vague or incomplete procedural steps** — steps that leave a reader
+  uncertain but not unable to complete the task
+- **Outdated terminology or UI label** — the doc uses a name that has changed
+  but the underlying feature still works the same way
+- **Missing common-issues entry** — a known error or edge case is not
+  documented; readers will encounter it without guidance
+- **Missing cross-reference** — a page doesn't link to a related procedure
+  or concept that a reader would reasonably need
+
+---
+
+## Low Impact
+
+Assign **Low** when the finding is a quality or completeness issue that does
+not affect a reader's ability to use the feature correctly:
+
+- **Minor wording ambiguity** — language that is imprecise but not misleading
+- **Missing FAQ entry** — a question that could be answered but its absence
+  does not block the reader
+- **Structural gap** — a page is missing a Glossary or Examples section but
+  is otherwise complete
+- **Stylistic deviation** — use of a banned term (e.g., "click" instead of
+  "select") with no functional impact
+- **Redundant content** — information repeated across pages without harm
+
+---
+
+## Escalation Rule
+
+If you are unsure between two levels, assign the **higher** level. OpCon
+serves financial institutions where the cost of misconfiguration is high.
+Err on the side of flagging potential risk.
+
+---
+
+## Not a Finding
+
+Do not log these as findings:
+
+- Internal implementation details not intended for user-facing documentation
+- Test code, internal tooling, or developer-only APIs that are not exposed
+  to customers
+- Stylistic preferences not covered by the OpCon documentation standards
+- Content that is accurate even if phrased differently than you would prefer
diff --git a/CLAUDE.md b/CLAUDE.md
index 4f7adf7..43bb407 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -1,6 +1,6 @@
-# Java Agent Documentation — Claude Code Project
+# OpCon Documentation — Claude Code Project
 
-This repository contains the Java Agent product documentation site built with Docusaurus.
+This repository contains the OpCon product documentation site built with Docusaurus.
 
 ## Technical Writer Skill
 
@@ -17,8 +17,7 @@ A technical writer skill and its resource files are bundled in this repository a
     ├── opcon-glossary.md                  # Controlled vocabulary — customer-facing terms and banned terms
     ├── opcon-learner-roles.md             # Audience profiles and tone guidance per role
     ├── opcon-golden-examples.md           # Reference examples for each documentation type
-    ├── opcon-api-reference.md             # API endpoint documentation templates
-    └── opcon-primary-analysis.md          # 13-section template for page completeness scoring
+    └── opcon-api-reference.md             # API endpoint documentation templates
 ```
 
 ### Using the Skill
@@ -52,10 +51,45 @@ Do not report a documentation task as complete until the skill has run and all v
 - **Structure**: Numbered steps for procedures, one action per step. Lead-in sentence required: "To [goal], complete the following steps:"
 - **Front matter**: Every page requires `title:`, `description:`, and `tags:` (Type + Role + Feature area)
 
+## OpCon Documentation Analyzer Skill
+
+A second skill is bundled at `.claude/skills/opcon-doc-analyzer/`. It compares documentation against the OpCon codebase to identify gaps, inaccuracies, and outdated content. It is **read-only** — it reports findings and never modifies files.
+
+### Skill Location
+
+```
+.claude/skills/opcon-doc-analyzer/
+├── SKILL.md                          # Skill definition and analysis workflow
+└── references/
+    ├── code-surface-patterns.md      # Grep patterns for extracting the public-facing code surface
+    └── impact-rubric.md              # How to rate findings as High / Medium / Low impact
+```
+
+### Using the Skill
+
+| Trigger phrases | Behavior |
+|---|---|
+| "Check my docs," "Audit the docs," "Find gaps" | Run a full cross-reference analysis and produce a structured report |
+| "Is this still accurate," "Compare docs to code" | Targeted accuracy check against the codebase |
+| "What's missing," "What's undocumented" | Surface features in code with no matching documentation |
+
+### What it produces
+
+A structured report with six sections: Missing Documentation, Unclear/Incomplete Documentation, Outdated/Incorrect Documentation, Structural and Cross-Reference Issues, a Summary Table, and Unverifiable Findings. Every finding includes a source citation (doc path and/or code file + line range).
+
+### What it does NOT do
+
+- It never modifies, creates, or deletes files
+- It never invents feature descriptions or fills in missing content
+- To fix findings, use the **technical-writer skill** or ask Claude to switch modes
+
+---
+
 ## Repository Structure
 
 ```
 docs/                    # Primary documentation pages
+versioned_docs/          # Archived versions
 src/                     # Docusaurus theme customizations
 static/                  # Images and static assets
 sidebars.js              # Navigation structure