---
name: onboarding-call
description: "Create, prepare, update, or finalize one client-safe Sellable kickoff meeting document and Campaign 1 decision record on its deterministic public Notion page. Use for requests such as make the kickoff doc, prepare tomorrow's onboarding call, update the kickoff page, or finalize the Campaign 1 decisions for one named client."
visibility: public
allowed-tools:
  - Read
  - WebSearch
  - Bash(agent-browser:*)
  - Bash({{adminRoot}}/scripts/run-lightfield-crm.sh:*)
  - mcp__sellable-admin__admin_workspace_get
  - mcp__sellable-admin__admin_notion_publisher_doctor
  - mcp__sellable-admin__admin_onboarding_call
---

# Sellable Admin Onboarding Call

Use this skill for the prepared decision meeting and its one public Notion
artifact. Infrastructure provisioning stays in `sellable-admin:onboard-client`.
This skill owns only the initial Campaign 1 kickoff engagement.

Read these canonical references before acting:

- `references/original-kickoff-template.md` — the primary meeting-document
  structure adapted from the original `/onboard:2-kickoff-agenda` command.
- `references/agenda-contract.md` — the full client-safe method and public page order.
- `references/handoff-v1.md` — the exact Campaign 1 handoff grammar and the proposed one-line infrastructure-to-call handoff.

The read-only Lightfield CRM helper is
`{{adminRoot}}/scripts/run-lightfield-crm.sh`. Use its exact filtered `find`
command first, then `get` only for a matched account, contact, or opportunity.
Treat the helper itself as a required installed runtime primitive. If that exact
path is absent, record the missing packaged asset as a gotcha before adapting;
never borrow it from a source checkout or call Lightfield directly. A current
registry-backed helper may complete this run with the same bounded filters, but
production verification still requires a rebuilt Admin package pair whose
installed runtime contains the pinned helper.
Lightfield list limits are 1–25; never page broadly through the CRM to discover
one named client. Never print or paste `lightfield.apiKey`, and never include
unrelated CRM records in the public artifact or final receipt.

## Adaptive execution contract

This prompt is the operator for the complete requested mode. MCP tools are
generic primitives and safety boundaries; no wrapper script owns the happy
path, diagnostic order, failure meaning, or retry policy.

At the start of every invocation, restate and retain:

- objective: complete the explicit `prepare` or `finalize` operation and prove
  the requested public result;
- allowed mutation: only the deterministic page bound to the exact client,
  engagement, folder, workspace, and sender in this invocation;
- forbidden effects: every item under Prohibited side effects;
- proof: exact runtime tool identity, typed lifecycle result, page/revision
  identity, and the tool's authenticated plus two-context public verification;
- real blockers: missing authority or credentials, platform permission denial,
  irreversible binding ambiguity, or a confirmed product defect.

Then operate adaptively:

1. Inspect the live binding and tool inventory relevant to the next action.
2. Choose one safe read or lifecycle primitive.
3. Verify progress from the primitive's structured result.
4. If it fails, emit a gotcha containing `surface`, observed `condition`,
   evidence-backed `diagnosis`, materially revised `recovery`, and independent
   `proof` target before another attempt.
5. Never repeat an unchanged failed call. Retry only after relevant live state
   or strategy changed; otherwise return the concrete blocker.

Persist every gotcha and verified binding in the current run receipt, then read
that receipt before the next action. Reuse authenticated receipts from an
earlier zero-write attempt in the same operator run instead of rediscovering the
same folder, ownership, identity, wrapper, or availability condition. Do not
promote a receipt, screenshot, page read, or successful result from a different
operator run into current lifecycle-command proof.

### Fresh execution invariant

Every authorized `prepare` or `finalize` invocation is a distinct operator run,
including a new Codex task carrying `source_thread_id` delegation metadata. The
current run must contain a fresh registered `admin_onboarding_call` tool call
and its structured result. An existing current page, an earlier task's final
answer, a prior receipt or screenshot, `admin_notion_publisher_doctor`, direct
Notion reads, and independent public reads are observations only; none can
replace the lifecycle call required by the current invocation.

Before that lifecycle call, collect or explicitly record unavailable receipts
for every required prepare source in this invocation. "Already researched in a
different task" is not a current-run source receipt. If the exact deterministic
page and revision already exist, classify the action as an idempotent `reuse`
and still call the primitive once with the exact complete agenda. After the
call, write a fresh operator receipt whose lifecycle-call evidence was created
after this invocation started and report only evidence paths from this run. A
final answer that cites only pre-existing receipts or screenshots without a
current-run `admin_onboarding_call` result is a failed invocation, even when the
public page is already correct.

