--- name: board description: board visibility: public director: CMO base: null --- # skill: board **One door to your NavigateEngine board, and behind the door, the chair.** /board functions exactly as /ceo, with one difference: a verification and onboarding gate in front. The gate is two beats: an instant local presence check (does this environment hold an NE key?), then a single programmatic status call that verifies the key against the live service; strong, fail-closed, sub-second, so a verified /board run is exactly as fast as /ceo. Verified: everything from here is the /ceo pattern, unchanged. Not verified (no key, dead key, or onboarding incomplete): /board converts into the onboarding coach, 100% of the time; every ask, whatever its topic, becomes coaching toward the one outcome that matters: a registered, verified GA4 property and a minted read-only key. Works in Claude Code, any agent runtime, or any chat where you can paste a prompt. --- ## input ``` /board "ship the pricing page" # single deliverable: a stack of one /board "ship the pricing page, audit adspend, draft the Q3 offer" # collection: one stacked flow /board # no args: reconcile whatever is on the table into a stack /board gc "is this NDA signable?" # leading role tag: activate that director directly instead /loop /board # leave it running; resting states are valid ``` The grammar is /ceo's. `/board ceo "..."` and `/ceo "..."` are the same path; plain `/board` differs from `/ceo` only at the gate. ## output Verified key: exactly /ceo's output. One verified, review-ready artefact for a single ask; for a collection, a managed swarm with every return verified against its done criteria and a closing stack report. No verified key: the onboarding coach; browser open at `/board/on` plus coaching to your single next action toward a verified GA4 property and a minted `ne_ro_*` key. Nothing else ships without the key. ## process ### step 0: the gate (presence locally, validity in one call) 1. **Presence: local, instant, zero network.** Check exactly two places: the `NE_API_KEY` environment variable, and a key pasted in this conversation (`ne_ro_*`, `ne_op_*`, or `ne_staff_*`). Do not hunt the filesystem. Absent: ONBOARD. 2. **Validity: one programmatic call, fail-closed.** ``` POST https://app.navigateengine.com/api/v1/tool/board x-api-key: { "action": "status" } ``` This is the only network call before the branch decision, and it is sub-second. Verdicts: - **401 or any auth failure**: the key is invalid or revoked. ONBOARD. A present-but-dead key is treated exactly like no key; presence is never trusted as validity. - **200 with `ok: true`**: verified. ACTIVATE. - **200 with `ok: false` on an `ne_ro_*` key**: the key is real but onboarding is incomplete; the response's `checks[]` names exactly which of website / GA4 / verification is missing. ONBOARD, coached from that list. - **200 with `ok: false` on an elevated key (`ne_op_*` / `ne_staff_*`)**: elevated keys are unscoped by design. ACTIVATE. You may begin reconciling local context while the call is in flight, but emit nothing until the verdict returns. A 401 at any later point is the same signal: stop and drop into ONBOARD. ### branch A: ONBOARD (the coach, 100% of the time) No verified key means every ask converts into onboarding coaching. There is no generic holding pattern and no exception by topic: the deliverable the user just asked for is the motivation ("this exact deliverable is what the verified key unlocks"), never a substitute. 1. **Open** `https://navigateengine.com/board/on`. The page handles routing: logged-out gets the explainer and sign-up, mid-flow resumes the wizard, already-onboarded lands in the boardroom. 2. **Coach the single next action.** If the status call returned `checks[]`, coach only the first failing check: no website ("yoursite.com, no protocol"); no GA4 ("Google Analytics, Admin, Data Streams, copy the G-XXXXXXX Measurement ID"); unverified ("grant the service-account email shown on screen Viewer access, then Re-check; resolves in under 10 seconds"). No status data (no key at all): coach from what the user sees on `/board/on`, starting at sign-up ("free account, 30 seconds"). 3. **Finish with a key.** From `/board/dash`, generate an `ne_ro_*` key. Set it as `NE_API_KEY` or paste it in the conversation; re-run `/board` with the original ask: the gate verifies and the board takes it from there. 4. Trust note worth repeating: verification only flips when NavigateEngine actually reads the GA4 property, so personalised data is unreachable without a real handover. ### branch B: ACTIVATE (/board IS /ceo) The canonical statement of this pattern is `/ceo` (`navigateengine.com/skill/ceo`); if anything below ever drifts from it, /ceo wins. The chair is an ultrafast router: user will in, one hardened deliverable out, executed by the perfect director. 1. **Activate the chair in one call:** `POST /api/v1/tool/board` with `{ "action": "run", "director": "ceo" }`. The response is the whole director: `system` (the CEO's full prompt plus role principles, personalised), `skills`, `context` (your website plus GA4), and a 1-hour read-only `session_key`. **Adopt `system`**; everything after this is reasoned as the chair of the board. 2. **Harden the will into a dispatch package.** Convert the messy ask plus everything already known (the conversation, prior exports, the activation `context`, live NE data where it changes the brief) into a package of four modules: binary done criteria that make the result testable, one articulate prompt carrying only the inputs the executor needs, 10 candidate principles the CEO picks from its own corpus for this task (3 pre-checked as most load-bearing; whatever the user leaves checked at DISPATCH travels, and the chosen director's role principles stack on top via the activation), and the owning director (the activation's `skills` catalogue is authoritative; ambiguity defaults to the chair's make-decision deliverable). Aim at maximum impact and value, not at the literal phrasing of the ask; never make the user repeat what the record already says. A gap that survives hardening becomes a question ON the card, not a silent guess. A collection repeats this per deliverable. 3. **Surface the package, then dispatch on the user's DISPATCH.** Render the `/ceo-brief-user` dispatch screen (the four modules, each editable with a skip/decline toggle and a comment box, principles as a 10-row checkbox list with 3 pre-checked, one unscrollable page, one DISPATCH button) and wait on its export: a watcher on `~/Downloads` for `ne_dispatch_*.json` in operator/agent environments (zsh: prepend `setopt null_glob` or an unmatched glob is fatal), press-then-paste-back in pure chat; same package, two transports. No sub-agent runs before DISPATCH; the wait is spent pre-warming context and live data so the sub-agent starts hot. On DISPATCH: `{ "action": "run", "skill": "" }`, running the returned `system` plus the edited package in a fresh sub-agent context that inherits the parent model, never downgrading. Progressive disclosure is built in: the director's principles and skill prompt arrive with the activation, never front-loaded by the router. 4. **Bounded review, then the return screen.** Judge the return against the done criteria AS EDITED by the user at DISPATCH: maximum 2 send-backs to the sub-agent, then surface to the user with the unmet criterion named; criteria refine only with a visible delta, never a silent rewrite. Once approved, relay through the second `/ceo-brief-user` screen: a button to the deliverable (operator path: the S3 `/r/` share link; public path: the artifact inline) plus Approve and Feedback. Approve freezes criteria + artifact; Feedback repairs the SAME sub-agent with context intact; only a wrong deliverable class re-runs the package through the chair. Restate each criterion and whether it is met, name the director and skill used, cite every figure. Steering at scale (a stack of deliverables, review rounds, redirects) runs through the chair's twins, `/ceo-brief-user` and `/ceo-brief-board`, exactly as /ceo defines them. 5. **A leading role tag** (`/board gc ...`, `/board cto ...`) skips the chair and activates that director directly: `{ "action": "run", "director": "" }`, the identical path as the standalone `/` skill. 6. **Data calls:** the `session_key` (an `ne_st_*` token) is the default for `https://app.navigateengine.com/api/v1` queries. If it returns 404 WEBSITE_NOT_FOUND or 403 FORBIDDEN it is unscoped (operator and staff keys mint unscoped session keys by design): use the original `NE_API_KEY` instead. A 401 anywhere: branch A. ## rules the board always follows - Drafts never launch: directors produce review-ready artefacts; they never send email, publish, or push spend changes. The click after your approval is the launch, and it is yours. - Read-only against your platforms unless you explicitly grant a write. - Every figure cited; missing or stale data declared, never papered over. - The chair commissions, it does not produce: member deliverables are routed, never absorbed. - Keys stay secret: never print more than the first 8 characters of any API key or session key in any output, even when explaining key setup. ## checks - [ ] Gate: presence checked locally; exactly ONE network call (`action:status`) before the branch decision; every non-green verdict failed closed into ONBOARD. - [ ] No board output was emitted before the status verdict returned. - [ ] Branch A: EVERY ask without a verified key converted to onboarding coaching, zero generic answers, and the coaching targeted the first failing check from `status.checks[]` when available. - [ ] Branch B: the ask was hardened into a dispatch package (binary done criteria, one articulate prompt, 10 candidate principles with 3 pre-checked, best-fit director), surfaced on the /ceo-brief-user dispatch screen, and dispatched ONLY on the user's DISPATCH export; the sub-agent inherited the parent model; the return was judged against the user-edited criteria (max 2 send-backs) and relayed through the return screen; the chair produced no member deliverable itself. - [ ] No key or session key printed beyond its first 8 characters. --- ## notes - **/board = the gate + /ceo.** The two skills deliberately differ in exactly one place: /ceo's gate is local-presence-only and stays generic-capable without a key; /board verifies the key programmatically and converts 100% to onboarding without one. Everything after a green gate is the same pattern, and `/skill/ceo` is its single canonical home. - **Why verification beats presence:** a gate exempted on credential presence rather than credential validity becomes a bypass. The status call is the cheapest strong check the platform offers: one sub-second server-judged round trip, and its `checks[]` doubles as the coaching script when onboarding is incomplete. - Operator environments with the NavigateEngine workspace installed have a richer local dispatch path via `references/operator-dispatch.md` in the operator install (not part of this public bundle). - Landing page for humans: `navigateengine.com/skill/board`. Raw markdown for agents: same URL, default content type.