fix(audit): seed the ledger in each narrow audit skill

context/skills/audit-attribution/references/4-report.md

@@ -4,7 +4,7 @@ next_step: null
 
 # Step 4 — Generate the audit report
 
-The audit report is rendered **directly from `.posthog-audit-checks.json`** — that file is the source of truth. Every check the wizard seeded for this skill ends up in the report, even passes; nothing is invented.
+The audit report is rendered **directly from `.posthog-audit-checks.json`** — that file is the source of truth. Every check Step 1 seeded ends up in the report, even passes; nothing is invented.
 
 ## Status
 

context/skills/audit-autocapture/description.md

@@ -11,7 +11,7 @@ The audit covers two lenses:
 
 The audit runs as a step chain. **The exact step list lives in the reference files themselves, not in this overview.** Step 1 lives at `references/1-presence.md`; each step file ends with a `next_step:` frontmatter pointer to the next, and the final step has `next_step: null`. Follow them in the order they point. You must resolve each step in order before any source-tree exploration.
 
-The audit ledger is seeded by the wizard with one pending check per autocapture check. **Each step gracefully handles a missing check id**: if a step's expected id is not in the ledger, it skips its `audit_resolve_checks` call for that id and continues. Use `mcp__wizard-tools__audit_resolve_checks` to patch each check as you finish it.
+Step 1 seeds the audit ledger itself with one pending check per autocapture check through `mcp__wizard-tools__audit_seed_checks`, because the runtime does not pre-seed this skill. **Each step gracefully handles a missing check id**: if a step's expected id is not in the ledger, it skips its `audit_resolve_checks` call for that id and continues. Use `mcp__wizard-tools__audit_resolve_checks` to patch each check as you finish it.
 
 **Start by reading the path relative to this file at `references/1-presence.md`.** Do not Glob, ls, or find the skill directory. Do not preload future steps. Do not re-read a step file once you've moved past it. Do not re-read SKILL.md.
 
@@ -33,6 +33,7 @@ The wizard intercepts these and updates the spinner. Use them freely — they ar
 
 The ledger lives at `.posthog-audit-checks.json` and is rendered live in the "Audit plan" tab. It is owned by MCP tools — **never `Write` this file directly**:
 
+- `mcp__wizard-tools__audit_seed_checks({ checks })` — writes the full pending checklist once at Step 1 and replaces the file atomically, so one call per run is safe.
 - `mcp__wizard-tools__audit_resolve_checks({ updates })` — patch one or more checks by `id`. Each `update` is `{ id, status, file?, details? }`. Batch updates from the same step into a single call.
 
 All audit ledger calls are atomic and serialize internally — **concurrent calls from parallel subagents cannot lose updates**, so feel free to fan out runtime checks across `Agent` subagents when a step says so.

context/skills/audit-autocapture/references/1-presence.md

@@ -12,6 +12,7 @@ Emit:
 
 ```
 [STATUS] Detecting PostHog autocapture configuration
+[STATUS] Seeding audit checklist
 ```
 
 ## Action
@@ -30,6 +31,27 @@ If init sites are found, `Read` each file once and inspect the init options for
 ## Decision
 
 - **Grep returns zero hits anywhere in the project:** emit `[ABORT] PostHog SDK initialization not found` and stop. The wizard catches `[ABORT]` and terminates the run.
+- **Init found:** seed the audit ledger, then continue based on the autocapture configuration.
+
+## Seed the audit ledger
+
+The runtime does not pre-seed this skill's ledger, so call `mcp__wizard-tools__audit_seed_checks` with the exact payload below. The tool replaces the file atomically, so one call at the start of every run is safe. Do not seed the ledger when this step aborts. Seeding is not resolving checks.
+
+```json
+{
+  "checks": [
+    { "id": "autocapture-intentional", "area": "Autocapture", "label": "Autocapture is explicitly configured", "status": "pending" },
+    { "id": "autocapture-mask-config", "area": "Autocapture", "label": "Autocapture PII masking stays enabled", "status": "pending" },
+    { "id": "autocapture-allowlists", "area": "Autocapture", "label": "Autocapture is scoped on high-traffic projects", "status": "pending" },
+    { "id": "autocapture-ratio-to-custom", "area": "Autocapture — Optimize", "label": "Autocapture and custom events have a healthy mix", "status": "pending" },
+    { "id": "autocapture-copied-text", "area": "Autocapture — Optimize", "label": "Copied text capture stays off on high-traffic sites", "status": "pending" },
+    { "id": "autocapture-dead-clicks-vs-heatmap", "area": "Autocapture — Optimize", "label": "Dead-click autocapture is off when heatmaps suffice", "status": "pending" }
+  ]
+}
+```
+
+## Continue
+
 - **Init found, `autocapture: false` is explicitly set on every init site:** autocapture is fully off. Resolve all three Step 2 fix checks (`autocapture-intentional`, `autocapture-mask-config`, `autocapture-allowlists`) in a single `audit_resolve_checks` call with `status: "pass"` and `details: "skip: autocapture explicitly disabled in init config"`. Then continue to Step 3 — optimize-side checks still have work to do for the dead-clicks and ratio checks.
 - **Init found, autocapture not fully disabled:** continue normally.
 