For website and market research, use first-party pages found through web search
or the isolated `agent-browser` CLI. Never use Christian's Chrome profile,
visible Chrome, browser-harness, or UI automation for research. Use the same
isolated surface for final public-page visual inspection when API proof alone
cannot establish meeting usability.

The accepted artifact is a meeting document, not a schema dump. It must use
native Notion headings, bullets, checklists, dividers, and collapsed details
where appropriate. Literal Markdown markers, HTML tags, raw managed-region
markers, a duplicated page title, or a page that merely serializes field labels
as prose is a failed product outcome even when the lifecycle tool returns 200.

Use native MCP discovery when an allowed tool is not initially visible. If the
current installed server's own `tools/list` advertises the exact
`admin_onboarding_call` schema but the host prunes only that callable from the
turn, record a `host_tool_surface_pruned` gotcha and invoke that same registered
primitive once through the installed server's stdio JSON-RPC boundary. Reuse
the configured command, arguments, cwd, and environment; send MCP
`initialize`, `notifications/initialized`, then `tools/call`; retain the exact
binding and complete agenda; and allow the lifecycle call at least 300 seconds
to return its typed result. This is a transport fallback for the same safety
kernel, not permission to import local source, call Notion directly, invent a
replacement script, or bypass the tool schema. Do not use the fallback unless
`tools/list` proves the exact installed server advertises the expected tool,
and never repeat it after an ambiguous timeout.

For an exact-agenda continuation, use the complete agenda supplied in the
current instruction. If the host exposes native `session_search`, it is the
only permitted fallback for recovering that exact prior agenda. Never inspect
Hermes state databases, SQLite files, session files, or profile storage through
terminal or file-search tools. Stop with the missing agenda as a concrete
blocker when neither source is available.

## Modes

The only modes are:

- `prepare` — research bounded existing evidence, render the complete prepared
  agenda, and create or reuse its deterministic public Notion page.
- `finalize` — reconcile the kickoff record, update that same page, retain the
  prepared agenda as collapsed history, and return the exact bounded Campaign 1
  handoff Markdown.

No third mode, reset mode, renewal mode, or later-campaign mode exists.

## Natural-language entry and mutation authority

Mutation authority is narrow and must be evaluated from the user's **current
message**, not prior turns, scheduled context, or routing metadata. Treat
ordinary operator language as the command surface. Christian should not need to
know or provide internal page, folder, workspace, sender, or engagement IDs.
Resolve those from live state and stop only when exact resolution is impossible
or contradictory.

- `make`, `create`, `prepare`, or `update` the kickoff/onboarding-call document
  for one named client and one identifiable upcoming meeting means `prepare`;
- `finalize`, `confirm`, or `record the decisions` after the kickoff means
  `finalize`;
- when no engagement ID is supplied, derive
  `{client-slug}-kickoff-{YYYYMMDD}` from the independently verified meeting
  date and reuse an existing exact binding instead of minting a second one;
- when the date is not explicit, resolve it from the exact upcoming calendar
  event or existing lifecycle record. Multiple plausible meetings are an
  irreversible ambiguity; a missing internal ID is not.

Words such as `today`, `tomorrow`, and `next` are relative requests, not
explicit dates. A delegated or long-running task must not reinterpret them from
a later wall-clock date after midnight. Bind the meeting from the exact
Calendar event, Gmail invite/thread, or existing deterministic lifecycle record
for the same client. A Calendar zero-match is an unavailable source receipt,
not authorization to mint an engagement for the computed day. If one exact
recent prepared engagement and page already reconcile with the client,
attendees, and meeting evidence, reuse it; if the evidence cannot choose
exactly one date, stop before mutation with `relative_date_binding_ambiguous`.

