@agent-native/core 0.152.1 → 0.153.1

package/dist/templates/workspace-core/.agents/skills/tracking/SKILL.md

@@ -1,278 +0,0 @@
----
-name: tracking
-description: >-
-  Server-side analytics tracking with pluggable providers. Use when adding
-  analytics events, registering custom tracking providers, or configuring
-  built-in providers (PostHog, Mixpanel, Amplitude, Webhook).
-scope: dev
-metadata:
-  internal: true
----
-
-# Tracking
-
-## Rule
-
-The tracking system provides a single `track()` call that fans out to all registered providers. Built-in providers auto-register from env vars -- set the var and tracking starts. Custom providers can be registered for any analytics backend. Tracking is server-side only, best-effort, and never blocks request handling.
-
-## How It Works
-
-1. At server startup, `registerBuiltinProviders()` checks env vars and registers any configured providers.
-2. Application code calls `track(eventName, properties, source)` from actions, plugins, or server routes.
-3. The registry fans out the event to every registered provider. Errors are caught and logged -- a failing provider never crashes the caller.
-4. Built-in providers batch HTTP calls (flush every 10 seconds or 50 events, whichever comes first).
-
-## API
-
-### `track(name, properties?, source?)`
-
-Fire an analytics event. `source` is either a `{ userId, anonymousId, sessionId }`
-meta object or an action's `ctx` passed straight through.
-
-```ts
-import { track } from "@agent-native/core/tracking";
-
-// From an action — pass ctx; userId comes from ctx.userEmail.
-run: async ({ name }, ctx) => {
-  track("meal.logged", { mealName: name, calories: 350 }, ctx);
-};
-
-// From a plugin or route with no ctx.
-track(
-  "meal.logged",
-  { mealName: "Salad", calories: 350 },
-  { userId: "user@example.com" },
-);
-```
-
-The caller's browser session comes from the ambient request context
-(`RequestContext.browserSessionId`, set from the `X-Agent-Native-Session-Id`
-header), so it resolves the same whether the UI called the action or the agent
-did. Pass `sessionId` in the meta object to override it — routes that run
-outside a request context, such as `/_agent-native/track`, do exactly that.
-Providers map it to their own session field: `$session_id` for PostHog (which
-joins the event to session replay), `session_id` as a property for Mixpanel and
-Amplitude, a top-level `sessionId` for webhooks and Agent Native Analytics. It
-is absent for callers with no browser — cron, CLI, MCP, A2A.
-
-### `identify(userId, traits?)`
-
-Identify a user with traits. Forwarded to providers that support it.
-
-```ts
-import { identify } from "@agent-native/core/tracking";
-
-identify("user@example.com", { plan: "pro", company: "ExampleCo" });
-```
-
-### `registerTrackingProvider(provider)`
-
-Register a custom provider.
-
-```ts
-import { registerTrackingProvider } from "@agent-native/core/tracking";
-
-registerTrackingProvider({
-  name: "my-analytics",
-  track(event) {
-    // Send event to your backend
-  },
-  identify(userId, traits) {
-    // Optional
-  },
-  flush() {
-    // Optional -- called on graceful shutdown
-  },
-});
-```
-
-### `flushTracking()`
-
-Flush all providers (call before process exit).
-
-## Built-in Providers
-
-Set the env var and the provider auto-registers at startup. No SDK dependencies -- all providers use raw HTTP.
-
-| Provider               | Env vars                                                                                                                                           |
-| ---------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- |
-| PostHog                | `POSTHOG_API_KEY` (required), `POSTHOG_HOST` (optional, defaults to `https://us.i.posthog.com`), `POSTHOG_ERROR_TRACKING=false` (optional opt-out) |
-| Mixpanel               | `MIXPANEL_TOKEN`                                                                                                                                   |
-| Amplitude              | `AMPLITUDE_API_KEY`                                                                                                                                |
-| Agent Native Analytics | `AGENT_NATIVE_ANALYTICS_PUBLIC_KEY` (server), `AGENT_NATIVE_ANALYTICS_ENDPOINT` (optional, defaults to `https://analytics.agent-native.com/track`) |
-| Webhook                | `TRACKING_WEBHOOK_URL` (required), `TRACKING_WEBHOOK_AUTH` (optional, sent as `Authorization` header)                                              |
-
-Multiple providers can be active simultaneously. All receive every event.
-
-Browser-side `trackEvent()` also forwards to Agent Native Analytics when `VITE_AGENT_NATIVE_ANALYTICS_PUBLIC_KEY` is present. Use `VITE_AGENT_NATIVE_ANALYTICS_ENDPOINT` to override the default browser endpoint. The built-in Agent Native Analytics sender is quiet on localhost/local dev by default; set `AGENT_NATIVE_ANALYTICS_ALLOW_LOCALHOST=true` only for an intentional local ingestion test.
-
-## Error Capture
-
-Exceptions fan out through `server/capture-error.ts` to every registered
-backend — Sentry, PostHog, and the tracking providers — from one `captureError()`
-call. Backends are additive: configuring a second one does not displace the
-first, and no backend is required for the others to work.
-
-Emit through `captureError()` / `captureException()`. Never hand-roll a
-`track("$exception", …)`: each backend needs its own payload shape and the
-providers build it.
-
-- **Provider-agnostic wiring must not live in a provider plugin.** The Nitro
-  `error` hook is in `core-routes-plugin.ts`, not `sentry-plugin.ts`, because
-  that plugin returns early when no `SENTRY_DSN` is set — hooking route errors
-  there meant an app on any other backend silently reported none.
-- **Every backend applies `server/error-noise-filter.ts`.** It holds
-  production-tuned drop rules (expected 4xx, access-control rejections, Lambda
-  freeze/thaw `socket hang up`). A backend that skips it receives a firehose;
-  the `socket hang up` rule alone is ~10k events/day.
-- **A backend can accept a malformed payload and still show a count.** PostHog
-  ingested the framework's camelCase `$exception` for a long time and rendered
-  empty, ungroupable issues — which reads as coverage, not as breakage. When
-  adding or changing a backend, check what an event looks like in its UI, not
-  just that the request returned 200.
-- **Attribute the error.** Without a user id, server exceptions land under
-  `anonymous` and split one person in two against their browser events. Pass
-  `aiTraceId` for anything inside an agent run so the issue and the LLM trace
-  resolve to each other.
-
-Symbolication is per-backend and not automatic: the framework uploads no source
-maps to PostHog, so minified browser stacks stay minified there. Known gap, not
-a bug to re-diagnose.
-
-### Browser keys and the SSR shell
-
-Public keys (`POSTHOG_PUBLIC_KEY`, the Sentry client DSN) ship inside the
-CDN-cached SSR shell — publishable and identical for every visitor. Server keys
-never do, and are never a fallback for a public one: `POSTHOG_API_KEY` may be a
-private key and this value lands in public HTML.
-
-Browser errors post directly to the backend rather than through
-`/_agent-native/track`, because that route requires a resolved session and
-relaying would drop every signed-out crash.
-
-When adding a client config field, update **both** `server/posthog-config.ts`
-and the mirrored worker emitter in `deploy/build.ts` — the worker bundles a
-string copy and cannot import the module, so a one-sided edit drops the config
-silently in deployed builds. `posthog-config.spec.ts` pins the two outputs
-together.
-
-## Default Baseline Events
-
-Template roots call `configureTracking()` once during app startup. That installs default browser pageview tracking for hosted apps:
-
-- Event: `pageview`
-- Fires on initial load, `history.pushState`, `history.replaceState`, and `popstate`
-- De-dupes repeated events for the same URL
-- Includes `url`, `path`, `hostname`, `referrer`, `title`, `navigation_type`, `app`, and inferred `template`
-- Includes LLM connection context on browser events when known: `llm_connection` (`builder`, `anthropic`, `openai`, etc.), `llm_engine`, `llm_model`, `llm_connection_source`, and `llm_connection_configured`
-- Does not send first-party events from localhost/local dev
-
-### Visitor identity (`anonymousId` + `sessionId`)
-
-Every browser-side `trackEvent()` POST to the Agent Native Analytics `/track` endpoint includes:
-
-- `anonymousId` — persistent per-browser visitor ID stored in `localStorage` under `agent-native.anonymous_id`. Generated once and reused across sessions. Use this for unique-visitor and returning-visitor metrics.
-- `sessionId` — rotating per-visit ID stored in `localStorage` under `agent-native.session_id`, with a 30-minute idle timeout (matches GA4 / Mixpanel defaults). Use this for sessions-per-visitor, pages-per-session, and session-duration metrics.
-- `userId` — only set when the calling code passes `properties.userId`. Anonymous traffic leaves this NULL by design; `anonymousId` is the fallback.
-
-These fields land in the `analytics_events.anonymous_id`, `analytics_events.session_id`, and `analytics_events.user_id` columns in the analytics template. Storage access is wrapped in try/catch — private-browsing / blocked-storage clients silently degrade to NULL rather than crashing the page.
-
-### Referral / viral attribution (first-touch)
-
-`configureTracking()` also captures an anonymous visitor's **first-touch** referral context once, on first page load, and persists it across the signup boundary so the server-side `signup` event records where the user came from. This powers virality metrics for every template (Clips share links, Plans public pages, etc.).
-
-**Share-link params** (set by whatever generates the link; read client-side only):
-
-- `ref` — referral source bucket, e.g. `clip_share`, `plan_share`
-- `via` — the referrer's stable user id (the clip/plan owner)
-- `utm_source`, `utm_medium`, `utm_campaign`, `utm_content`, `utm_term`
-
-**Client persistence** (first-write-wins — an existing value is never overwritten):
-
-- `localStorage` key `an_attribution` and first-party cookie `an_ft` (`path=/; max-age=2592000; SameSite=Lax`, not HttpOnly — non-sensitive, written by client JS).
-- Both store the same URL-encoded compact JSON (empty fields omitted, each value capped at 120 chars): `{ ref, via, utm_source, utm_medium, utm_campaign, utm_content, utm_term, landing_path, landing_referrer, landed_at }`. `landing_referrer` is the **host only** of `document.referrer` (scrubbed; same-origin referrers are dropped).
-- `getFirstTouchAttribution()` (from `@agent-native/core/client`) returns the parsed object or `null`.
-
-**Signup event enrichment** (server-side, from the `an_ft` cookie on the signup/OAuth-callback request, derived in `packages/core/src/server/attribution.ts`):
-
-- `referral_source` — `ref` if present, else derived: `/share/…` → `clip_share`; a plan public path (`/p/`, `/plan/`, `/share-plan/`) → `plan_share`; a non-empty external referring host → `external`; otherwise `direct`.
-- `referrer_user` (= `via`), `referral_medium` (= `utm_medium`), `referral_campaign` (= `utm_campaign`)
-- `utm_source`, `utm_medium`, `utm_campaign`, `utm_content`, `utm_term` (raw passthrough)
-- `first_touch_path` (= `landing_path`), `landing_referrer`
-
-Attribution parsing is fully defensive and never blocks signup — a missing/malformed cookie falls back to `referral_source: "direct"`.
-
-Other framework-level baseline events:
-
-- `session status` from `useSession()`, with `signed_in`
-- `action.response` from the browser action transport, with action name,
-  browser-perceived duration and TTFB, response status/outcome, response size
-  when known, and parsed `Server-Timing` phases for framework readiness and
-  database work. Its `request_id` joins the exact browser and server events.
-  This separates server time from CDN/network/body overhead.
-- `http.response` from Nitro request/response hooks, with normalized path,
-  status, request duration, first-request-in-isolate cold marker, process age,
-  framework readiness wait, deploy/runtime fingerprint, database
-  connection/query counts and timings, retries, timeouts, and failures. It also
-  emits `Server-Timing` for `app`, `startup`, `db`, `db-connect`, and
-  `db-slowest` plus an `X-Agent-Native-Request-Id` correlation header where
-  applicable. Query text and parameters are never captured.
-  Database activity that begins during the first two minutes of process/plugin
-  initialization is reported separately as `startup_db_*` on the first
-  framework request that passes the readiness gate.
-  Slow, cold-isolate, server failures, and 4xx action routes are always
-  retained; fast successful requests default to 10% sampling. Override with
-  `AGENT_NATIVE_HTTP_TELEMETRY_SAMPLE_RATE` on the server and
-  `VITE_AGENT_NATIVE_ACTION_TELEMETRY_SAMPLE_RATE` in the browser.
-- `signup` from Better Auth user creation, with `auth_provider`, `auth_user_id`, and first-touch referral attribution (`referral_source`, `referrer_user`, `referral_medium`, `referral_campaign`, `utm_*`, `first_touch_path`, `landing_referrer` — see "Referral / viral attribution" above)
-- `builder connect clicked` and `builder connect popup blocked` from browser Connect Builder CTAs
-- `builder connect started`, `builder connect succeeded`, `builder connect failed`, `builder disconnect succeeded`, and `builder disconnect failed` from the Builder connection routes, with LLM connection context when resolvable
-- `$ai_generation` from instrumented agent loops, with PostHog AI Observability fields such as `$ai_trace_id`, `$ai_session_id`, `$ai_model`, `$ai_provider`, `$ai_input_tokens`, `$ai_output_tokens`, `$ai_latency`, `$ai_total_cost_usd`, and mirrored Agent Native query fields such as `run_id`, `thread_id`, `cost_cents_x100`, `duration_ms`, `tool_calls`, and `status`. A bounded `tools` array contains names, start offsets, durations, statuses, and coarse error classes only; interrupted tools and failed runs remain visible, and delegated runs include protocol/task/parent-run/parent-turn correlation. Prompt, tool argument, result, and output content is excluded unless `captureToolResults` is opted in (see the `observability` skill), in which case each failed tool call also carries a `error_message` string truncated to 500 characters and already scrubbed of bearer tokens, API keys, and key/value secret patterns.
-
-For new lifecycle events, call `track()` server-side when the server is the source of truth, and `trackEvent()` client-side only for browser interactions.
-
-## Provider Interface
-
-```ts
-interface TrackingProvider {
-  name: string;
-  track(event: TrackingEvent): void | Promise<void>;
-  identify?(
-    userId: string,
-    traits?: Record<string, unknown>,
-  ): void | Promise<void>;
-  flush?(): void | Promise<void>;
-}
-
-interface TrackingEvent {
-  name: string;
-  properties?: Record<string, unknown>;
-  timestamp?: string;
-  userId?: string;
-}
-```
-
-## Design Decisions
-
-- **globalThis singleton** -- the registry uses a `Symbol.for` key on globalThis so multiple ESM graph instances (dev-mode Vite + Nitro, symlinks) share one provider set.
-- **Best-effort fan-out** -- provider errors are caught and logged, never propagated. A broken analytics integration must not break app functionality.
-- **Batched HTTP** -- built-in providers enqueue events and flush every 10 seconds or 50 events, minimizing outbound requests.
-- **NOT bridged to the event bus** -- tracking and the event bus are separate concerns. The event bus is for triggering automations; tracking is for analytics. Do not subscribe to `track()` calls from the event bus or vice versa.
-
-## Key Files
-
-| File                                      | Purpose                                                                                                             |
-| ----------------------------------------- | ------------------------------------------------------------------------------------------------------------------- |
-| `packages/core/src/tracking/registry.ts`  | `track()`, `identify()`, `registerTrackingProvider()`, `flushTracking()`                                            |
-| `packages/core/src/tracking/providers.ts` | Built-in providers (PostHog, Mixpanel, Amplitude, Agent Native Analytics, Webhook) and `registerBuiltinProviders()` |
-| `packages/core/src/tracking/types.ts`     | `TrackingEvent` and `TrackingProvider` interfaces                                                                   |
-| `packages/core/src/tracking/posthog-exception.ts` | `$exception_list` builder + stack-frame parser (isomorphic: server and browser)                             |
-| `packages/core/src/tracking/redaction.ts` | Shared bounding/redaction helpers used by every exception emitter                                                   |
-| `packages/core/src/server/error-noise-filter.ts` | Provider-agnostic drop rules, applied by both Sentry `beforeSend` and the route error hook                   |
-| `packages/core/src/server/posthog-config.ts` | Public browser PostHog config (mirrored in `deploy/build.ts`)                                                    |
-
-## Related Skills
-
-- `secrets` -- API keys for tracking providers can be registered as secrets
-- `server-plugins` -- `registerBuiltinProviders()` is called by the core-routes plugin at startup
-- `actions` -- call `track()` from action handlers to record user/agent activity

