feat(skills): publish every report through publish_handoff, no local files

context/agents/integration-v2/report.md

@@ -6,7 +6,7 @@ model_pi: openai/gpt-5.6-luna
 effort_pi: low
 model_sdk: claude-sonnet-4-6
 effort_sdk: high
-skills: [integration-v2-report, integration-v2-notebook, integration-v2-mcp]
+skills: [integration-v2-report, integration-v2-mcp]
 allowedTools: [Read, Glob, Grep]
 disallowedTools: [enqueue_task]
 dependsOn: [dashboard, review]
@@ -18,9 +18,9 @@ Compose the setup report summarizing what this integration did, drawing only on
 what the run itself recorded: the queue log and event plan in
 `.posthog-wizard-cache/` (`queue.json` and `.posthog-events.json`), and the
 handoff each step left behind. Then publish it with a single `publish_handoff`
-call, and mirror the same markdown into a shareable PostHog notebook, emitting
-its URL with the `[NOTEBOOK_URL]` marker. Do not write a report file — the
-handoff call and the notebook are how the report reaches the user.
+call. That call is how the report reaches the user: the tool creates the
+shareable PostHog notebook from it and hands the wizard the link. Do not write a
+report file, and do not create the notebook yourself.
 
 Separate what the run verified from what it did not. A passing build proves the
 code compiles, not that events flow — never write that an event was captured
@@ -42,6 +42,5 @@ One `publish_handoff` call went through with the full report: what was
 installed and initialized, the events captured, whether identify was wired or
 skipped, error tracking added, the dashboard link, any build conflict in full,
 and the next steps for the user. Every claim in it traces to a handoff, and
-what the run could not confirm reads as unconfirmed. The same report is
-mirrored into a PostHog notebook whose URL is emitted with the
-`[NOTEBOOK_URL]` marker.
+what the run could not confirm reads as unconfirmed. Nothing else is needed —
+the notebook comes from that one call.

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

@@ -50,7 +50,7 @@ The ledger lives at `.posthog-audit-checks.json` and renders live in the wizard
     { "id": "attribution-cross-subdomain-cookie",  "area": "Attribution — Configuration", "label": "cross_subdomain_cookie configured for multi-subdomain projects", "status": "pending" },
     { "id": "attribution-cookieless-mode-impact",  "area": "Attribution — Configuration", "label": "cookieless_mode tradeoff acknowledged",                          "status": "pending" },
     { "id": "attribution-consent-integration",     "area": "Attribution — Configuration", "label": "Consent banner wired to PostHog opt_in/opt_out",                 "status": "pending" },
-    { "id": "write-report",                        "area": "Write report",                "label": "Render posthog-audit-attribution-report.md",                     "status": "pending" }
+    { "id": "write-report",                        "area": "Write report",                "label": "Publish the attribution audit report",                           "status": "pending" }
   ]
 }
 ```

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

@@ -2,7 +2,7 @@
 next_step: null
 ---
 
-# Step 4 — Generate the audit report
+# Step 4 — Compose and publish 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.
 
@@ -11,14 +11,14 @@ The audit report is rendered **directly from `.posthog-audit-checks.json`** —
 Emit:
 
 ```
-[STATUS] Writing attribution audit report
+[STATUS] Publishing attribution audit report
 ```
 
 ## Action
 
 `Read` the ledger once, then transform every entry into the report below. Use `area`, `label`, `status`, `file`, and `details` from each entry verbatim where the report calls for them.
 
-`Write` `posthog-audit-attribution-report.md` at the project root with the structure shown below. After the markdown lands on disk, resolve the `write-report` ledger row to `pass` so the wizard sidebar advances. Then delete `.posthog-audit-checks.json`.
+Compose the report as markdown with the structure shown below and publish it in **one** `publish_handoff` call — that call is how the report reaches the user, and the tool creates the shareable PostHog notebook copy and surfaces its URL for you. Do not write a report file. After the call goes through, resolve the `write-report` ledger row to `pass` so the wizard sidebar advances. Then delete `.posthog-audit-checks.json`.
 
 The report has four sections in this order:
 
@@ -119,8 +119,10 @@ Re-run `posthog-wizard audit attribution` after applying fixes to refresh the le
 
 </wizard-report>
 
-After the report is written, emit a final line so the wizard can surface the path to the user:
+Compose the whole report in one model turn — starting with the `#` H1 heading — then call `publish_handoff` once, passing the full markdown as `content`:
 
 ```
-Created audit report: <absolute path to posthog-audit-attribution-report.md>
+publish_handoff({ "content": "<the full report markdown>" })
 ```