| Current route | Result |
|---|---|
| Natural-language or explicit `prepare` request for exactly one named client and one identifiable kickoff | Resolve the exact binding, then authorize one `prepare` lifecycle mutation after the preview |
| Natural-language or explicit `finalize` request for exactly one named client and one identifiable prior kickoff | Reuse the prepared binding, then authorize one `finalize` lifecycle mutation after the preview |
| Implicit skill routing | Read-only preview, then stop before mutation |
| Missing mode | Read-only preview, then stop before mutation |
| Ambiguous or missing client/meeting after bounded resolution | Read-only preview, then stop before mutation |
| Scheduled, autonomous, or agent continuation without a carried exact authorization envelope | Read-only preview, then stop before mutation |
| Continuation carrying the exact explicit mode/client/engagement/resource envelope from the active operator request | Consume that envelope once and continue inside it |
| Reference or handoff from `onboard-client` | Read-only preview, then stop before mutation |
| Legacy `/onboard:2-kickoff-agenda` alias plus an explicit one-client create/prepare request | Resolve the binding and treat it as `prepare` |

Never select among multiple clients or meetings. Do infer `prepare` or
`finalize` from the unambiguous verbs above. An authorized natural-language or
explicit invocation is the approval for this one scoped Notion lifecycle
mutation; do not ask for a generic second confirmation. The action preview is
evidence, not another approval gate.

## Required action preview

Before either a mutation or a preview-only stop, show exactly these resolved
fields in progress output:

- Resolved client and exact engagement.
- Deterministic title: `Sellable x {Company} — Kickoff & Campaign 1 Decisions`.
- Planned action: `create`, `reuse`, or `update` (or `resolve before mutation`
  when read-only evidence cannot distinguish create from reuse).
- Mode: `prepare`, `finalize`, or `missing/ambiguous`.
- Expected public URL, or `pending deterministic page resolution` when none is
  known yet.

The action preview is evidence, not another approval gate.

If the route is preview-only, end the preview with `Notion mutation: stopped`.
Do not call the publisher or `admin_onboarding_call`.

## Prepare

For an authorized `prepare` invocation:

1. Bind exactly one client name, engagement ID, client folder ID, workspace ID,
   and sender ID. Derive the engagement from the verified meeting when it is
   not supplied; never derive it from an uncorroborated relative-date
   calculation. Resolve internal IDs through live Admin state, exact existing
   client artifacts, and the deterministic lifecycle record; do not ask the
   operator for IDs the system can resolve. Inspect only the read primitives
   that can resolve a missing field or expose a safety conflict, without a
   fixed diagnostic order. Stop read-only only after bounded resolution proves
   a binding missing or conflicting.
2. Gather bounded existing evidence in this order: the exact Calendar event
   and connected read-only Gmail invite/thread that bind the meeting and
   attendees; all relevant existing Grain calls; the client's exact Lightfield
   CRM account, deal, contact, and note context; exact Sellable
   workspace/sender state; first-party web research through web search or
   `agent-browser`; then bounded external research only for a material gap.
   Calendar/Gmail meeting identity wins over stale Lightfield identity when
   they conflict. Sales Pipeline, Onboarding Tracker, and Client Ops Slack
   Lists are not CRM sources for this workflow and must not be called. This
   pre-call research is part of every `prepare`; the
   operator does not need to request each source separately. Prefer newer
   direct customer evidence over older CRM notes when sources conflict. If a
   source is unavailable, record that exact condition and continue from the
   remaining evidence without inventing facts.
   For Lightfield, run `find accounts "{client}" --field '$name' --operator
   equal` and then retrieve only the matched account and directly linked
   contact or opportunity IDs. Treat zero exact matches as a valid empty
   receipt. Do not widen to unrelated CRM records when the exact client has no
   match.
   Prefer already-resolved exact inputs over redundant searches. Use an exact
   Sellable workspace read only when it can change a required identity field or
   expose a safety conflict. When publisher readiness is unknown, or a prior
   exact attempt returned `created_unpublished`, call
   `admin_notion_publisher_doctor` with `checkAuth: true` before another
   lifecycle call. Treat its exact result as publisher evidence, not as a
   substitute for final public proof.
3. Classify evidence internally as `fact`, `inference`, or `open_question`.
   Never publish raw transcript text, private email, pricing, source IDs, internal IDs,
   confidence labels, private DNC entries, or facilitator notes.