package/dist/templates/workspace-core/.agents/skills/upgrade-agent-native/SKILL.md

@@ -1,127 +0,0 @@
----
-name: upgrade-agent-native
-description: >-
-  Bring an older Agent Native app or workspace current. Use when updating
-  @agent-native/core, fixing a broken upgrade, or when tempted to patch or
-  override core/dispatch packages to make an old branch run.
-scope: dev
-metadata:
-  internal: true
----
-
-# Upgrade Agent Native
-
-## Rule
-
-When an older Agent Native app/branch needs to run on current packages, use
-`agent-native upgrade`. Never "fix" upgrade breakage with
-`pnpm patch`, `pnpm patch-commit`, `pnpm.patchedDependencies`,
-`pnpm.overrides`, `patchedDependencies`, `resolutions`, local patch artifacts,
-or edits under `node_modules/@agent-native/*` — especially not against
-`@agent-native/core` or `@agent-native/dispatch`.
-
-## Why
-
-Agents often respond to a failed core bump by inventing framework patches and
-dispatch behavior overrides. That hides the real app-level break, drifts from
-upstream, and makes the next upgrade worse. The supported path is bump →
-install → refresh scaffold skills → verify, then fix **app** code only.
-
-## How
-
-1. **Preview migration codemods first**
-
-   ```bash
-   npx @agent-native/core@latest upgrade --codemods
-   ```
-
-   Codemods are preview-by-default: read the diff before applying it. Do not
-   manually edit imports before running this command; the migration manifest is
-   the source of truth for renamed specifiers and symbols.
-
-2. **Apply the reviewed codemods, then run the upgrade**
-
-   ```bash
-   npx @agent-native/core@latest upgrade --codemods --yes
-   npx @agent-native/core@latest upgrade
-   ```
-
-   Or from an already-installed CLI: `pnpm exec agent-native upgrade` /
-   `agent-native upgrade`.
-
-   What it does:
-
-   - Blocks (unless `--force`) when `@agent-native/*` overrides/patches exist
-   - Rewrites non-local `@agent-native/*` dependency pins to `latest`
-   - Runs the package manager install
-   - Rewrites those pins to the exact versions the install resolved, so the
-     committed manifest names one release instead of re-resolving next install
-   - Runs `skills update scaffold --project`
-   - Runs `typecheck` when the project has that script
-
-3. **Pull upstream template changes (optional, separate from the bump)**
-
-   `agent-native upgrade` moves package versions. It never touches files that
-   were copied out of a template at scaffold time, so template fixes and
-   improvements do not arrive with a bump.
-
-   ```bash
-   agent-native template status        # recorded ref vs latest, drift counts
-   agent-native template diff          # what upstream changed, read-only
-   agent-native template sync          # 3-way merge it into the app
-   ```
-
-   `sync` defaults to the ref matching the installed `@agent-native/core`, so
-   run it after `upgrade`. It merges per file against a pristine baseline
-   stored in `refs/agent-native/template-baseline/<app-path>`; files upstream
-   did not touch are left alone, and real collisions get conflict markers.
-   After resolving markers, run `agent-native template accept` — the baseline
-   deliberately does not advance past an unresolved merge.
-
-   Apps scaffolded before provenance existed have no baseline. Create one
-   with `agent-native template baseline` before the first sync.
-
-4. **If upgrade or typecheck fails**
-
-   - Read the concrete error
-   - Fix **app** source, actions, config, or env — not framework packages
-   - Re-run `agent-native upgrade` or `pnpm typecheck`
-   - Stop and ask the user if you cannot fix the app-level error
-
-   Intentional app-level UI customization is a separate workflow. Read
-   `customizing-agent-native` when the product needs to own a selectively
-   copied component; do not use that path to reproduce framework runtime
-   behavior or hide version skew.
-
-5. **Dry-run / partial runs**
-
-   ```bash
-   agent-native upgrade --dry-run
-   agent-native upgrade --skip-verify
-   agent-native upgrade --skip-install   # package.json bumps only
-   agent-native doctor --only migration-manifest
-   ```
-
-   `migration-manifest` has no opt-out. Run it in CI before upgrading to find
-   imports that will break, then use `npx @agent-native/core@latest upgrade --codemods`
-   to preview the supported rewrite.
-
-## Don't
-
-- Don't add `pnpm.overrides`, `overrides`, `resolutions`, or
-  `patchedDependencies` for any `@agent-native/*` package
-- Don't run `pnpm patch` or `pnpm patch-commit`, or commit files under
-  `patches/`, for any dependency
-- Don't edit `node_modules/@agent-native/core` or
-  `node_modules/@agent-native/dispatch`
-- Don't invent local "dispatch behavior" shims to paper over version skew
-- Don't keep iterating with more framework patches after a failed install
-- Don't skip `skills update scaffold --project` after a core bump (the
-  upgrade command does this for you)
-
-## Related Skills
-
-- **self-modifying-code** — Tier 4: framework packages are off limits
-- **agent-native-docs** — version-matched docs after the bump
-- **customizing-agent-native** — intentional app-owned UI copies, not upgrade patches
-- **portability** — keep app code provider-agnostic across upgrades