+
+Do not fall back to writing a file. That one call is the whole handoff: the tool stores the report on the wizard session, mirrors it into a PostHog notebook, and surfaces the notebook URL in the wizard outro.

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

@@ -2,7 +2,7 @@
 next_step: null
 ---
 
-# Step 4 — Generate the audit report
+# Step 4 — Compose and publish 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.
 
@@ -11,14 +11,14 @@ The audit report is rendered **directly from `.posthog-audit-checks.json`** —
 Emit:
 
 ```
-[STATUS] Writing autocapture audit report
+[STATUS] Publishing autocapture audit report
 ```
 
 ## Action
 
 `Read` the ledger once, then transform every entry into the report below. Use `area`, `label`, `status`, `file`, and `details` from each entry verbatim where the report calls for them.
 
-`Write` `posthog-audit-autocapture-report.md` at the project root with the structure shown below. After the report is written, delete `.posthog-audit-checks.json`.
+Compose the report as markdown with the structure shown below and publish it in **one** `publish_handoff` call — that call is how the report reaches the user, and the tool creates the shareable PostHog notebook copy and surfaces its URL for you. Do not write a report file. After the call goes through, delete `.posthog-audit-checks.json`.
 
 The report has four sections in this order:
 
@@ -115,8 +115,10 @@ Re-run `posthog-wizard audit-autocapture` after applying fixes to refresh the le
 
 </wizard-report>
 
-After the report is written, emit a final line so the wizard can surface the path to the user:
+Compose the whole report in one model turn — starting with the `#` H1 heading — then call `publish_handoff` once, passing the full markdown as `content`:
 
 ```
-Created audit report: <absolute path to posthog-audit-autocapture-report.md>
+publish_handoff({ "content": "<the full report markdown>" })
 ```
+
+Do not fall back to writing a file. That one call is the whole handoff: the tool stores the report on the wizard session, mirrors it into a PostHog notebook, and surfaces the notebook URL in the wizard outro.

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

@@ -2,7 +2,7 @@
 next_step: null
 ---
 
-# Step 4 — Generate the audit report
+# Step 4 — Compose and publish 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.
 
@@ -11,14 +11,14 @@ The audit report is rendered **directly from `.posthog-audit-checks.json`** —
 Emit:
 
 ```
-[STATUS] Writing event capture audit report
+[STATUS] Publishing event capture audit report
 ```
 
 ## Action
 
 `Read` the ledger once, then transform every entry into the report below. Use `area`, `label`, `status`, `file`, and `details` from each entry verbatim where the report calls for them.
 
-`Write` `posthog-audit-events-report.md` at the project root with the structure shown below. After the report is written, delete `.posthog-audit-checks.json`.
+Compose the report as markdown with the structure shown below and publish it in **one** `publish_handoff` call — that call is how the report reaches the user, and the tool creates the shareable PostHog notebook copy and surfaces its URL for you. Do not write a report file. After the call goes through, delete `.posthog-audit-checks.json`.
 
 The report has four sections in this order:
 
@@ -115,8 +115,10 @@ Re-run `posthog-wizard audit-events` after applying fixes to refresh the ledger.
 
 </wizard-report>
 
-After the report is written, emit a final line so the wizard can surface the path to the user:
+Compose the whole report in one model turn — starting with the `#` H1 heading — then call `publish_handoff` once, passing the full markdown as `content`:
 
 ```
-Created audit report: <absolute path to posthog-audit-events-report.md>
+publish_handoff({ "content": "<the full report markdown>" })
 ```
+
+Do not fall back to writing a file. That one call is the whole handoff: the tool stores the report on the wizard session, mirrors it into a PostHog notebook, and surfaces the notebook URL in the wizard outro.

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

@@ -2,7 +2,7 @@
 next_step: null
 ---
 
-# Step 4 — Generate the audit report
+# Step 4 — Compose and publish 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.
 