4. Build the complete `agenda` object using the exact input contract in
   `references/agenda-contract.md`. Every required field must be a concrete
   public-safe value; preserve honest gaps as explicit public-safe pending
   decisions with owners instead of inventing facts. Thirty to sixty minutes
   controls depth, never section inclusion. Use the deterministic prepared
   revision defined by the reference; never mint a wall-clock or random
   revision for an unchanged binding. Apply the reference's lexical public-
   safety scan to every agenda string before calling the lifecycle primitive;
   a forbidden phrase is invalid even when quoted only to negate or prohibit
   it. Treat renderer-composed values as fragments, not finished sentences:
   every blocker `description` and `dueCondition` omits terminal punctuation
   because the renderer supplies it, and `targetDates.conditionalLaunch`
   contains only the date or pending-date target. Never include the renderer-
   owned `when setup, representative sample review, and approvals are complete`
   suffix, say that gates remain open when completion happens, or restate that
   completion condition in the target value. Canonicalize repeated decision
   and timeline text before preview: each
   open decision appears once, and the
   conditional-launch completion clause appears once in the rendered sentence.
   Re-read the composed blocker and timeline lines before mutation; doubled
   punctuation or a semantically inverted launch condition fails preflight.
   Use the old detailed kickoff-document structure in the
   reference as the meeting-facing base. Prefill it with researched theses and
   decision options; do not reduce it to a sparse list of schema fields. The
   ICP section must contain two or three distinct researched options with
   company demographics and buyer roles. End it with exactly three live prompts
   for the client to name a dream company and buyer role; never show a
   lookalike section or the machine handoff on the public meeting page.
5. Show the required action preview. Because the current invocation already
   authorizes one exact client/meeting, continue without a second approval
   prompt.
6. Call the live registered `admin_onboarding_call` primitive with
   `mode: prepare`, the exact binding, the complete agenda, and only the
   evidence receipts needed for that agenda. The typed tool owns page lookup,
   create/reuse, managed-region lifecycle,
   publishing, authenticated proof, and logged-out public revision proof.
   The call is mandatory in the current operator run even when reads prove that
   the deterministic page and prepared revision already exist; that case is the
   idempotent `reuse` proof, not permission to stop at verification.
7. Report success only when the tool returns `ok: true`, the exact public URL,
   lifecycle `prepared`, and a visible revision, and the rendered page passes
   the native-block and meeting-usability acceptance above. Cite the fresh
   current-run lifecycle receipt and screenshot/public-read evidence, never an
   older run's artifacts. Preserve any typed recovery or stale/blocked result
   exactly.

## Finalize

For an authorized `finalize` invocation:

1. Reuse the exact prepared engagement binding. Do not finalize before prepare,
   change the client, change the engagement, or reuse a confirmed page for a
   renewal or different campaign.
2. Reconcile the complete kickoff against the prepared agenda using supplied
   transcript observations or approved read evidence. Confirm every section,
   record explicit unknown/pending values, assign real blockers, and leave
   unsupported claims unresolved. Build the complete confirmed `agenda` object
   from `references/agenda-contract.md`; do not pass `{}` or a partial object.
   Carry the deterministic confirmed revision across an unchanged rerun. Only
   a material agenda change may advance its explicit numeric suffix, and the
   changed decision must be named in the result.
3. Keep Aida as the single Customer Success Engineer and launch operator. The
   client has no generic homework; only a confirmed client-controlled launch
   blocker receives an explicit owner and due condition.
4. Show the required action preview with action `update`. Continue without a
   second approval prompt because the authorized finalization request plus the
   resolved exact engagement is the scoped authorization.
5. Call the live registered `admin_onboarding_call` primitive once per strategy
   with `mode: finalize`, the complete confirmed agenda, and relevant
   observations. Do not duplicate its append/prove/retire lifecycle or
   maintain a hidden handoff store.
6. Report success only when the same page ID/public URL is current, lifecycle is
   `confirmed`, and the exact returned handoff Markdown is present. Pass that
   bounded Markdown explicitly to the later `$sellable:create-campaign`
   workflow; do not scrape the public URL.

For an unchanged prepare or finalize rerun, reuse the exact prior complete
agenda and deterministic revision. Do not refresh dates, wording, arrays, or
revision merely because the command was invoked again. The lifecycle primitive
is the independent idempotency verifier; a different input is not an
idempotency test.

If an optional evidence read and the lifecycle primitive both fail, keep their
diagnoses separate. Never attribute the lifecycle result to an unrelated read
failure. First compare the exact submitted agenda to the deterministic input,
revision, and lexical-safety contracts. Retry only after the offending input or
other proven lifecycle condition changes and a fresh exact authorization exists.

## Method boundary

Every call covers the complete agenda, keeps Signal Discovery as the only
first sourcing/relevance method, and uses plain English: relevant LinkedIn
topics, creators, posts, conversations, and participants. Sales Navigator may
appear only as a sender/setup readiness fact. Hiring, funding, timing,
technology, generic intent, database-provider signals, or dream-client examples
as source seeds are forbidden in this artifact and handoff. Dream clients are
live qualitative discussion prompts for clarifying fit only. The final public
decision list must ask the client to define three dream clients and the buyer
role at each; never carry a prefilled dream account, lookalike, or reusable-fit
decision into the public page.