context/skills/audit-autocapture/references/4-report.md

@@ -4,7 +4,7 @@ next_step: null
 
 # Step 4 — Generate the audit report
 
-The audit report is rendered **directly from `.posthog-audit-checks.json`** — that file is the source of truth. Every check the wizard seeded for this skill ends up in the report, even passes; nothing is invented.
+The audit report is rendered **directly from `.posthog-audit-checks.json`** — that file is the source of truth. Every check Step 1 seeded ends up in the report, even passes; nothing is invented.
 
 ## Status
 

context/skills/audit-events/description.md

@@ -11,7 +11,7 @@ The audit covers two lenses:
 
 The audit runs as a step chain. **The exact step list lives in the reference files themselves, not in this overview.** Step 1 lives at `references/1-presence.md`; each step file ends with a `next_step:` frontmatter pointer to the next, and the final step has `next_step: null`. Follow them in the order they point. You must resolve each step in order before any source-tree exploration.
 
-The audit ledger is seeded by the wizard with one pending check per event check. **Each step gracefully handles a missing check id**: if a step's expected id is not in the ledger, it skips its `audit_resolve_checks` call for that id and continues. Use `mcp__wizard-tools__audit_resolve_checks` to patch each check as you finish it.
+Step 1 seeds the audit ledger itself with one pending check per event check through `mcp__wizard-tools__audit_seed_checks`, because the runtime does not pre-seed this skill. **Each step gracefully handles a missing check id**: if a step's expected id is not in the ledger, it skips its `audit_resolve_checks` call for that id and continues. Use `mcp__wizard-tools__audit_resolve_checks` to patch each check as you finish it.
 
 **Start by reading the path relative to this file at `references/1-presence.md`.** Do not Glob, ls, or find the skill directory. Do not preload future steps. Do not re-read a step file once you've moved past it. Do not re-read SKILL.md.
 
@@ -33,6 +33,7 @@ The wizard intercepts these and updates the spinner. Use them freely — they ar
 
 The ledger lives at `.posthog-audit-checks.json` and is rendered live in the "Audit plan" tab. It is owned by MCP tools — **never `Write` this file directly**:
 
+- `mcp__wizard-tools__audit_seed_checks({ checks })` — writes the full pending checklist once, at Step 1. The tool replaces the file atomically, so one call per run is safe.
 - `mcp__wizard-tools__audit_resolve_checks({ updates })` — patch one or more checks by `id`. Each `update` is `{ id, status, file?, details? }`. Batch updates from the same step into a single call.
 
 All audit ledger calls are atomic and serialize internally — **concurrent calls from parallel subagents cannot lose updates**, so feel free to fan out runtime checks across `Agent` subagents when a step says so.

context/skills/audit-events/references/1-presence.md

@@ -12,6 +12,7 @@ Emit:
 
 ```
 [STATUS] Detecting PostHog event capture usage
+[STATUS] Seeding audit checklist
 ```
 
 ## Action