@@ -11,14 +11,14 @@ The audit report is rendered **directly from `.posthog-audit-checks.json`** —
 Emit:
 
 ```
-[STATUS] Writing feature flag audit report
+[STATUS] Publishing feature flag audit report
 ```
 
 ## Action
 
 `Read` the ledger once, then transform every entry into the report below. Use `area`, `label`, `status`, `file`, and `details` from each entry verbatim where the report calls for them.
 
-`Write` `posthog-audit-feature-flags-report.md` at the project root with the structure shown below. After the report is written, delete `.posthog-audit-checks.json`.
+Compose the report as markdown with the structure shown below and publish it in **one** `publish_handoff` call — that call is how the report reaches the user, and the tool creates the shareable PostHog notebook copy and surfaces its URL for you. Do not write a report file. After the call goes through, delete `.posthog-audit-checks.json`.
 
 The report has four sections in this order:
 
@@ -118,8 +118,10 @@ Re-run `posthog-wizard audit-feature-flags` after applying fixes to refresh the
 
 </wizard-report>
 
-After the report is written, emit a final line so the wizard can surface the path to the user:
+Compose the whole report in one model turn — starting with the `#` H1 heading — then call `publish_handoff` once, passing the full markdown as `content`:
 
 ```
-Created audit report: <absolute path to posthog-audit-feature-flags-report.md>
+publish_handoff({ "content": "<the full report markdown>" })
 ```
+
+Do not fall back to writing a file. That one call is the whole handoff: the tool stores the report on the wizard session, mirrors it into a PostHog notebook, and surfaces the notebook URL in the wizard outro.

context/skills/audit-identify/references/6-report.md

@@ -2,7 +2,7 @@
 next_step: null
 ---
 
-# Step 6 — Generate the audit report
+# Step 6 — Compose and publish 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.
 
@@ -11,14 +11,14 @@ The audit report is rendered **directly from `.posthog-audit-checks.json`** —
 Emit:
 
 ```
-[STATUS] Writing identify audit report
+[STATUS] Publishing identify audit report
 ```
 
 ## Action
 
 `Read` the ledger once, then transform every entry into the report below. Use `area`, `label`, `status`, `file`, and `details` from each entry verbatim where the report calls for them.
 
-`Write` `posthog-audit-identify-report.md` at the project root with the structure shown below. After the report is written, delete `.posthog-audit-checks.json`.
+Compose the report as markdown with the structure shown below and publish it in **one** `publish_handoff` call — that call is how the report reaches the user, and the tool creates the shareable PostHog notebook copy and surfaces its URL for you. Do not write a report file. After the call goes through, delete `.posthog-audit-checks.json`.
 
 The report has four sections in this order:
 
@@ -136,8 +136,10 @@ Re-run `posthog-wizard audit-identify` after applying fixes to refresh the ledge
 
 </wizard-report>
 
-After the report is written, emit a final line so the wizard can surface the path to the user:
+Compose the whole report in one model turn — starting with the `#` H1 heading — then call `publish_handoff` once, passing the full markdown as `content`:
 
 ```
-Created audit report: <absolute path to posthog-audit-identify-report.md>
+publish_handoff({ "content": "<the full report markdown>" })
 ```
+
+Do not fall back to writing a file. That one call is the whole handoff: the tool stores the report on the wizard session, mirrors it into a PostHog notebook, and surfaces the notebook URL in the wizard outro.

context/skills/audit-session-replay/references/4-report.md

@@ -2,7 +2,7 @@
 next_step: null
 ---
 
-# Step 4 — Generate the audit report
+# Step 4 — Compose and publish 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.
 
@@ -11,14 +11,14 @@ The audit report is rendered **directly from `.posthog-audit-checks.json`** —
 Emit:
 
 ```
-[STATUS] Writing session replay audit report
+[STATUS] Publishing session replay audit report
 ```
 
 ## Action
 
 `Read` the ledger once, then transform every entry into the report below. Use `area`, `label`, `status`, `file`, and `details` from each entry verbatim where the report calls for them.
 