The page preserves the readiness ledger, named owners, real dates, an
approval-ready plan within 48 hours, and a conditional launch target within
5–7 business days after payment only when setup, representative-sample review,
and approvals are complete.

## Prohibited side effects

This skill must never:

- send, post, edit, schedule, or delete Slack messages or canvases;
- draft or send Gmail;
- search, enrich, import, or add leads;
- create the downstream 25–50 lead sample or its approval packet;
- create, mutate, schedule, or launch a campaign;
- send outreach or broaden authority to any other Notion page.

Those are separate workflows with separate gates. This skill names downstream
handoffs but contains no executable instructions for them.

## Result handling

Treat HTTP 200, a non-null `publicUrl`, authenticated Notion content, or a
screenshot alone as insufficient. A successful result requires the typed tool's
current logged-out rendered revision proof. Surface stable recovery states such
as `created_unpublished`, `prepared_internal_public_stale`,
`confirmed_internal_public_stale`, or `public_verification_blocked` without
claiming the page is current.

On `created_unpublished`, preserve the deterministic page and revision. Inspect
the publisher doctor before retrying; do not create a replacement page or call
the publisher directly. A missing provider key, configured-profile auth
failure, permission denial, or public-verifier failure is a distinct condition
with a distinct recovery proof. Resume only through `admin_onboarding_call`
after that exact condition changes and the authorization envelope is renewed.
Read and record any returned `publisherDiagnostic` before choosing recovery. A
transient internal-page load condition is a publisher-primitive condition, not
an authentication failure and not authority to repeat the unchanged lifecycle
call; require materially changed publisher behavior or live state first.
If the host transport times out before returning the lifecycle result, do not
infer page state or retry. Record the exact configured timeout as a host-kernel
condition and require a longer registered MCP tool boundary before continuing.
On a typed public-proof failure, retain the returned page, public URL, visible
revision, and `publicDiagnostic` as non-success diagnostic evidence. Do not
discard navigation errors or treat a redirect-aborted navigation signal as
terminal before inspecting the rendered page in both cookie-free contexts.
Treat a CDP parameter-validation error as a verifier implementation defect,
not a public-page failure. Preserve its exact diagnostic and correct the
invalid primitive argument before any fresh lifecycle continuation.
The exactly-once public assertion applies to the canonical `Visible revision:`
marker, not every intentional appearance of the raw revision token in the
handoff. A failed disposable public context may be replaced once with a fresh
empty context; final proof still requires two distinct successful cookie-free
contexts and never reuses the failed context's state.
When an exact known public URL already passes the publisher's lightweight live
check, the publisher must skip authenticated Notion navigation and continue to
the independent rendered-revision proof. A wrapper timeout or stale-daemon
signal is a typed condition for the operator; the wrapper never replays the
whole unchanged harness on its own.
If that known-live path returns `timed out` with zero public observations, treat
it as proof that the publisher incorrectly entered authenticated publication
navigation before public revision reads. Repair that primitive ordering; do not
run publisher doctor or repeat the unchanged lifecycle.
Do not accept `document.readyState=complete` plus arbitrary non-empty body text
as rendered-page evidence: Notion's loading shell can satisfy both before page
hydration. Wait for the complete expected title, revision, and required-text
set in a stable rendered sample. At the bounded deadline, assess the last
non-empty sample honestly so a truly stale or mismatched page is still typed.
If authenticated and public reads show a required heading fragmented across
adjacent Notion blocks, treat it as a content-packing implementation defect.
Rich-text chunking must preserve newline and heading boundaries; do not weaken
the required-text proof or ask the operator to reword the complete agenda.
Idempotency compares the exact canonical managed block layout as well as the
visible revision. If executable packing rules change while the agenda and
revision remain identical, repair that one managed region in place, retire the
superseded layout, and let later unchanged reruns remain true no-ops.

For a failed or blocked result, include this compact operator receipt before
stopping or materially changing strategy:

```json
{
  "surface": "registered tool or proof boundary",
  "condition": "typed observed state",
  "diagnosis": "what current evidence proves",
  "recovery": "next materially different safe strategy, or none",
  "proof": "independent result that would verify recovery"
}
```