@@ -27,6 +28,24 @@ Run **two `Grep` calls in parallel**, both with `output_mode: "files_with_matche
 - **Init found, capture not found:** continue. Step 2 (fix) will detect this and resolve its four ledger checks with skip details. Step 3 (optimize) still has work to do because pageview defaults and downstream usage may still matter.
 - **Both found:** continue normally.
 
+## Seed audit ledger
+
+The runtime does not pre-seed this skill's ledger, so call `mcp__wizard-tools__audit_seed_checks` here with the exact payload below. The tool replaces the file atomically, so one call at the start of every run is safe. Do not seed when this step aborts.
+
+```json
+{
+  "checks": [
+    { "id": "capture-event-names-static", "area": "Event Capture", "label": "Event names use static strings", "status": "pending" },
+    { "id": "event-naming-standardization", "area": "Event Capture", "label": "Event names follow a consistent convention", "status": "pending" },
+    { "id": "event-duplicates-and-bloat", "area": "Event Capture", "label": "Event captures have no duplicates or bloat", "status": "pending" },
+    { "id": "event-quality-context-review", "area": "Event Capture", "label": "Event captures contain no material quality issues", "status": "pending" },
+    { "id": "event-usage-coverage", "area": "Event Capture — Optimize", "label": "Captured events are used in PostHog artifacts", "status": "pending" },
+    { "id": "events-pageview-defaults", "area": "Event Capture — Optimize", "label": "Automatic pageviews do not dominate event volume", "status": "pending" },
+    { "id": "events-env-pollution", "area": "Event Capture — Optimize", "label": "Production project excludes non-production events", "status": "pending" }
+  ]
+}
+```
+
 Do not read any files in this step. Do not call `audit_resolve_checks`. Do not preload future steps.
 
 Continue to **`2-events-fix.md`**.

context/skills/audit-events/references/4-report.md

@@ -4,7 +4,7 @@ next_step: null
 
 # Step 4 — Generate the audit report
 
-The audit report is rendered **directly from `.posthog-audit-checks.json`** — that file is the source of truth. Every check the wizard seeded for this skill ends up in the report, even passes; nothing is invented.
+The audit report is rendered **directly from `.posthog-audit-checks.json`** — that file is the source of truth. Every check Step 1 seeded ends up in the report, even passes; nothing is invented.
 
 ## Status
 

context/skills/audit-feature-flags/description.md

@@ -13,7 +13,7 @@ The billed feature flag endpoint is `/flags` (the renamed `/decide`). All refere
 
 The audit runs as a step chain. **The exact step list lives in the reference files themselves, not in this overview.** Step 1 lives at `references/1-presence.md`; each step file ends with a `next_step:` frontmatter pointer to the next, and the final step has `next_step: null`. Follow them in the order they point. You must resolve each step in order before any source-tree exploration.
 
-The audit ledger is seeded by the wizard with one pending check per feature flag check. **Each step gracefully handles a missing check id**: if a step's expected id is not in the ledger, it skips its `audit_resolve_checks` call for that id and continues. Use `mcp__wizard-tools__audit_resolve_checks` to patch each check as you finish it.
+Step 1 seeds the audit ledger itself with one pending check per feature flag check through `mcp__wizard-tools__audit_seed_checks`, because the runtime does not pre-seed this skill. **Each step gracefully handles a missing check id**: if a step's expected id is not in the ledger, it skips its `audit_resolve_checks` call for that id and continues. Use `mcp__wizard-tools__audit_resolve_checks` to patch each check as you finish it.
 
 **Start by reading the path relative to this file at `references/1-presence.md`.** Do not Glob, ls, or find the skill directory. Do not preload future steps. Do not re-read a step file once you've moved past it. Do not re-read SKILL.md.
 
@@ -35,6 +35,7 @@ The wizard intercepts these and updates the spinner. Use them freely — they ar
 
 The ledger lives at `.posthog-audit-checks.json` and is rendered live in the "Audit plan" tab. It is owned by MCP tools — **never `Write` this file directly**:
 
+- `mcp__wizard-tools__audit_seed_checks({ checks })` — writes the full pending checklist once, at Step 1. It replaces the file atomically, so one call per run is safe.
 - `mcp__wizard-tools__audit_resolve_checks({ updates })` — patch one or more checks by `id`. Each `update` is `{ id, status, file?, details? }`. Batch updates from the same step into a single call.
 
 All audit ledger calls are atomic and serialize internally — **concurrent calls from parallel subagents cannot lose updates**, so feel free to fan out runtime checks across `Agent` subagents when a step says so.

context/skills/audit-feature-flags/references/1-presence.md

@@ -12,6 +12,7 @@ Emit:
 
 ```
 [STATUS] Detecting PostHog feature flag usage
+[STATUS] Seeding audit checklist
 ```
 
 ## Action
@@ -25,9 +26,29 @@ Run **two `Grep` calls in parallel**, both with `output_mode: "files_with_matche
 
 ## Decision
 
-- **Surface grep returns zero hits anywhere in the project:** emit `[ABORT] No PostHog feature flag usage found` and stop. The wizard catches `[ABORT]` and terminates the run.
+- **Surface grep returns zero hits anywhere in the project:** emit `[ABORT] No PostHog feature flag usage found` and stop. The wizard catches `[ABORT]` and terminates the run. Do not seed the ledger.
 - **Surface grep finds hits:** continue.
 