-`Write` `posthog-audit-session-replay-report.md` at the project root with the structure shown below. After the report is written, delete `.posthog-audit-checks.json`.
+Compose the report as markdown with the structure shown below and publish it in **one** `publish_handoff` call — that call is how the report reaches the user, and the tool creates the shareable PostHog notebook copy and surfaces its URL for you. Do not write a report file. After the call goes through, delete `.posthog-audit-checks.json`.
 
 The report has four sections in this order:
 
@@ -117,8 +117,10 @@ Re-run `posthog-wizard audit-session-replay` after applying fixes to refresh the
 
 </wizard-report>
 
-After the report is written, emit a final line so the wizard can surface the path to the user:
+Compose the whole report in one model turn — starting with the `#` H1 heading — then call `publish_handoff` once, passing the full markdown as `content`:
 
 ```
-Created audit report: <absolute path to posthog-audit-session-replay-report.md>
+publish_handoff({ "content": "<the full report markdown>" })
 ```
+
+Do not fall back to writing a file. That one call is the whole handoff: the tool stores the report on the wizard session, mirrors it into a PostHog notebook, and surfaces the notebook URL in the wizard outro.

context/skills/audit/description.md

@@ -1,18 +1,18 @@
 # PostHog Audit
 
-This skill audits an existing PostHog integration for **data integrity** in event capture and identification. **Read-only** — the only file you create is the final audit report.
+This skill audits an existing PostHog integration for **data integrity** in event capture and identification. **Read-only** — it creates no files; the audit report is published to the wizard session instead.
 
 Perform the checks described in the referenced skills and only the events referenced in the skills.
 
 ## Workflow
 
-The audit runs as a 5-step chain: Installation (SDK + version) → init correctness → identification → event capture → report (which also uploads the report to a PostHog notebook). Each step file ends with a pointer to the next. Follow them in the order they are written. You must resolve them in order before any source-tree exploration.
+The audit runs as a 5-step chain: Installation (SDK + version) → init correctness → identification → event capture → report (which publishes the report with a single `publish_handoff` call). Each step file ends with a pointer to the next. Follow them in the order they are written. You must resolve them in order before any source-tree exploration.
 
-The audit ledger is already seeded with the 11 pending checks (10 correctness checks plus `upload-notebook`, which the report step resolves after mirroring the markdown into a PostHog notebook). Use `mcp__wizard-tools__audit_resolve_checks` to patch each one as you finish it.
+The audit ledger is already seeded with the 12 pending checks (10 correctness checks plus `write-report` and `upload-notebook`, both of which the report step resolves after publishing the report). Use `mcp__wizard-tools__audit_resolve_checks` to patch each one as you finish it.
 
 **Start by reading the path relative to this file at `references/1-version.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.
 
-`ToolSearch` is only for loading a tool by exact name when the SDK has it deferred (e.g. `select:Grep`). Do **not** use it to browse for other tools — every tool the audit needs (`Glob`, `Grep`, `Read`, `Write`, `Bash`, and the named `mcp__wizard-tools__audit_*` tools) is already named in this skill.
+`ToolSearch` is only for loading a tool by exact name when the SDK has it deferred (e.g. `select:Grep`). Do **not** use it to browse for other tools — every tool the audit needs (`Glob`, `Grep`, `Read`, `Bash`, `publish_handoff`, and the named `mcp__wizard-tools__audit_*` tools) is already named in this skill.
 
 **Do not call `TaskCreate` / `TaskUpdate` / `TaskGet` / `TaskList`.** The audit doesn't track its own task list — progress comes from the audit ledger plus `[STATUS]` lines.
 
@@ -43,7 +43,7 @@ All audit ledger calls are atomic and serialize internally — **concurrent call
 - `file` — optional `path:line` for findings tied to a location.
 - `details` — optional one-line explanation.
 
-After the report is written (Step 5), delete `.posthog-audit-checks.json`.
+After the report is published (Step 5), delete `.posthog-audit-checks.json`.
 
 ## Severity levels
 
@@ -53,7 +53,7 @@ After the report is written (Step 5), delete `.posthog-audit-checks.json`.
 
 ## Key principles
 
-- **Read-only**: Do not edit project source files. The only file you create is the audit report.
+- **Read-only**: Do not edit project source files. The audit writes no report file — it publishes the report with `publish_handoff`.
 - **Evidence-based**: Reference specific `file:line` for every non-pass finding.
 - **Actionable**: Every finding states what to fix and how.