diff --git a/.github/workflows/ci_local.yml b/.github/workflows/ci_local.yml
index c23365e..856636f 100644
--- a/.github/workflows/ci_local.yml
+++ b/.github/workflows/ci_local.yml
@@ -51,3 +51,22 @@ jobs:
         run: |
           go test -race -coverprofile=coverage.out -covermode=atomic ./...
           go tool cover -func=coverage.out | tail -1
+
+  module-sync:
+    name: Module Sync Check
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Checkout code
+        uses: actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7.0.0
+        with:
+          persist-credentials: false
+
+      - name: Verify module copies match sources
+        run: |
+          diff -r skills/mcp-setup module/skills/mcp-setup
+          diff -r skills/audit-pipeline module/skills/audit-pipeline
+          diff -r skills/pack-assessment module/skills/pack-assessment
+          diff .opencode/commands/comply-setup.md module/commands/comply-setup.md
+          diff .opencode/commands/comply-pipeline.md module/commands/comply-pipeline.md
+          diff .opencode/commands/comply-pack.md module/commands/comply-pack.md
diff --git a/INSTALL.md b/INSTALL.md
index 424a0c1..a09bade 100644
--- a/INSTALL.md
+++ b/INSTALL.md
@@ -189,6 +189,30 @@ Or use the setup command to generate it interactively:
 | `/comply-pack`     | Generate Rego policies from the child policy         |
 | `/comply-pipeline` | Run the comply pipeline (scoping, mapping, adherence)|
 