package/dist/templates/workspace-core/.agents/skills/visual-answer/SKILL.md

@@ -1,101 +0,0 @@
----
-name: visual-answer
-description: >-
-  Answer code/product questions as visual Plan artifacts using repo, bridge, or
-  GitHub context; use for API specs, UI look, schema models, and architecture.
-scope: dev
-metadata:
-  visibility: exported
----
-
-# Visual Answer
-
-`/visual-answer` turns a specific code or product question into a published
-Agent-Native Plan artifact. It is for questions that need a visual, inspectable
-answer rather than a chat paragraph: API contracts, schema/data models, UI
-states, component behavior, architecture flows, and code evidence.
-
-## When To Use
-
-Use this skill when the user asks:
-
-- "what is the API spec for this?"
-- "what does this UI look like?"
-- "what is the schema model for x?"
-- "draw the flow for this code path"
-- "show me the current shape of this component/API/data model"
-
-For history questions about what changed or shipped, search merged PR recaps
-first with `search-pr-recaps`, then pull a relevant hit into the conversation
-with `show-visual-plan` (it renders that plan or recap's blocks inline). Reach
-for `get-visual-plan` only when you need the full bundle/MDX to edit, not to
-display. Use `visual-answer` when the current codebase, a local bridge, or
-GitHub source needs to be inspected to produce a new answer.
-
-## Workflow
-
-1. Inspect the real source first. Use the host agent's repo tools, the Plan
-   local bridge, or GitHub/source links. Do not invent endpoints, schema fields,
-   UI states, file names, or behavior.
-2. Call `get-plan-blocks` before authoring. Use the live registry, not memory.
-   If the question asks what components are available, call
-   `list-plan-components`.
-3. Pick the evidence blocks:
-   - API shape: `openapi-spec` plus `api-endpoint`; use before/after only when
-     comparing historical changes from recaps.
-   - UI look: `wireframe` or a `columns` before/after pair when comparing a
-     recap.
-   - Schema/data model: `data-model`, optionally with `diagram`.
-   - Code evidence: `file-tree`, `tabs`, `annotated-code`, and `diff` when the
-     answer depends on implementation details.
-4. Publish with the Plan `visual-answer` action. Include the user's question,
-   `repoPath`/`sourceUrl` when known, a concise title/brief, and MDX source
-   under `mdx`.
-5. In Agent-Native chat the published answer renders inline automatically — its
-   blocks appear in the conversation. Add a one-line summary of the evidence plus
-   the deep link; do not paste raw MDX or block source as text. (In terminal or
-   external MCP hosts that cannot render the blocks, return the URL.)
-
-## Terminal Handoff
-
-When running from a terminal or coding-agent shell, write
-`visual-answer-source.json`:
-
-```json
-{
-  "question": "What is the billing API shape?",
-  "title": "Billing API visual answer",
-  "brief": "Shows the request and response contract.",
-  "repoPath": "owner/repo",
-  "sourceUrl": "https://github.com/owner/repo",
-  "mdx": {
-    "plan.mdx": "---\ntitle: Billing API visual answer\n---\n\n..."
-  }
-}
-```
-
-Then publish:
-
-```sh
-agent-native plan visual-answer publish --question "What is the billing API shape?" --source visual-answer-source.json --repo owner/repo
-```
-
-Use `--source-url` for a GitHub file/PR/commit/issue URL, `--prev-plan-id` to
-refresh an existing answer, and `--visibility private` for owner-only output.
-The command writes `visual-answer-url.txt`.
-
-## Don't
-
-- Do not use `visual-answer` for a plain implementation plan; use
-  `visual-plan`.
-- Do not use it for a PR diff recap; use `visual-recap`.
-- Do not skip code inspection and infer from names alone.
-- Do not publish screenshots, secrets, credential-looking values, or private
-  source excerpts beyond what the user has asked to visualize.
-
-## Related Skills
-
-- `visual-plan`
-- `visual-recap`
-- `delegate-to-agent`
-- `context-awareness`