+## Seed the audit ledger
+
+The ledger lives at `.posthog-audit-checks.json` and renders live in the wizard sidebar / "Audit plan" tab. **The runtime does not pre-seed this skill's ledger**, so call `mcp__wizard-tools__audit_seed_checks` here with the exact payload below. Do not seed when this step aborts. The tool replaces the file atomically, so one call at the start of every run is safe.
+
+```json
+{
+  "checks": [
+    { "id": "ff-bootstrap-when-known-set", "area": "Feature Flags", "label": "Known initial flag sets use bootstrap", "status": "pending" },
+    { "id": "ff-await-readiness", "area": "Feature Flags", "label": "Flag evaluation waits for readiness", "status": "pending" },
+    { "id": "ff-default-values", "area": "Feature Flags", "label": "Flag evaluations have safe default values", "status": "pending" },
+    { "id": "ff-bootstrap-distinct-id-mismatch", "area": "Feature Flags", "label": "Bootstrap distinct ID matches stable identity", "status": "pending" },
+    { "id": "ff-identified-only-pre-auth-targeting", "area": "Feature Flags", "label": "Pre-auth flag targeting works for anonymous users", "status": "pending" },
+    { "id": "ff-active-but-unreferenced", "area": "Feature Flags — Optimize", "label": "Active flags have codebase references", "status": "pending" },
+    { "id": "ff-local-eval-polling-interval", "area": "Feature Flags — Optimize", "label": "Local evaluation uses an intentional polling interval", "status": "pending" },
+    { "id": "ff-local-eval-in-edge-handlers", "area": "Feature Flags — Optimize", "label": "Edge handlers avoid local flag evaluation", "status": "pending" },
+    { "id": "ff-test-ci-gating", "area": "Feature Flags — Optimize", "label": "Test and CI runs gate flag evaluation", "status": "pending" }
+  ]
+}
+```
+
 ## Record local-evaluation detection
 
 Local evaluation is detected when the second grep returns **at least one hit** (the project either initializes a server SDK with `personal_api_key` / a feature-flags secure API key, or calls a local-evaluation-only API like `getAllFlagsAndPayloads` / `getAllFlags` on the server). Keep this signal in working memory — Step 3 uses it to decide whether to run two of the optimize subagents or skip them as `pass` with `details: "skip: local evaluation not detected"`.

context/skills/audit-feature-flags/references/4-report.md

@@ -4,7 +4,7 @@ next_step: null
 
 # Step 4 — Generate the audit report
 
-The audit report is rendered **directly from `.posthog-audit-checks.json`** — that file is the source of truth. Every check the wizard seeded for this skill ends up in the report, even passes; nothing is invented.
+The audit report is rendered **directly from `.posthog-audit-checks.json`** — that file is the source of truth. Every check Step 1 seeded ends up in the report, even passes; nothing is invented.
 
 ## Status
 

context/skills/audit-identify/description.md

@@ -12,7 +12,7 @@ The audit covers three lenses:
 
 The audit runs as a step chain. **The exact step list lives in the reference files themselves, not in this overview.** Step 1 lives at `references/1-presence.md`; each step file ends with a `next_step:` frontmatter pointer to the next, and the final step has `next_step: null`. Follow them in the order they point. You must resolve each step in order before any source-tree exploration.
 
-The audit ledger is seeded by the wizard with one pending check per identify check. **Each step gracefully handles a missing check id**: if a step's expected id is not in the ledger, it skips its `audit_resolve_checks` call for that id and continues. Use `mcp__wizard-tools__audit_resolve_checks` to patch each check as you finish it.
+Step 1 seeds the audit ledger itself with one pending check per identify check through `mcp__wizard-tools__audit_seed_checks`, because the runtime does not pre-seed this skill. **Each step gracefully handles a missing check id**: if a step's expected id is not in the ledger, it skips its `audit_resolve_checks` call for that id and continues. Use `mcp__wizard-tools__audit_resolve_checks` to patch each check as you finish it.
 
 **Start by reading the path relative to this file at `references/1-presence.md`.** Do not Glob, ls, or find the skill directory. Do not preload future steps. Do not re-read a step file once you've moved past it. Do not re-read SKILL.md.
 
@@ -34,14 +34,15 @@ The wizard intercepts these and updates the spinner. Use them freely — they ar
 
 The ledger lives at `.posthog-audit-checks.json` and is rendered live in the "Audit plan" tab. It is owned by MCP tools — **never `Write` this file directly**:
 
+- `mcp__wizard-tools__audit_seed_checks({ checks })` — writes the full pending checklist once at Step 1. It replaces the file atomically, so one call per run is safe.
 - `mcp__wizard-tools__audit_resolve_checks({ updates })` — patch one or more checks by `id`. Each `update` is `{ id, status, file?, details? }`. Batch updates from the same step into a single call.
 
 All audit ledger calls are atomic and serialize internally — **concurrent calls from parallel subagents cannot lose updates**, so feel free to fan out runtime checks across `Agent` subagents when a step says so.
 
 ### Check entry shape
 
 - `id` — stable kebab-case slug. Reuse the existing seeded ids exactly when calling `audit_resolve_checks`.
-- `area` — short group name. This skill seeds three areas: `Identification` (fix), `Identification — Lifecycle` (quality), and `Identification — Optimize` (cost).
+- `area` — short group name. This skill seeds four areas: `Identification` (fix), `Identification — Lifecycle` (quality), `Identification — Optimize` (cost), and `Identification — Server SDK` (server-side hygiene).
 - `label` — short human name.
 - `status` — `pending` | `pass` | `error` | `warning` | `suggestion`.
 - `file` — optional `path:line` for findings tied to a location.