+## Lola (any AI assistant)
+
+Install the complypack module with [lola](https://lobstertrap.org/lola/):
+
+```bash
+lola mod add https://github.com/complytime/complypack.git
+lola install complypack -a opencode --scope project
+```
+
+This installs skills and commands into `.opencode/skills/` and
+`.opencode/commands/`. After installation, the `/comply-setup`,
+`/comply-pipeline`, and `/comply-pack` commands are available in OpenCode.
+
+To update after complypack releases new skills:
+
+```bash
+lola mod update complypack
+lola install complypack -a opencode --scope project
+```
+
+> **Note:** The MCP server still requires separate configuration. Run
+> `/comply-setup` after installation to generate the MCP config, or
+> edit `mcps.json` manually with your registry and schema values.
+
 ## SELinux (Fedora / RHEL)
 
 On systems with SELinux enforcing, volume mounts require the `:z` suffix so
diff --git a/Taskfile.yml b/Taskfile.yml
index 2a72f27..1852178 100644
--- a/Taskfile.yml
+++ b/Taskfile.yml
@@ -13,6 +13,29 @@ tasks:
     generates:
       - json-schema/*.json
 
+  sync-module:
+    desc: Copy skills and commands into module/ for lola distribution
+    cmds:
+      - rm -rf module/skills/mcp-setup module/skills/audit-pipeline module/skills/pack-assessment
+      - rm -f module/commands/comply-setup.md module/commands/comply-pipeline.md module/commands/comply-pack.md
+      - mkdir -p module/skills module/commands
+      - cp -r skills/mcp-setup module/skills/mcp-setup
+      - cp -r skills/audit-pipeline module/skills/audit-pipeline
+      - cp -r skills/pack-assessment module/skills/pack-assessment
+      - cp .opencode/commands/comply-setup.md module/commands/comply-setup.md
+      - cp .opencode/commands/comply-pipeline.md module/commands/comply-pipeline.md
+      - cp .opencode/commands/comply-pack.md module/commands/comply-pack.md
+
+  check-module-sync:
+    desc: Verify module/ skills and commands match their sources
+    cmds:
+      - diff -r skills/mcp-setup module/skills/mcp-setup
+      - diff -r skills/audit-pipeline module/skills/audit-pipeline
+      - diff -r skills/pack-assessment module/skills/pack-assessment
+      - diff .opencode/commands/comply-setup.md module/commands/comply-setup.md
+      - diff .opencode/commands/comply-pipeline.md module/commands/comply-pipeline.md
+      - diff .opencode/commands/comply-pack.md module/commands/comply-pack.md
+
   default:
     cmds:
       - task: generate-schemas
diff --git a/docs/adr/018-lola-module-distribution.md b/docs/adr/018-lola-module-distribution.md
new file mode 100644
index 0000000..5f8362f
--- /dev/null
+++ b/docs/adr/018-lola-module-distribution.md
@@ -0,0 +1,57 @@
+# ADR 018: Lola Module for Skill Distribution
+
+**Status:** Proposed
+
+**Date:** 2026-07-13
+
+**Context:**
+
+Complypack provides AI coding assistants with compliance pipeline skills (audit-pipeline, mcp-setup, pack-assessment) and slash commands (comply-setup, comply-pipeline, comply-pack). These artifacts are authored in two canonical locations:
+
+- `skills/` — skill definitions (markdown with frontmatter)
+- `.opencode/commands/` — slash command definitions
+
+Consumer repositories need these skills and commands installed into their own tool-specific directories. Before this change, the only installation path was manual: clone the repo, copy files into the right directories, and repeat on every update. Tool-specific plugin directories (`.claude-plugin/`, `.cursor-plugin/`, `gemini-extension.json`) reference `skills/` directly but only work within the complypack repository itself.
+
+[Lola](https://lobstertrap.org/lola/concepts/skills-and-modules/) provides a standard layout (`module/`) and install command (`lola install`) for distributing AI coding assistant artifacts across repositories. It currently supports OpenCode as the install target.
+
+The challenge is maintaining two sets of files — canonical sources and distributable copies — without them silently drifting apart.
+
+**Decision:**
+
+Add a `module/` directory following the lola AI Context Module layout. Module files are exact copies of their canonical sources, not symlinks, because lola requires a self-contained directory that it can copy into consumer repositories.
+
+**Drift prevention** uses two Taskfile targets:
+
+1. **`task sync-module`** — copies canonical sources into `module/`. Run by contributors after editing canonical files.
+2. **`task check-module-sync`** — diffs module copies against sources, exits non-zero on divergence. A `Module Sync Check` job in `ci_local.yml` runs this on every push and PR, preventing drift from reaching `main`.
+
+A pre-commit hook to automate step 1 is tracked separately.
+
+**`mcps.json` version strategy:** The module includes a `mcps.json` with `VERSION` placeholders rather than a pinned release tag or a floating tag like `latest`/`main`. Floating tags were rejected per the constitution's container standards ("MUST use a specific base image tag or digest. MUST NOT use `latest` or floating tags"). Pinning a release tag would go stale on next release. The `mcp-setup` skill handles interactive version resolution at runtime, so the placeholder is the honest representation — users run `/comply-setup` or substitute the version manually.
+
+**Command scope:** Only the three `/comply-*` commands (comply-setup, comply-pipeline, comply-pack) are included. The `review-pr.md` command (a general-purpose PR review workflow) is excluded because it is not a compliance command and consumer repos may have their own review workflows.
+
+**Module `AGENTS.md` scope:** The module's `AGENTS.md` is a consumer-facing overview — what complypack is, what the skills do, the pipeline flow, and how to invoke commands. It does not reuse the root `AGENTS.md`, which contains contributor-focused architecture notes (domain packages, transport layers, testing split) that are irrelevant to consumers.
+
+The existing tool-specific integrations (`.claude-plugin/`, `.cursor-plugin/`, `.opencode/skills/` symlinks, `gemini-extension.json`) remain unchanged. The `.opencode/skills/` symlinks serve local complypack development — they point back to `skills/` at the repo root so OpenCode discovers the skills when working on this repo. They are not part of any distribution mechanism.
+
+**Consequences:**
+
+**Benefits:**
+
+- Consumer repos install with `lola mod add` + `lola install` instead of manual file copying
+- CI catches drift between canonical sources and module copies before merge
+- Existing tool integrations are unaffected (backwards compatible)
+- Canonical sources remain the single source of truth
+
+**Drawbacks:**
+
+- Every canonical file has an exact copy in `module/`, increasing maintenance surface
+- Contributors must run `task sync-module` after editing canonical files (until pre-commit hook is added)
+- Lola currently supports OpenCode only; other tools still require their own plugin directories
+
+**Related:**
+
+- ADR 012: Container-Based MCP Server Distribution
+- ADR 015: Comply Pipeline as Plugin Skills
diff --git a/module/AGENTS.md b/module/AGENTS.md
new file mode 100644
index 0000000..3229dce
--- /dev/null
+++ b/module/AGENTS.md
@@ -0,0 +1,45 @@
+# ComplyPack
+
+ComplyPack provides AI coding assistants with compliance pipeline skills
+and an MCP server for working with [Gemara](https://github.com/gemaraproj)
+control catalogs.
+
+## MCP Server
+
+The complypack MCP server serves Gemara artifacts (catalogs, policies,
+mappings) and provides tools for policy validation, assessment triage,
+and parameter analysis. Configure it via `/comply-setup` or manually
+in your tool's MCP configuration. See `mcps.json` for the base template.
+
+## Skills
+
+| Skill | Trigger | Purpose |
+|-------|---------|---------|
+| `mcp-setup` | User wants to configure MCP servers | Interactive setup wizard for complypack and gemara MCP servers |
+| `audit-pipeline` | User wants to build compliance artifacts or prepare for audit | Three-stage pipeline: scoping, mapping, adherence |
+| `pack-assessment` | User mentions Rego, Conftest, OPA, or policy generation | Generate Rego policies from Gemara catalogs |
+
+### Pipeline Flow
+
+```
+scoping -> mapping -> adherence -> pack-assessment
+```
+
+1. **Scoping** -- Characterize the system, scope control catalogs, identify gaps
+2. **Mapping** -- Crosswalk frameworks, harmonize parameters across layers
+3. **Adherence** -- Compile a Gemara Policy with assessment plans
+4. **Pack** -- Generate Rego policies for automated assessment plans
+
+## Commands
+
+| Command | Description |
+|---------|-------------|
+| `/comply-setup` | Configure complypack MCP server for this project |
+| `/comply-pipeline` | Run the comply pipeline (scoping, mapping, adherence) |
+| `/comply-pack` | Generate Rego policies from the child policy |
+
+## Safety
+
+All control IDs, requirement IDs, and parameter values MUST come from MCP
+resources. Skills enforce this constraint to prevent hallucinated policy
+content. The MCP server is the single source of truth.
diff --git a/module/commands/comply-pack.md b/module/commands/comply-pack.md
new file mode 100644
index 0000000..4d91537
--- /dev/null
+++ b/module/commands/comply-pack.md
@@ -0,0 +1,6 @@
+---
+description: Generate Rego policies from the child policy
+---
+
+Load the `pack` skill and execute it. Read `.complytime/child-policy.yaml`
+for the assessment plans to generate Rego policies from.
diff --git a/module/commands/comply-pipeline.md b/module/commands/comply-pipeline.md
new file mode 100644
index 0000000..494e3c4
--- /dev/null
+++ b/module/commands/comply-pipeline.md
@@ -0,0 +1,6 @@
+---
+description: Run the comply pipeline (scoping, mapping, adherence)
+---
+
+Load the `pipeline` skill and execute it. Check `.complytime/` for existing
+artifacts to determine which stage to resume from.
diff --git a/module/commands/comply-setup.md b/module/commands/comply-setup.md
new file mode 100644
index 0000000..5d12187
--- /dev/null
+++ b/module/commands/comply-setup.md
@@ -0,0 +1,6 @@
+---
+description: Configure complypack MCP server for this project
+---
+
+Load the `setup` skill and execute it. Generate `.mcp.json` with the
+complypack MCP server configuration for the current project.
diff --git a/module/mcps.json b/module/mcps.json
new file mode 100644
index 0000000..4a58515
--- /dev/null
+++ b/module/mcps.json
@@ -0,0 +1,14 @@
+{
+  "mcpServers": {
+    "complypack": {
+      "command": "podman",
+      "args": [
+        "run", "--rm", "-i",
+        "ghcr.io/complytime/complypack:VERSION",
+        "mcp", "serve",
+        "--source", "oci://YOUR_REGISTRY/YOUR_CATALOG:VERSION",
+        "--schema", "YOUR_PLATFORM"
+      ]
+    }
+  }
+}
diff --git a/module/skills/audit-pipeline/SKILL.md b/module/skills/audit-pipeline/SKILL.md
new file mode 100644
index 0000000..edb811a
--- /dev/null
+++ b/module/skills/audit-pipeline/SKILL.md
@@ -0,0 +1,52 @@
+---
+name: audit-pipeline
+description: Use when user wants to build Gemara Policy artifacts for audit preparation or compliance program setup
+---
+
+# /comply:audit-pipeline — ComplyTime Audit Pipeline
+
+Guide users through building a Gemara Policy (applicability statement) from their system architecture and governance sources. The Gemara Policy is the formal contract between audit and engineering, functionally equivalent to an ISO 27001 Statement of Applicability or a NIST System Security Plan.
+
+## Safety
+
+**CRITICAL:** Every stage MUST read control IDs, requirement IDs, and parameter values from MCP resources. DO NOT generate these from memory. The MCP server is the source of truth.
+
+## Pipeline Stages
+
+| Stage     | Artifact                          | Purpose                                                          |
+|-----------|-----------------------------------|------------------------------------------------------------------|
+| scoping   | `.complytime/scoping.yaml`        | System profile + Control Catalog scoping + gap analysis          |
+| mapping   | `.complytime/delta-report.yaml`   | Parameter delta analysis + harmonization across framework layers |
+| adherence | `.complytime/child-policy.yaml`   | Compile the child Policy with adherence plan                     |
+
+After adherence, invoke `/comply:pack-assessment` to generate assessment logic for use with `complyctl`.
+
+## Router Logic
+
+1. Check if `.complytime/` directory exists and which artifacts are present
+2. Determine pipeline state:
+   - No `.complytime/` directory → start at **scoping**
+   - `scoping.yaml` exists but no `delta-report.yaml` → offer **mapping**
+   - `delta-report.yaml` exists but no `child-policy.yaml` → offer **adherence**
+   - `child-policy.yaml` exists → pipeline complete, offer to re-run any stage or proceed to `/comply:pack-assessment`
+3. If the user specified a stage, validate prerequisites:
+   - **mapping** requires `scoping.yaml`
+   - **adherence** requires `delta-report.yaml`
+4. Dispatch to the appropriate stage skill
+
+## Dispatching
+
+Read the stage instructions from this skill's base directory before proceeding:
+
+- **scoping** → `scoping.md`
+- **mapping** → `mapping.md`
+- **adherence** → `adherence.md`
+
+## Status Display
+
+```text
+/comply:audit-pipeline status:
+  [done] scoping     — .complytime/scoping.yaml
+  [done] mapping     — .complytime/delta-report.yaml
+  [next] adherence   — not yet run
+```
diff --git a/module/skills/audit-pipeline/adherence.md b/module/skills/audit-pipeline/adherence.md
new file mode 100644
index 0000000..85e7519
--- /dev/null
+++ b/module/skills/audit-pipeline/adherence.md
@@ -0,0 +1,195 @@
+---
+name: adherence
+description: Populate a Gemara Policy defining what controls apply, with what parameter values, and how evidence will be collected
+user-invocable: false
+---
+
+# Adherence — Compile Policy
+
+Compile or alter a Gemara Policy artifact. Declares what controls apply, with exact parameter values, and defines the adherence plan: frequency, evaluation method, and evidence requirements.
+
+Evidence collection and Evaluation Logs are produced by `complyctl` at runtime.
+
+## Prerequisites
+
+- `.complytime/scoping.yaml`
+- `.complytime/delta-report.yaml`
+
+Verify all parameters are resolved (no `pending_user_decision`). If unresolved, tell the user to re-run mapping.
+
+## Process
+
+### Step 1: Read Input Artifacts
+
+Read both `.complytime/scoping.yaml` and `.complytime/delta-report.yaml`.
+
+### Step 2: Build Mapping References
+
+From the delta report's `sources`, build `mapping_references`:
+- One for the parent Policy
+- One for each scoped Control Catalog
+- One for each Guidance Catalog for the target framework
+
+> **Critical:** Set `mapping-reference.id` to match the referenced
+> artifact's `metadata.id` exactly (e.g., `container-security-controls`,
+> not `csc`). ComplyPack resolves policy imports by matching these IDs
+> against loaded sources. Short aliases pass Gemara schema validation but
+> fail at complypack runtime with:
+> `failed to resolve effective policy: no imports could be resolved`
+
+### Step 3: Build Imports
+
+- `imports.catalogs` — one per Control Catalog
+- `imports.guidance` — one per mandated Guidance Catalog
+
+### Step 4: Build Assessment Plans
+
+#### 4a: Identify the trusted evaluator
+
+Ask the user: "Who is the trusted evaluator for automated assessments?" Read `complypack://evaluator` to see available evaluators. Collect:
+- `id` — evaluator plugin identifier
+- `name` — display name
+- `type` — `Software`
+- `version` — evaluator version
+
+This becomes the **default** executor for all automated plans, set as a global evaluation method on `adherence.evaluation-methods`. Individual assessment plans can override this with their own `evaluation-methods` and `executor` when a specific requirement needs a different evaluator or mode.
+
+#### 4b: Triage requirements by automation eligibility
+
+Call `get_applicability_groups` to retrieve the catalog's applicability group definitions and see which requirements belong to each group. Use the group titles and descriptions to identify which group designates automation-eligible requirements.
+
+- **Automatable** (requirement belongs to the automation-eligible group): assessment plan inherits the global `mode: Automated` and executor — no per-plan `evaluation-methods` needed unless overriding
+- **Not automatable**: assessment plan overrides with per-plan `evaluation-methods` set to `mode: Manual`, no executor
+- **No applicability groups in catalog**: ask the user to classify each requirement as automated or manual
+
+The user may also override any individual plan's evaluation method and executor. Present the triage results and ask if any plans need a different evaluator or mode before compiling.
+
+#### 4c: Build each plan
+
+Group by `requirement-id`. Each plan:
+- `id` — unique plan identifier
+- `requirement-id` — the assessment requirement this plan addresses
+- `frequency` (e.g., "30d", "90d", "365d")
+- `evaluation-methods` — only when overriding the global default (e.g., manual plans or plans with a different executor)
+- `evidence-requirements` — what evidence is collected
+- `parameters` — frozen values from harmonization, each with `id`, `label`, `accepted-values`, `description`
+
+### Step 5: Compile the Policy
+
+```yaml
+title: "<System Name> Policy"
+metadata:
+  id: <system-name>-policy
+  gemara-version: v1.0.0
+  type: Policy
+  description: "<system description>"
+  author:
+    id: <author-id>
+    name: <author-name>
+    type: Software Assisted
+  mapping-references:
+    - id: <ref-id>
+      title: "<reference title>"
+      version: "<version>"
+contacts:
+  responsible:
+    - name: "<contact name>"
+  accountable:
+    - name: "<contact name>"
+scope:
+  in:
+    technologies:
+      - <technology from system profile>
+    groups:
+      - <applicability group, e.g. maturity-1, maturity-2>
+imports:
+  catalogs:
+    - reference-id: <ref-id>
+  guidance:
+    - reference-id: <ref-id>
+adherence:
+  # Global default: applies to all plans unless overridden
+  evaluation-methods:
+    - id: default-eval
+      type: Behavioral
+      mode: Automated
+      executor:
+        id: <evaluator-id>
+        name: <evaluator-name>
+        type: Software
+        version: "<evaluator-version>"
+  assessment-plans:
+    # Automated plan — inherits global evaluation-methods and executor
+    - id: <plan-id>
+      requirement-id: "<req-id>"
+      frequency: "<cadence>"
+      evidence-requirements: "<what>"
+      parameters:
+        - id: <param-id>
+          label: "<label>"
+          accepted-values: ["<value>"]
+          description: "<rationale>"
+    # Manual plan — overrides global with per-plan evaluation-methods
+    - id: <plan-id-manual>
+      requirement-id: "<req-id-manual>"
+      frequency: "<cadence>"
+      evaluation-methods:
+        - id: manual-review
+          type: Intent
+          mode: Manual
+      evidence-requirements: "<what>"
+    # Plan with different executor — overrides global with per-plan executor
+    - id: <plan-id-custom>
+      requirement-id: "<req-id-custom>"
+      frequency: "<cadence>"
+      evaluation-methods:
+        - id: custom-eval
+          type: Behavioral
+          mode: Automated
+          executor:
+            id: <other-evaluator-id>
+            name: <other-evaluator-name>
+            type: Software
+            version: "<other-evaluator-version>"
+      evidence-requirements: "<what>"
+```
+
+Use `scope.in.groups` for applicability groups from the scoping stage (e.g., maturity levels, risk tiers). This scopes the policy to only the controls that match those groups.
+
+### Step 6: Validate
+
+Write `.complytime/child-policy.yaml`. If the Gemara MCP server is available, validate against the schema with the Policy definition.
+
+### Step 7: Present Summary
+
+Show mapping references, imported catalogs/guidance, and the automation split:
+
+```text
+Policy written to .complytime/child-policy.yaml
+
+Assessment plans: 12 total
+  Automated (evaluator: <evaluator-name>): 8 requirements
+  Manual: 4 requirements
+
+Invoke /comply:pack-assessment to generate assessment logic for the 8 automated requirements.
+```
+
+## MCP Resources and Tools
+
+- `complypack://catalog/*` — Control Catalogs, Guidance Catalogs, Policies
+- `get_assessment_requirements` — get requirement details and parameters for building assessment plans
+- `get_applicability_groups` — get applicability group definitions and requirement memberships for automation triage
+
+**DO NOT parse local YAML files to extract control data.** Use `get_assessment_requirements` and `get_applicability_groups` for requirement data and group classification. All control data MUST come from MCP resources or tools.
+
+## Red Flags
+
+- [ ] Any unresolved parameters?
+- [ ] Every mapping reference has a corresponding import?
+- [ ] Every assessment plan has frequency and evaluation method?
+- [ ] Every value came from MCP or the delta report?
+- [ ] Did you use `get_assessment_requirements`, not parse files?
+- [ ] Did you use `get_applicability_groups` to check automation eligibility?
+- [ ] Does `adherence.evaluation-methods` have an executor with the user-identified trusted evaluator?
+- [ ] Did you ask the user to identify the trusted evaluator?
+- [ ] Did you present the triage results and ask if any plans need a different evaluator or mode?
diff --git a/module/skills/audit-pipeline/mapping.md b/module/skills/audit-pipeline/mapping.md
new file mode 100644
index 0000000..e6f6591
--- /dev/null
+++ b/module/skills/audit-pipeline/mapping.md
@@ -0,0 +1,128 @@
+---
+name: mapping
+description: Crosswalk frameworks and perform parameter harmonization. Parent Policy always sets the floor.
+user-invocable: false
+---
+
+# Mapping — Delta Analysis & Parameter Harmonization
+
+Compare parameters across Guidance Catalogs, the parent Policy, and Control Catalogs. Surface where the organization's values match or differ from each framework. Interpret the relationship using domain context — the tool gathers, the model judges.
+
+**Core invariant:** The parent Policy always sets the floor. Never resolve below it without explicit user acknowledgement.
+
+## Prerequisites
+
+Requires `.complytime/scoping.yaml` from the scoping stage.
+
+## Key Concepts
+
+### Mandated vs. Under Evaluation
+
+The parent Policy's `imports.guidance` determines which frameworks are binding:
+
+- **Mandated:** Guidance Catalogs imported by the parent Policy. Shortfalls MUST be addressed.
+- **Under evaluation:** Guidance Catalogs loaded in MCP but NOT imported. Informational only.
+
+## Process
+
+### Step 1: Read Scoping Artifacts
+
+Read `.complytime/scoping.yaml`.
+
+### Step 2: Identify Parent Policy
+
+```text
+ListMcpResourcesTool(server="complypack")
+```
+
+Look for resources with "Policy" in the name. If a Policy exists, read it. **If no parent Policy exists:** extract minimums from the target framework's Control Catalog requirements. The framework becomes the floor.
+
+### Step 3: Classify Guidance Frameworks
+
+If a parent Policy exists, check `imports.guidance`. If not, all Guidance Catalogs are **under evaluation** unless the user designates one as the target.
+
+### Step 4: Load Mapping Documents
+
+Read any Mapping Documents recorded in scoping:
+
+```text
+ReadMcpResourceTool(server="complypack", uri="complypack://mapping/<id>")
+```
+
+Use them to resolve framework crosswalks.
+
+### Step 5: Gather Parameter Comparisons
+
+```text
+CallMcpToolTool(server="complypack", tool="analyze_parameter_delta", arguments={"policyName": "<policy-name>"})
+```
+
+This returns structured L3 parameter values from the Policy alongside the L1/L2 requirement text they map to. Each comparison contains:
+- `requirement_id` — which requirement the parameter maps to
+- `label` — the parameter name
+- `policy_value` — the structured value from the Policy
+- `requirement_text` — the prose from the catalog
+
+**The tool does not judge the relationship.** You interpret each pair using domain context.
+
+### Step 6: Present Results
+
+For each comparison, interpret the relationship:
+- Do the values align?
+- Does the requirement text express a concrete expectation the policy value satisfies?
+- Does the policy set a stricter threshold than the requirement implies?
+- Is the requirement generic ("per organizational requirements") and the policy provides a concrete binding?
+
+**Mandated frameworks:** present your interpretation and recommended action.
+
+**Under evaluation:** same analysis, framed as "if you pursue this certification..."
+
+### Step 7: Resolve Decisions
+
+Walk the user through items where values differ. For each, present both the policy value and the requirement text, explain your interpretation, and let the user decide.
+
+### Step 8: Write Output
+
+Write `.complytime/delta-report.yaml`:
+
+```yaml
+version: "1"
+created: YYYY-MM-DD
+sources:
+  parent_policy: "<policy-id>"
+  guidance:
+    mandated:
+      - id: "<id>"
+        status: imported_by_parent
+    under_evaluation:
+      - id: "<id>"
+        status: loaded_not_imported
+  catalogs: [<ids>]
+
+comparisons:
+  - requirement_id: "<req-id>"
+    label: "<label>"
+    policy_value: "<value>"
+    policy_source: "<policy-id>"
+    requirement_text: "<text>"
+    catalog_source: "<catalog-id>"
+    interpretation: "<your assessment>"
+    resolution: "<user decision>"
+```
+
+## MCP Resources and Tools
+
+- `complypack://catalog/*` — Control Catalogs, Guidance Catalogs, Policies
+- `complypack://mapping/*` — Mapping Documents
+- `analyze_parameter_delta` — gather L3 parameter values alongside L1/L2 requirement text
+- `get_assessment_requirements` — get requirement details, supports scope filtering
+
+**DO NOT parse local YAML files to extract control data.** All control IDs, requirement IDs, requirement text, and parameter values MUST come from MCP resources or tools.
+
+## Red Flags
+
+- [ ] Did you classify guidance as mandated vs. under evaluation?
+- [ ] Did the user decide every item where values differ?
+- [ ] Did you ensure no resolution goes below the parent Policy floor?
+- [ ] Did every value come from MCP?
+- [ ] Did you use `analyze_parameter_delta` to gather comparisons, not parse files?
diff --git a/module/skills/audit-pipeline/scoping.md b/module/skills/audit-pipeline/scoping.md
new file mode 100644
index 0000000..b54dca2
--- /dev/null
+++ b/module/skills/audit-pipeline/scoping.md
@@ -0,0 +1,130 @@
+---
+name: scoping
+description: Characterize a system's component stack, scope existing Control Catalogs, and identify coverage gaps
+user-invocable: false
+---
+
+# Scoping
+
+Characterize the system, identify its technology component stack, and scope which existing Control Catalogs apply. Produces `.complytime/scoping.yaml`.
+
+## Modes
+
+- **Conversational:** Ask structured questions one at a time.
+- **Document ingestion:** Extract and normalize from existing SAR, architecture doc, deployment manifest, or IaC.
+- **Hybrid:** Fill gaps with targeted questions.
+
+## Process
+
+### Step 1: Characterize the System
+
+1. **Identity:** Name, description, purpose, criticality
+2. **Data classification:** public, internal, confidential, restricted
+3. **Component stack:** Name, type, runtime/engine, image/version
+4. **Data flows:** Source → destination, protocol, data types
+5. **Deployment:** Cloud/on-prem/hybrid, provider, regions
+6. **Boundaries:** DMZ, internal, external-facing components
+
+### Step 2: Scope Control Catalogs
+
+Query MCP for available Control Catalogs:
+
+```text
+ListMcpResourcesTool(server="complypack")
+```
+
+Map each component to an existing Control Catalog. No matching catalog → record as a **gap**.
+
+### Step 3: Filter by Applicability Group
+
+If the user specified a scoping level (e.g., maturity level, risk tier), use `get_assessment_requirements` with the `scope` parameter to get only the requirements that apply.
+
+**Important:** The `catalogName` parameter takes a **policy name**, not a catalog name. The policy resolves its imported catalogs internally. Find the policy name from `ListMcpResourcesTool` output — look for resources with `kind: Policy`.
+
+```text
+CallMcpToolTool(server="complypack", tool="get_assessment_requirements", arguments={"catalogName": "<policy-name>", "scope": ["<applicability-group>"]})
+```
+
+For example, for OSPS Baseline at Maturity Level 2 with a policy named `example-foundation-policy`:
+
+```text
+CallMcpToolTool(server="complypack", tool="get_assessment_requirements", arguments={"catalogName": "example-foundation-policy", "scope": ["maturity-1", "maturity-2"]})
+```
+
+This returns only the requirements whose applicability includes the target level. Use this filtered set for the rest of the pipeline — do NOT manually read and parse the catalog to determine which controls apply.
+
+### Step 4: Check for Mapping Documents
+
+Ask the user if they have Gemara Mapping Documents. Check MCP:
+
+```text
+ListMcpResourcesTool(server="complypack")
+```
+
+Record any available Mapping Documents — the mapping stage will use them.
+
+### Step 5: Identify Gaps
+
+For each component with no matching Control Catalog:
+- Record the component, its type, and engine
+- Recommend: "Control Catalog needed for this technology, or accept risk"
+
+### Step 6: Confirm with User
+
+Present findings. Ask user to confirm or adjust before writing.
+
+### Step 7: Write Output
+
+Write `.complytime/scoping.yaml`:
+
+```yaml
+version: "1"
+created: YYYY-MM-DD
+system:
+  name: "<name>"
+  description: "<description>"
+  criticality: <high|medium|low>
+  data_classification: <public|internal|confidential|restricted>
+  components:
+    - name: "<name>"
+      type: <container|database|cache|api-gateway|model-server|...>
+      runtime: "<runtime>"
+  data_flows:
+    - from: "<source>"
+      to: "<destination>"
+      protocol: <tls|mtls|plaintext>
+      data_types: [<types>]
+  deployment:
+    model: <cloud|on-prem|hybrid>
+    provider: "<provider>"
+    regions: [<regions>]
+
+catalog_scope:
+  covered:
+    - catalog_id: "<id>"
+      components: [<names>]
+      reason: "<why>"
+  gaps:
+    - component: "<name>"
+      type: "<type>"
+      finding: "No Control Catalog available"
+
+mapping_documents:
+  - id: "<id>"
+    source: "<where found>"
+```
+
+## MCP Resources and Tools
+
+- `complypack://catalog/*` — Control Catalogs, Guidance Catalogs, Policies
+- `complypack://mapping/*` — Mapping Documents
+- `get_assessment_requirements` — get requirement details and parameters for a specific control or in batch
+
+**DO NOT parse local YAML files to extract control data.** All control IDs, requirement IDs, requirement text, and parameter values MUST come from MCP resources or tools.
+
+## Red Flags
+
+- [ ] Did you query MCP for catalogs, not assume them?
+- [ ] Did you use `get_assessment_requirements` for requirement details, not parse files?
+- [ ] Did you record gaps?
+- [ ] Did you confirm with the user before writing?
diff --git a/module/skills/mcp-setup/SKILL.md b/module/skills/mcp-setup/SKILL.md
new file mode 100644
index 0000000..355df1f
--- /dev/null
+++ b/module/skills/mcp-setup/SKILL.md
@@ -0,0 +1,190 @@
+---
+name: mcp-setup
+description: Configure the Gemara and complypack MCP servers for this project — set up artifact sources, platform schemas, and generate the .mcp.json config
+---
+
+# /comply:mcp-setup — Configure MCP Servers
+
+Set up the Gemara MCP server and the complypack MCP server for this project.
+
+## MCP Servers
+
+| Server         | Purpose                              | Provides                                                                                                                                                                                                                   |
+| -------------- | ------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| **gemara**     | Authoring and validation             | `gemara://lexicon`, `gemara://schema/definitions`, `validate_gemara_artifact`                                                                                                                                              |
+| **complypack** | Artifact serving, policy validation  | `complypack://catalog/*`, `complypack://mapping/*`, `complypack://schema/*`, `validate_policy`, `test_policy`, `get_assessment_requirements`, `get_applicability_groups`, `get_automation_triage`, `analyze_parameter_delta` |
+
+## Process
+
+### Step 1: Detect Tool Environment
+
+Determine which AI coding tool is running and adapt the output.
+
+First, scan for all recognized tool directories:
+
+- `.claude-plugin/` → Claude Code
+- `.opencode/` → OpenCode
+- `.cursor-plugin/` → Cursor
+
+**If multiple tool directories are found**: prompt the user to select their active tool before proceeding. Example:
+
+> Multiple AI coding tools detected in this repository:
+> 1. Claude Code (`.claude-plugin/`)
+> 2. OpenCode (`.opencode/`)
+>
+> Which tool are you using? (This affects the config file format and
+> post-setup guidance.)
+
+**If exactly one is found**: use it automatically.
+
+**If none are found**: fall back to Unknown.
+
+### Step 2: Check Existing Configuration
+
+Check if a config file already exists. The file depends on the tool environment:
+- Claude Code / Cursor: `.mcp.json`
+- OpenCode: `opencode.json` (or `opencode.jsonc`)
+
+Show current config and ask if the user wants to reconfigure.
+
+### Step 3: Detect Container Runtime
+
+Detect which container runtime is available on the host before generating
+any configuration.
+
+```bash
+command -v docker &> /dev/null && HAVE_DOCKER=true || HAVE_DOCKER=false
+command -v podman &> /dev/null && HAVE_PODMAN=true || HAVE_PODMAN=false
+```
+
+- If **only one** is found: use it automatically and set `RUNTIME` to
+  `docker` or `podman`.
+- If **both** are found: ask the user which they prefer and set `RUNTIME`
+  to their choice.
+- If **neither** is found: stop and inform the user that a container
+  runtime (`docker` or `podman`) is required. Do not proceed.
+
+Use `<RUNTIME>` in all subsequent steps wherever the container command
+appears.
+
+### Step 4: Configure Sources
+
+Ask for Gemara artifact sources for the complypack server:
+
+- `oci://registry.example.com/gemara/controls:v1`
+- `oci+http://localhost:5001/gemara/controls:v1` (development)
+- `file://path/to/catalog.yaml`
+
+At least one source is required.
+
+> **Volume mounts for `file://` sources:** When any source uses `file://`,
+> the Docker/Podman command must include `-v <host-path>:/workspace -w /workspace`
+> to mount the host directory into the container. Without this, the server
+> cannot access the file and will fail at startup. Relative `file://` paths
+> resolve from the container's working directory (`/workspace`).
+
+### Step 5: Configure Schemas
+
+Ask which platform schemas to load:
+
+- `ci-github-actions`, `ci-gitlab`, `ci-azure-pipelines` (built-in)
+- `kubernetes-deployment`, `kubernetes-pod`, etc. (built-in, per resource type)
+- `terraform=https://example.com/terraform.json` (custom, explicit source)
+
+### Step 6: Resolve Versions
+
+Look up latest release versions. Do NOT use `:latest` tags.
+
+- **gemara-mcp**: `gh api repos/gemaraproj/gemara-mcp/releases/latest --jq '.tag_name'`
+- **complypack**: `gh api repos/complytime/complypack/releases --jq '.[0].tag_name'`
+
+The complypack releases may be pre-releases, so use the first entry from the
+full releases list rather than the `releases/latest` endpoint.
+
+If no release exists, fall back to `:main`.
+
+#### Verify container image tag exists
+
+After resolving the version tag, verify the container image actually exists
+at that tag before using it:
+
+```bash
+<RUNTIME> manifest inspect ghcr.io/complytime/complypack:<VERSION> > /dev/null 2>&1
+```
+
+If the manifest check fails, the release tag does not have a corresponding
+container image. Fall back to `:main` and inform the user:
+
+> "No container image found for tag `<VERSION>`. Using `:main` instead.
+> The `:main` tag tracks the latest commit on the main branch."
+
+### Step 7: Write Configuration
+
+Apply the tool's setup steps:
+
+- **Claude Code**: Write `.mcp.json` (see below, `.mcp.json` format).
+- **OpenCode**: Write `opencode.json` (see below, `opencode.json` format).
+- **Cursor**: Write `.mcp.json` (see below, `.mcp.json` format).
+- **Unknown**: Write `.mcp.json` and inform the user about skill discovery.
+
+#### Claude Code / Cursor — `.mcp.json`
+
+```json
+{
+  "mcpServers": {
+    "gemara": {
+      "command": "<RUNTIME>",
+      "args": ["run", "--rm", "-i",
+               "ghcr.io/gemaraproj/gemara-mcp:<VERSION>",
+               "serve"]
+    },
+    "complypack": {
+      "command": "<RUNTIME>",
+      "args": ["run", "--rm", "-i",
+               "ghcr.io/complytime/complypack:<VERSION>",
+               "mcp", "serve",
+               "--source", "<SOURCE>",
+               "--schema", "<SCHEMA>"]
+    }
+  }
+}
+```
+
+#### OpenCode — `opencode.json`
+
+If `opencode.json` already exists, merge the `mcp` entries into it.
+If not, create a new file.
+
+```json
+{
+  "$schema": "https://opencode.ai/config.json",
+  "mcp": {
+    "gemara": {
+      "type": "local",
+      "command": ["<RUNTIME>", "run", "--rm", "-i",
+                  "ghcr.io/gemaraproj/gemara-mcp:<VERSION>",
+                  "serve"]
+    },
+    "complypack": {
+      "type": "local",
+      "command": ["<RUNTIME>", "run", "--rm", "-i",
+                  "ghcr.io/complytime/complypack:<VERSION>",
+                  "mcp", "serve",
+                  "--source", "<SOURCE>",
+                  "--schema", "<SCHEMA>"]
+    }
+  }
+}
+```
+
+> **Key differences:** OpenCode uses `opencode.json` with top-level key
+> `mcp` (not `mcpServers`). Each server has `"type": "local"` and
+> `command` is a single array (not split into `command` + `args`).
+
+### Step 8: Verify
+
+Check that each server starts and responds. Report loaded catalogs and schemas.
+
+**Claude Code**: Inform user to use `/comply:audit-pipeline` or `/comply:pack-assessment`.
+
+**OpenCode**: Inform user to use `/comply-pipeline` or `/comply-pack` (custom commands) or to ask "run the comply pipeline" (skill-based invocation).
diff --git a/module/skills/pack-assessment/SKILL.md b/module/skills/pack-assessment/SKILL.md
new file mode 100644
index 0000000..4264347
--- /dev/null
+++ b/module/skills/pack-assessment/SKILL.md
@@ -0,0 +1,84 @@
+---
+name: pack-assessment
+description: Use when user mentions Rego, Conftest, OPA, "generate policy", or "assessment logic" in the context of Gemara catalogs. Generates Rego policies from Gemara Control Catalogs for Kubernetes (Deployments, Pods, DaemonSets, StatefulSets, CronJobs, Jobs, Services, NetworkPolicies, Ingress, RBAC, ConfigMaps, Secrets), CI/CD pipelines (GitHub Actions, GitLab CI, Azure Pipelines), Conftest, or OPA
+---
+
+# /comply:pack-assessment — Rego Policy Generation and Assessment
+
+Generate Rego policies from Gemara Control Catalogs that enforce compliance requirements. Policies must be written to disk, validated against the target platform schema, and tested with sample inputs.
+
+**Core principle:** Read control definitions from source → Generate platform-specific policy → Write to disk → Verify it works.
+
+## Quick Reference
+
+| Step | Action | Output |
+| ---- | ------ | ------ |
+| 1. Scope | Call `get_automation_triage`, filter to automated plans | Requirement list |
+| 2. Read control | Get definition from catalog (MCP) | Control text, ID, title |
+| 3. Get parameters | Extract assessment requirements | Thresholds, values |
+| 4. Read schema | Get platform schema (MCP) | Platform schema |
+| 5. Choose format | Select evaluator output convention | Policy structure |
+| 6. Generate policy | Write Rego against schema contract | .rego file |
+| 7. Write to disk | Save to `policy/` | File on disk |
+| 8. Validate | Contract check then test | Pass/fail results |
+
+## Step 1: Scope — Filter to Automated Requirements
+
+Call `get_automation_triage` with the policy name to get the automation split:
+
+1. The tool returns `automated` and `manual` lists with requirement IDs, evaluation methods, and executor details
+2. Generate policies only for requirements in the `automated` list
+3. List `manual` requirements for the user — these need human review
+
+If no policy is loaded in the MCP server, proceed with all requested requirements.
+
+## Steps 2-5: Read and Prepare
+
+**DO NOT generate from general knowledge.** Always read the actual control text from MCP.
+
+1. **Read control** — get the definition from the catalog via MCP (`complypack://catalog/*`)
+2. **Get parameters** — call `get_assessment_requirements` to extract thresholds and accepted values
+3. **Read schema** — get the platform schema via MCP (`complypack://schema/*`)
+4. **Choose format** — select evaluator output convention (e.g., OPA `deny` rules for Conftest)
+
+## Step 6: Generate Policy — Reusability Rules
+
+Write policies against the platform schema contract, not sample inputs:
+
+- **Write `input.*` paths from the schema.** Read `complypack://schema/*` and use the paths it defines. Do NOT reverse-engineer paths from sample manifests in `targets/`.
+- **No hardcoded values from test data.** Do not embed names, image refs, step names, or other values from sample inputs. Use parameter values from `get_assessment_requirements` for thresholds and accepted values.
+- **One file per assessment requirement.** Name the file after the requirement (e.g., `run_as_nonroot.rego`).
+- **Identify the subject in denial messages.** Use fields from the schema that identify the resource being checked (e.g., `input.metadata.name` for Kubernetes, `input.name` for CI jobs). Do not hardcode expected values in messages.
+
+## Step 7: Write to Disk
+
+Save to `policy/` directory.
+
+## Step 8: Validate — Contract Check First
+
+1. Run `validate_policy` — confirm zero contract violations against the platform schema
+2. If contract violations: fix the `input.*` paths to match the schema. The schema is the source of truth, not test data.
+3. Run `test_policy` — confirm policy logic works with sample inputs
+
+## Safety
+
+**DO NOT generate from general knowledge.** Always read the actual control text from MCP.
+
+## MCP Resources and Tools
+
+- `complypack://catalog/*` — Control Catalogs, Guidance Catalogs, Policies
+- `complypack://schema/*` — Platform schemas
+- `complypack://evaluator` — Available evaluators
+- `get_automation_triage` — Classify assessment plans as Automated or Manual with executor details
+- `get_assessment_requirements` — Extract assessment requirements with parameters
+- `validate_policy` — Validate policy syntax and contract compliance
+- `test_policy` — Run policy tests against sample data
+
+## Red Flags - STOP AND FIX IF THERE ARE ISSUES
+
+- [ ] Does every `input.*` reference exist in the platform schema?
+- [ ] Are there hardcoded values from sample inputs that should be parameters?
+- [ ] Did you run `validate_policy` before `test_policy`?
+- [ ] Is each `.rego` file scoped to a single assessment requirement?
+- [ ] Did you read control text from MCP, not from general knowledge?
+- [ ] Did you call `get_automation_triage` to determine which plans are automated?
diff --git a/skills/mcp-setup/SKILL.md b/skills/mcp-setup/SKILL.md
index c922ccb..355df1f 100644
--- a/skills/mcp-setup/SKILL.md
+++ b/skills/mcp-setup/SKILL.md
@@ -16,7 +16,30 @@ Set up the Gemara MCP server and the complypack MCP server for this project.
 
 ## Process
 
-### Step 1: Check Existing Configuration
+### Step 1: Detect Tool Environment
+
+Determine which AI coding tool is running and adapt the output.
+
+First, scan for all recognized tool directories:
+
+- `.claude-plugin/` → Claude Code
+- `.opencode/` → OpenCode
+- `.cursor-plugin/` → Cursor
+
+**If multiple tool directories are found**: prompt the user to select their active tool before proceeding. Example:
+
+> Multiple AI coding tools detected in this repository:
+> 1. Claude Code (`.claude-plugin/`)
+> 2. OpenCode (`.opencode/`)
+>
+> Which tool are you using? (This affects the config file format and
+> post-setup guidance.)
+
+**If exactly one is found**: use it automatically.
+
+**If none are found**: fall back to Unknown.
+
+### Step 2: Check Existing Configuration
 
 Check if a config file already exists. The file depends on the tool environment:
 - Claude Code / Cursor: `.mcp.json`
@@ -24,7 +47,7 @@ Check if a config file already exists. The file depends on the tool environment:
 
 Show current config and ask if the user wants to reconfigure.
 
-### Step 2: Detect Container Runtime
+### Step 3: Detect Container Runtime
 
 Detect which container runtime is available on the host before generating
 any configuration.
@@ -44,7 +67,7 @@ command -v podman &> /dev/null && HAVE_PODMAN=true || HAVE_PODMAN=false
 Use `<RUNTIME>` in all subsequent steps wherever the container command
 appears.
 
-### Step 3: Configure Sources
+### Step 4: Configure Sources
 
 Ask for Gemara artifact sources for the complypack server:
 
@@ -60,7 +83,7 @@ At least one source is required.
 > cannot access the file and will fail at startup. Relative `file://` paths
 > resolve from the container's working directory (`/workspace`).
 
-### Step 4: Configure Schemas
+### Step 5: Configure Schemas
 
 Ask which platform schemas to load:
 
@@ -68,7 +91,7 @@ Ask which platform schemas to load:
 - `kubernetes-deployment`, `kubernetes-pod`, etc. (built-in, per resource type)
 - `terraform=https://example.com/terraform.json` (custom, explicit source)
 
-### Step 5: Resolve Versions
+### Step 6: Resolve Versions
 
 Look up latest release versions. Do NOT use `:latest` tags.
 
@@ -95,44 +118,15 @@ container image. Fall back to `:main` and inform the user:
 > "No container image found for tag `<VERSION>`. Using `:main` instead.
 > The `:main` tag tracks the latest commit on the main branch."
 
-### Step 6: Detect Tool Environment
-
-Determine which AI coding tool is running and adapt the output.
-
-First, scan for all recognized tool directories:
-
-- `.claude-plugin/` → Claude Code
-- `.opencode/` → OpenCode
-- `.cursor-plugin/` → Cursor
-
-**If multiple tool directories are found**: prompt the user to select their active tool before proceeding. Example:
-
-> Multiple AI coding tools detected in this repository:
-> 1. Claude Code (`.claude-plugin/`)
-> 2. OpenCode (`.opencode/`)
->
-> Which tool are you using? (This affects the config file format and
-> post-setup guidance.)
-
-**If exactly one is found**: use it automatically.
+### Step 7: Write Configuration
 
-**If none are found**: fall back to Unknown.
+Apply the tool's setup steps:
 
-Then apply the selected tool's setup steps:
-
-- **Claude Code**: Write `.mcp.json` (see Step 7, `.mcp.json` format).
-- **OpenCode**: Write `opencode.json` (see Step 7, `opencode.json` format). Verify that `.opencode/skills/` symlinks exist — if not, create them:
-  ```bash
-  mkdir -p .opencode/skills
-  ln -sf ../../skills/audit-pipeline .opencode/skills/audit-pipeline
-  ln -sf ../../skills/pack-assessment .opencode/skills/pack-assessment
-  ln -sf ../../skills/mcp-setup .opencode/skills/mcp-setup
-  ```
-- **Cursor**: Write `.mcp.json` (see Step 7, `.mcp.json` format).
+- **Claude Code**: Write `.mcp.json` (see below, `.mcp.json` format).
+- **OpenCode**: Write `opencode.json` (see below, `opencode.json` format).
+- **Cursor**: Write `.mcp.json` (see below, `.mcp.json` format).
 - **Unknown**: Write `.mcp.json` and inform the user about skill discovery.
 
-### Step 7: Write Configuration
-
 #### Claude Code / Cursor — `.mcp.json`
 
 ```json